Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

I got an error emailing Masami Hiramatsu <masami.hiramatsu@linaro.org>, 
who's listed as a reviewer for Socionext platforms and silicon: 
apparently they no longer work at Linaro.


-- 

Rebecca Cran


On 8/19/22 17:35, Rebecca Cran wrote:
>
> I have an armplatbld.sh script that goes through and tries to build as 
> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>
> I'm think this used to work for these, but I'm getting some errors now.
>
> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>
>
> Drivers/ASIX/Asix.dsc (fails with undefined references to 
> __stack_chk_guard and __stack_chk_fail)
>
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
> undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
> symbol type.  For example, absolute and undefined symbols are not 
> supported.)
>
> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined 
> references to __stack_chk_guard and __stack_chk_fail)
> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
> with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
> unsupported symbol type.  For example, absolute and undefined symbols 
> are not supported.)
>
>
> -- 
> Rebecca Cran
>
> 

[-- Attachment #2: Type: text/html, Size: 9965 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]

./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about 
__stack_chk_guard and __stack_chk_fail.


And I get an error from Andy Hayes' email: "Your message couldn't be 
delivered to the recipient because you don't have permission to send to it."


-- 
Rebecca Cran


On 8/19/22 17:35, Rebecca Cran wrote:
>
> I have an armplatbld.sh script that goes through and tries to build as 
> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>
> I'm think this used to work for these, but I'm getting some errors now.
>
> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and 
> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>
>
> Drivers/ASIX/Asix.dsc (fails with undefined references to 
> __stack_chk_guard and __stack_chk_fail)
>
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with 
> undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad 
> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported 
> symbol type.  For example, absolute and undefined symbols are not 
> supported.)
>
> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined 
> references to __stack_chk_guard and __stack_chk_fail)
> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails 
> with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or 
> unsupported symbol type.  For example, absolute and undefined symbols 
> are not supported.)
>
>
> -- 
> Rebecca Cran
>
> 

[-- Attachment #2: Type: text/html, Size: 10313 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

Hi Rebecca,

What EDK2 toolchain are you using? And how is your toolchain configured (or
where did you get it from?)? It seems that it's trying to use the stack
protector automatically...

Thanks,
Pedro


On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:

> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
> __stack_chk_guard and __stack_chk_fail.
>
>
> And I get an error from Andy Hayes' email: "Your message couldn't be
> delivered to the recipient because you don't have permission to send to it."
>
>
> --
> Rebecca Cran
>
>
> On 8/19/22 17:35, Rebecca Cran wrote:
>
> I have an armplatbld.sh script that goes through and tries to build as
> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>
> I'm think this used to work for these, but I'm getting some errors now.
>
> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and
> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>
>
> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard
> and __stack_chk_fail)
>
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
> undefined references to __stack_chk_guard and __stack_chk_fail)
> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad
> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported
> symbol type.  For example, absolute and undefined symbols are not
> supported.)
>
> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references
> to __stack_chk_guard and __stack_chk_fail)
> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
> (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
> unsupported symbol type.  For example, absolute and undefined symbols are
> not supported.)
>
>
> --
> Rebecca Cran
> 
>
>

[-- Attachment #2: Type: text/html, Size: 9111 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

[-- Attachment #1: Type: text/plain, Size: 5490 bytes --]

I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu 
20.04.4, from the Ubuntu repo.

I'm building it with:


export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
export WORKSPACE=$PWD
export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-

. ./edk2/edksetup.sh
build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5


Some of the messages are:


"aarch64-linux-gnu-gcc" -o 
/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll 
-Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint 
-Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map 
-z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os 
-L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch 
-Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group 
-g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror 
-Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections 
-fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar 
-fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds 
-include AutoGen.h -fno-common -mlittle-endian -fno-short-enums 
-fverbose-asm -funsigned-char -ffunction-sections -fdata-sections 
-Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic 
-fno-pie -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable 
-Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES 
-Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function 
`InternalAllocatePool.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: 
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation 
R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may 
bind externally can not be used when making a shared object; recompile 
with -fPIC
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc): 
dangerous relocation: unsupported relocation
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368: 
undefined reference to `__stack_chk_guard'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382: 
undefined reference to `__stack_chk_fail'
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: 
/tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function 
`OrderedCollectionInsert.constprop.0':
/home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584: 
undefined reference to `__stack_chk_guard'

-- 
Rebecca Cran


On 8/19/22 18:46, Pedro Falcato wrote:
> Hi Rebecca,
>
> What EDK2 toolchain are you using? And how is your toolchain 
> configured (or where did you get it from?)? It seems that it's trying 
> to use the stack protector automatically...
>
> Thanks,
> Pedro
>
>
> On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:
>
>     ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
>     __stack_chk_guard and __stack_chk_fail.
>
>
>     And I get an error from Andy Hayes' email: "Your message couldn't
>     be delivered to the recipient because you don't have permission to
>     send to it."
>
>
>     -- 
>     Rebecca Cran
>
>
>     On 8/19/22 17:35, Rebecca Cran wrote:
>>
>>     I have an armplatbld.sh script that goes through and tries to
>>     build as many of the Arm (AARCH64 and ARM) platforms in
>>     edk2-platforms as possible.
>>
>>     I'm think this used to work for these, but I'm getting some
>>     errors now.
>>
>>     I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8
>>     and edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>
>>
>>     Drivers/ASIX/Asix.dsc (fails with undefined references to
>>     __stack_chk_guard and __stack_chk_fail)
>>
>>     Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
>>     undefined references to __stack_chk_guard and __stack_chk_fail)
>>     Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with
>>     bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
>>     unsupported symbol type.  For example, absolute and undefined
>>     symbols are not supported.)
>>
>>     Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined
>>     references to __stack_chk_guard and __stack_chk_fail)
>>     Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails
>>     with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
>>     unsupported symbol type.  For example, absolute and undefined
>>     symbols are not supported.)
>>
>>
>>     -- 
>>     Rebecca Cran
>>
>>     
>

[-- Attachment #2: Type: text/html, Size: 17065 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 5809 bytes --]

I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC
toolchains (although arguably we should just enable support for it...). Can
you try hacking up your tools_def to add -fno-stack-protector to
GCC_AARCH64_CC_FLAGS? It should fix your build issues.

On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran <rebecca@bsdio.com> wrote:

> I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu
> 20.04.4, from the Ubuntu repo.
>
> I'm building it with:
>
>
> export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
> export WORKSPACE=$PWD
> export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
>
> . ./edk2/edksetup.sh
> build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5
>
>
> Some of the messages are:
>
>
> "aarch64-linux-gnu-gcc" -o
> /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
> -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint
> -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
> -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
> -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64
> -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch
> -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
> -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror
> -Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections
> -fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
> -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include
> AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm
> -funsigned-char -ffunction-sections -fdata-sections -Wno-address
> -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic -fno-pie
> -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable
> -Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES
> -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
> -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
> `InternalAllocatePool.constprop.0':
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
> undefined reference to `__stack_chk_guard'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
> R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may
> bind externally can not be used when making a shared object; recompile with
> -fPIC
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
> dangerous relocation: unsupported relocation
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
> undefined reference to `__stack_chk_guard'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
> undefined reference to `__stack_chk_fail'
> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
> `OrderedCollectionInsert.constprop.0':
> /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
> undefined reference to `__stack_chk_guard'
>
> --
> Rebecca Cran
>
>
> On 8/19/22 18:46, Pedro Falcato wrote:
>
> Hi Rebecca,
>
> What EDK2 toolchain are you using? And how is your toolchain configured
> (or where did you get it from?)? It seems that it's trying to use the stack
> protector automatically...
>
> Thanks,
> Pedro
>
>
> On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:
>
>> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
>> __stack_chk_guard and __stack_chk_fail.
>>
>>
>> And I get an error from Andy Hayes' email: "Your message couldn't be
>> delivered to the recipient because you don't have permission to send to it."
>>
>>
>> --
>> Rebecca Cran
>>
>>
>> On 8/19/22 17:35, Rebecca Cran wrote:
>>
>> I have an armplatbld.sh script that goes through and tries to build as
>> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>>
>> I'm think this used to work for these, but I'm getting some errors now.
>>
>> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and
>> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>
>>
>> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard
>> and __stack_chk_fail)
>>
>> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
>> undefined references to __stack_chk_guard and __stack_chk_fail)
>> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad
>> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported
>> symbol type.  For example, absolute and undefined symbols are not
>> supported.)
>>
>> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined references
>> to __stack_chk_guard and __stack_chk_fail)
>> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
>> (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
>> unsupported symbol type.  For example, absolute and undefined symbols are
>> not supported.)
>>
>>
>> --
>> Rebecca Cran
>> 
>>
>>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 15699 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

[-- Attachment #1: Type: text/plain, Size: 6667 bytes --]

Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have:


   # Add support for GCC stack protector
   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf


-- 

Rebecca Cran


On 8/19/22 20:34, Pedro Falcato wrote:
> I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC 
> toolchains (although arguably we should just enable support for 
> it...). Can you try hacking up your tools_def to add 
> -fno-stack-protector to GCC_AARCH64_CC_FLAGS? It should fix your build 
> issues.
>
> On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran <rebecca@bsdio.com> wrote:
>
>     I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on
>     Ubuntu 20.04.4, from the Ubuntu repo.
>
>     I'm building it with:
>
>
>     export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
>     export WORKSPACE=$PWD
>     export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
>
>     . ./edk2/edksetup.sh
>     build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5
>
>
>     Some of the messages are:
>
>
>     "aarch64-linux-gnu-gcc" -o
>     /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
>     -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint
>     -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
>     -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
>     -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto
>     -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64
>     -Wno-lto-type-mismatch
>     -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
>     -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall
>     -Werror -Wno-array-bounds -include AutoGen.h -fno-common
>     -ffunction-sections -fdata-sections
>     -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
>     -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds
>     -include AutoGen.h -fno-common -mlittle-endian -fno-short-enums
>     -fverbose-asm -funsigned-char -ffunction-sections -fdata-sections
>     -Wno-address -fno-asynchronous-unwind-tables -fno-unwind-tables
>     -fno-pic -fno-pie -ffixed-x18 -mcmodel=small -flto
>     -Wno-unused-but-set-variable -Wno-unused-const-variable -D
>     DISABLE_NEW_DEPRECATED_INTERFACES
>     -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
>     -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
>     /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>     /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>     `InternalAllocatePool.constprop.0':
>     /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>     undefined reference to `__stack_chk_guard'
>     /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>     /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
>     R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard'
>     which may bind externally can not be used when making a shared
>     object; recompile with -fPIC
>     /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
>     dangerous relocation: unsupported relocation
>     /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>     /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>     undefined reference to `__stack_chk_guard'
>     /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>     /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
>     undefined reference to `__stack_chk_fail'
>     /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>     /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>     `OrderedCollectionInsert.constprop.0':
>     /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
>     undefined reference to `__stack_chk_guard'
>
>     -- 
>     Rebecca Cran
>
>
>     On 8/19/22 18:46, Pedro Falcato wrote:
>>     Hi Rebecca,
>>
>>     What EDK2 toolchain are you using? And how is your toolchain
>>     configured (or where did you get it from?)? It seems that it's
>>     trying to use the stack protector automatically...
>>
>>     Thanks,
>>     Pedro
>>
>>
>>     On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:
>>
>>         ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors
>>         about __stack_chk_guard and __stack_chk_fail.
>>
>>
>>         And I get an error from Andy Hayes' email: "Your message
>>         couldn't be delivered to the recipient because you don't have
>>         permission to send to it."
>>
>>
>>         -- 
>>         Rebecca Cran
>>
>>
>>         On 8/19/22 17:35, Rebecca Cran wrote:
>>>
>>>         I have an armplatbld.sh script that goes through and tries
>>>         to build as many of the Arm (AARCH64 and ARM) platforms in
>>>         edk2-platforms as possible.
>>>
>>>         I'm think this used to work for these, but I'm getting some
>>>         errors now.
>>>
>>>         I'm using edk2-platforms
>>>         46686eeb7e78efe603badd86f13777d9fb070fb8 and edk2
>>>         e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>>
>>>
>>>         Drivers/ASIX/Asix.dsc (fails with undefined references to
>>>         __stack_chk_guard and __stack_chk_fail)
>>>
>>>         Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails
>>>         with undefined references to __stack_chk_guard and
>>>         __stack_chk_fail)
>>>         Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails
>>>         with bad definition for symbol
>>>         '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type. 
>>>         For example, absolute and undefined symbols are not supported.)
>>>
>>>         Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with
>>>         undefined references to __stack_chk_guard and __stack_chk_fail)
>>>         Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails
>>>         with bad definition for symbol
>>>         '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol type. 
>>>         For example, absolute and undefined symbols are not supported.)
>>>
>>>
>>>         -- 
>>>         Rebecca Cran
>>>
>>>         
>>
>
>
> -- 
> Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 20910 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Pedro Falcato]

[-- Attachment #1: Type: text/plain, Size: 7555 bytes --]

Hi,

So, what's your suggestion? Do you want me to add that to my package as
well?

There is obviously a huge problem with EDK2 build tools not knowing what a
damn runtime library is. I personally don't think it's appropriate for me
to say "I want my package built with the stack protector", particularly
because my package shouldn't know what a damn stack protector is, and
whoever is building it knows best, and because of that this should be dealt
with by the build system itself (and no, setting it up in a platform dsc
isn't a correct approach, since my package should be buildable standalone).
And what if someone doesn't want the stack protector? Do they just create a
new AARCH64_GCC5_NOSSP toolchain and build it with that? Do they just sed
AARCH64_GCC5 to use -fno-stack-protector? Do they just limit themselves to
toolchains without default SSP? IMO the correct way to go about things is
to have the build tools automatically insert dependencies on runtime
libraries and have a way to tag a toolchain such that you can easily
selectively enable instrumentation (such as the SSP, UBSAN, ASAN, etc) and
build them in any combination.

Anyway, </rant>. I'll defer to your experience with the EDK2 build system
for a solution.

All the best,
Pedro

On Sat, Aug 20, 2022 at 4:06 AM Rebecca Cran <rebecca@bsdio.com> wrote:

> Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have:
>
>
>   # Add support for GCC stack protector
>   NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>
>
> --
>
> Rebecca Cran
>
>
> On 8/19/22 20:34, Pedro Falcato wrote:
>
> I see the issue: We're not passing -fno-stack-protector to AARCH64 GCC
> toolchains (although arguably we should just enable support for it...). Can
> you try hacking up your tools_def to add -fno-stack-protector to
> GCC_AARCH64_CC_FLAGS? It should fix your build issues.
>
> On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran <rebecca@bsdio.com> wrote:
>
>> I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) on Ubuntu
>> 20.04.4, from the Ubuntu repo.
>>
>> I'm building it with:
>>
>>
>> export PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
>> export WORKSPACE=$PWD
>> export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
>>
>> . ./edk2/edksetup.sh
>> build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE -t GCC5
>>
>>
>> Some of the messages are:
>>
>>
>> "aarch64-linux-gnu-gcc" -o
>> /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
>> -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u _ModuleEntryPoint
>> -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
>> -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
>> -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto -llto-aarch64
>> -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch
>> -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
>> -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall -Werror
>> -Wno-array-bounds -include AutoGen.h -fno-common -ffunction-sections
>> -fdata-sections -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
>> -fno-builtin -fno-strict-aliasing -Wall -Werror -Wno-array-bounds -include
>> AutoGen.h -fno-common -mlittle-endian -fno-short-enums -fverbose-asm
>> -funsigned-char -ffunction-sections -fdata-sections -Wno-address
>> -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-pic -fno-pie
>> -ffixed-x18 -mcmodel=small -flto -Wno-unused-but-set-variable
>> -Wno-unused-const-variable -D DISABLE_NEW_DEPRECATED_INTERFACES
>> -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
>> -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
>> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>> `InternalAllocatePool.constprop.0':
>> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>> undefined reference to `__stack_chk_guard'
>> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
>> R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard' which may
>> bind externally can not be used when making a shared object; recompile with
>> -fPIC
>> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
>> dangerous relocation: unsupported relocation
>> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>> undefined reference to `__stack_chk_guard'
>> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>> /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
>> undefined reference to `__stack_chk_fail'
>> /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>> /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>> `OrderedCollectionInsert.constprop.0':
>> /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
>> undefined reference to `__stack_chk_guard'
>>
>> --
>> Rebecca Cran
>>
>>
>> On 8/19/22 18:46, Pedro Falcato wrote:
>>
>> Hi Rebecca,
>>
>> What EDK2 toolchain are you using? And how is your toolchain configured
>> (or where did you get it from?)? It seems that it's trying to use the stack
>> protector automatically...
>>
>> Thanks,
>> Pedro
>>
>>
>> On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com> wrote:
>>
>>> ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with errors about
>>> __stack_chk_guard and __stack_chk_fail.
>>>
>>>
>>> And I get an error from Andy Hayes' email: "Your message couldn't be
>>> delivered to the recipient because you don't have permission to send to it."
>>>
>>>
>>> --
>>> Rebecca Cran
>>>
>>>
>>> On 8/19/22 17:35, Rebecca Cran wrote:
>>>
>>> I have an armplatbld.sh script that goes through and tries to build as
>>> many of the Arm (AARCH64 and ARM) platforms in edk2-platforms as possible.
>>>
>>> I'm think this used to work for these, but I'm getting some errors now.
>>>
>>> I'm using edk2-platforms 46686eeb7e78efe603badd86f13777d9fb070fb8 and
>>> edk2 e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>>
>>>
>>> Drivers/ASIX/Asix.dsc (fails with undefined references to __stack_chk_guard
>>> and __stack_chk_fail)
>>>
>>> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc (fails with
>>> undefined references to __stack_chk_guard and __stack_chk_fail)
>>> Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc (fails with bad
>>> definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported
>>> symbol type.  For example, absolute and undefined symbols are not
>>> supported.)
>>>
>>> Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with undefined
>>> references to __stack_chk_guard and __stack_chk_fail)
>>>
>>> Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc
>>> (fails with bad definition for symbol '_GLOBAL_OFFSET_TABLE_'@0x72d8 or
>>> unsupported symbol type.  For example, absolute and undefined symbols are
>>> not supported.)
>>>
>>>
>>> --
>>> Rebecca Cran
>>> 
>>>
>>>
>
> --
> Pedro Falcato
>
>

-- 
Pedro Falcato

[-- Attachment #2: Type: text/html, Size: 19719 bytes --]

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Ard Biesheuvel]

On Wed, 24 Aug 2022 at 13:05, Pedro Falcato <pedro.falcato@gmail.com> wrote:
>
> Hi,
>
> So, what's your suggestion? Do you want me to add that to my package as well?
>
> There is obviously a huge problem with EDK2 build tools not knowing what a damn runtime library is.

The real problem here is that someone decided that, instead of
implementing proper support for PE/COFF executables in binutils and
GCC [for certain architectures: most notably ARM and arm64 today, but
also Itanium], it is OK to use a toolchain that targets an entirely
different execution environment (ELF on Linux, for example), and hack
some scaffolding around its output looks like PE/COFF to the extent
required by EFI.

Of course, this entirely falls apart with any kind of runtime library:
this also affects memcpy() and memset(), for instance, and on ARM32, a
slew of __aeabi_xxx runtime routines that the architecture specifies
for ELF targets. And we cannot actually use the toolchain provided
versions either, as they may contain syscalls or other codegen that
depends on the toolchain's target ABI.

> I personally don't think it's appropriate for me to say "I want my package built with the stack protector", particularly because my package shouldn't know what a damn stack protector is, and whoever is building it knows best, and because of that this should be dealt with by the build system itself (and no, setting it up in a platform dsc isn't a correct approach, since my package should be buildable standalone). And what if someone doesn't want the stack protector? Do they just create a new AARCH64_GCC5_NOSSP toolchain and build it with that? Do they just sed AARCH64_GCC5 to use -fno-stack-protector? Do they just limit themselves to toolchains without default SSP? IMO the correct way to go about things is to have the build tools automatically insert dependencies on runtime libraries and have a way to tag a toolchain such that you can easily selectively enable instrumentation (such as the SSP, UBSAN, ASAN, etc) and build them in any combination.
>

In my opinion, adding stack protector support like this was a mistake.
What we need is a single intrinsics library, where every
arch/toolchain combo can provide all the stuff that might be needed.
If structured correctly (i.e., use separate objects and rely on LD
garbage collection), this will only pull in the code that is actually
needed at link time, and will get rid of these errors.

As for overriding the use of the stack protector: this can be done
from a DSC file, by appending -f[no]-stack-protector to the global CC
flags. In general, choice of compiler options is a DSC level choice,
so it is not something you typically need to worry about at the
package level.

Building the *SAN pieces like this requires extensive runtime support
anyway, and so I don't see those being supported soon - someone needs
to port the runtime library first.

> Anyway, </rant>. I'll defer to your experience with the EDK2 build system for a solution.
>

I propose adding the library class resolution to the DSC - it will
only take effect when the stack protector is actually enabled. Then,
if you feel generous, you can add a DEFINE that can be set from the
build command line to control stack protector support, but I
personally wouldn't bother.

Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)

[Rebecca Cran]

I really don't have much knowledge about the EDK2 build system, and was 
hoping that Ard would reply - which he has!

-- 
Rebecca Cran

On 8/24/22 05:05, Pedro Falcato wrote:
> Hi,
>
> So, what's your suggestion? Do you want me to add that to my package 
> as well?
>
> There is obviously a huge problem with EDK2 build tools not knowing 
> what a damn runtime library is. I personally don't think it's 
> appropriate for me to say "I want my package built with the stack 
> protector", particularly because my package shouldn't know what a damn 
> stack protector is, and whoever is building it knows best, and because 
> of that this should be dealt with by the build system itself (and no, 
> setting it up in a platform dsc isn't a correct approach, since my 
> package should be buildable standalone). And what if someone doesn't 
> want the stack protector? Do they just create a new AARCH64_GCC5_NOSSP 
> toolchain and build it with that? Do they just sed AARCH64_GCC5 to use 
> -fno-stack-protector? Do they just limit themselves to toolchains 
> without default SSP? IMO the correct way to go about things is to have 
> the build tools automatically insert dependencies on runtime libraries 
> and have a way to tag a toolchain such that you can easily selectively 
> enable instrumentation (such as the SSP, UBSAN, ASAN, etc) and build 
> them in any combination.
>
> Anyway, </rant>. I'll defer to your experience with the EDK2 build 
> system for a solution.
>
> All the best,
> Pedro
>
> On Sat, Aug 20, 2022 at 4:06 AM Rebecca Cran <rebecca@bsdio.com> wrote:
>
>     Other platform such as Platform/Qemu/SbsaQemu/SbsaQemu.dsc have:
>
>
>       # Add support for GCC stack protector
>     NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>
>
>     -- 
>
>     Rebecca Cran
>
>
>     On 8/19/22 20:34, Pedro Falcato wrote:
>>     I see the issue: We're not passing -fno-stack-protector to
>>     AARCH64 GCC toolchains (although arguably we should just enable
>>     support for it...). Can you try hacking up your tools_def to add
>>     -fno-stack-protector to GCC_AARCH64_CC_FLAGS? It should fix your
>>     build issues.
>>
>>     On Sat, Aug 20, 2022 at 2:51 AM Rebecca Cran <rebecca@bsdio.com>
>>     wrote:
>>
>>         I'm using gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
>>         on Ubuntu 20.04.4, from the Ubuntu repo.
>>
>>         I'm building it with:
>>
>>
>>         export
>>         PACKAGES_PATH=$PWD/edk2:$PWD/edk2-platforms:$PWD/edk2-non-osi
>>         export WORKSPACE=$PWD
>>         export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
>>
>>         . ./edk2/edksetup.sh
>>         build -p ./Features/Ext4Pkg/Ext4Pkg.dsc -a AARCH64 -b RELEASE
>>         -t GCC5
>>
>>
>>         Some of the messages are:
>>
>>
>>         "aarch64-linux-gnu-gcc" -o
>>         /home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.dll
>>         -Wl,--emit-relocs -nostdlib -Wl,--gc-sections -u
>>         _ModuleEntryPoint
>>         -Wl,-e,_ModuleEntryPoint,-Map,/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/DEBUG/Ext4Dxe.map
>>         -z common-page-size=0x20 -z common-page-size=0x1000 -flto -Os
>>         -L/home/bcran/src/beaglebone/edk2/ArmPkg/Library/GccLto
>>         -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64
>>         -Wno-lto-type-mismatch
>>         -Wl,--start-group,@/home/bcran/src/beaglebone/Build/Ext4Pkg/RELEASE_GCC5/AARCH64/Features/Ext4Pkg/Ext4Dxe/Ext4Dxe/OUTPUT/static_library_files.lst,--end-group
>>         -g -Os -fshort-wchar -fno-builtin -fno-strict-aliasing -Wall
>>         -Werror -Wno-array-bounds -include AutoGen.h -fno-common
>>         -ffunction-sections -fdata-sections
>>         -DSTRING_ARRAY_NAME=Ext4DxeStrings -g -Os -fshort-wchar
>>         -fno-builtin -fno-strict-aliasing -Wall -Werror
>>         -Wno-array-bounds -include AutoGen.h -fno-common
>>         -mlittle-endian -fno-short-enums -fverbose-asm
>>         -funsigned-char -ffunction-sections -fdata-sections
>>         -Wno-address -fno-asynchronous-unwind-tables
>>         -fno-unwind-tables -fno-pic -fno-pie -ffixed-x18
>>         -mcmodel=small -flto -Wno-unused-but-set-variable
>>         -Wno-unused-const-variable -D
>>         DISABLE_NEW_DEPRECATED_INTERFACES
>>         -Wl,--script=/home/bcran/src/beaglebone/edk2/BaseTools/Scripts/GccBase.lds
>>         -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 -Wno-error
>>         /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>>         /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>>         `InternalAllocatePool.constprop.0':
>>         /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>>         undefined reference to `__stack_chk_guard'
>>         /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>>         /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: relocation
>>         R_AARCH64_ADR_PREL_PG_HI21 against symbol `__stack_chk_guard'
>>         which may bind externally can not be used when making a
>>         shared object; recompile with -fPIC
>>         /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:(.text.InternalAllocatePool.constprop.0+0xc):
>>         dangerous relocation: unsupported relocation
>>         /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>>         /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:368:
>>         undefined reference to `__stack_chk_guard'
>>         /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>>         /home/bcran/src/beaglebone/edk2/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:382:
>>         undefined reference to `__stack_chk_fail'
>>         /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld:
>>         /tmp/Ext4Dxe.dll.sETaOX.ltrans0.ltrans.o: in function
>>         `OrderedCollectionInsert.constprop.0':
>>         /home/bcran/src/beaglebone/edk2/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c:584:
>>         undefined reference to `__stack_chk_guard'
>>
>>         -- 
>>         Rebecca Cran
>>
>>
>>         On 8/19/22 18:46, Pedro Falcato wrote:
>>>         Hi Rebecca,
>>>
>>>         What EDK2 toolchain are you using? And how is your toolchain
>>>         configured (or where did you get it from?)? It seems that
>>>         it's trying to use the stack protector automatically...
>>>
>>>         Thanks,
>>>         Pedro
>>>
>>>
>>>         On Sat, 20 Aug 2022, 00:40 Rebecca Cran, <rebecca@bsdio.com>
>>>         wrote:
>>>
>>>             ./Features/Ext4Pkg/Ext4Pkg.dsc is also failing - with
>>>             errors about __stack_chk_guard and __stack_chk_fail.
>>>
>>>
>>>             And I get an error from Andy Hayes' email: "Your message
>>>             couldn't be delivered to the recipient because you don't
>>>             have permission to send to it."
>>>
>>>
>>>             -- 
>>>             Rebecca Cran
>>>
>>>
>>>             On 8/19/22 17:35, Rebecca Cran wrote:
>>>>
>>>>             I have an armplatbld.sh script that goes through and
>>>>             tries to build as many of the Arm (AARCH64 and ARM)
>>>>             platforms in edk2-platforms as possible.
>>>>
>>>>             I'm think this used to work for these, but I'm getting
>>>>             some errors now.
>>>>
>>>>             I'm using edk2-platforms
>>>>             46686eeb7e78efe603badd86f13777d9fb070fb8 and edk2
>>>>             e2ac68a23b4954d5c0399913a1df3dd9fd90315d.
>>>>
>>>>
>>>>             Drivers/ASIX/Asix.dsc (fails with undefined references
>>>>             to __stack_chk_guard and __stack_chk_fail)
>>>>
>>>>             Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkPkg.dsc
>>>>             (fails with undefined references to __stack_chk_guard
>>>>             and __stack_chk_fail)
>>>>             Platform/Socionext/DeveloperBox/DeveloperBoxMm.dsc
>>>>             (fails with bad definition for symbol
>>>>             '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol
>>>>             type. For example, absolute and undefined symbols are
>>>>             not supported.)
>>>>
>>>>             Drivers/StandaloneMmCpu/StandaloneMmCpu (fails with
>>>>             undefined references to __stack_chk_guard and
>>>>             __stack_chk_fail)
>>>>             Platform/StandaloneMm/PlatformStandaloneMmPkg/PlatformStandaloneMmRpmb.dsc(fails
>>>>             with bad definition for symbol
>>>>             '_GLOBAL_OFFSET_TABLE_'@0x72d8 or unsupported symbol
>>>>             type.  For example, absolute and undefined symbols are
>>>>             not supported.)
>>>>
>>>>
>>>>             -- 
>>>>             Rebecca Cran
>>>>
>>
>>
>>     -- 
>>     Pedro Falcato
>
>
>
> -- 
> Pedro Falcato
>