public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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
> 


      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