From: "Rebecca Cran" <quic_rcran@quicinc.com>
To: <devel@edk2.groups.io>, <pedro.falcato@gmail.com>,
Rebecca Cran <rebecca@bsdio.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
"Leif Lindholm" <quic_llindhol@quicinc.com>,
"Ard Biesheuvel" <ardb+tianocore@kernel.org>,
"Marvin Häuser" <mhaeuser@posteo.de>
Subject: Re: [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_)
Date: Wed, 24 Aug 2022 08:03:28 -0600 [thread overview]
Message-ID: <7146c032-9943-07f8-7246-b11517c26c14@quicinc.com> (raw)
In-Reply-To: <CAKbZUD0kGFngjs+5yEtxZYny_B8vfmP0w2Ojv4k1axLWgfeEMA@mail.gmail.com>
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
>
prev parent reply other threads:[~2022-08-24 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <170CE325F85990DA.4359@groups.io>
2022-08-19 23:37 ` [edk2-devel] Problems building some Arm platforms (__stack_chk_guard/__stack_chk_fail, _GLOBAL_OFFSET_TABLE_) Rebecca Cran
2022-08-19 23:40 ` Rebecca Cran
2022-08-20 0:46 ` Pedro Falcato
2022-08-20 1:51 ` Rebecca Cran
2022-08-20 2:34 ` Pedro Falcato
2022-08-20 3:06 ` Rebecca Cran
2022-08-24 11:05 ` Pedro Falcato
2022-08-24 11:31 ` Ard Biesheuvel
2022-08-24 14:03 ` Rebecca Cran [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7146c032-9943-07f8-7246-b11517c26c14@quicinc.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox