[Bug ld/19249] New: ld.so not properly linked in with ld --no-allow-shlib-undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19249
Bug ID: 19249
Summary: ld.so not properly linked in with ld
--no-allow-shlib-undefined
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pjones at redhat dot com
Target Milestone: ---
Some time ago I decided to try to enforce some hygiene on one
of the libraries I maintain, and started linking it with
-Wl,--fatal-warnings,--no-allow-shlib-undefined . Then yesterday I
tried to build this tree on an aarch64 machine, and I got this error
while building a .so:
gcc -O2 -g -Werror -Wall -Wsign-compare -Wstrict-aliasing -std=gnu11 \
-fshort-wchar -fPIC -flto -fvisibility=hidden -D_GNU_SOURCE \
-I/root/efivar/src/include/efivar/ -Wmaybe-uninitialized \
-fno-merge-constants \
-Wl,--fatal-warnings,--no-allow-shlib-undefined,--default-symver \
-Wl,-O2 -Wl,--no-undefined-version -shared \
-Wl,-soname,libefivar.so.0 \
-o libefivar.so dp.o dp-acpi.o dp-hw.o dp-media.o dp-message.o \
efivarfs.o export.o guid.o guids.o guid-symbols.o lib.o vars.o \
-ldl
/lib64/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `__pointer_chk_guard@GLIBC_PRIVATE'
/lib64/libc.so.6: undefined reference to `__tls_get_addr@GLIBC_2.17'
/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/libdl.so: undefined
reference to `_dl_rtld_di_serinfo@GLIBC_PRIVATE'
/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/libdl.so: undefined
reference to `_rtld_global@GLIBC_PRIVATE'
/usr/lib/gcc/aarch64-redhat-linux/4.8.5/../../../../lib64/libdl.so: undefined
reference to `_rtld_global_ro@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status
Now, I'm not using those symbols directly, but I am using
dlopen()/dlsym()/dlclose(), and no other libraries. To me it looks like
a couple of things are happening - one is that --no-allow-shlib-undefined
is being applied to all the symbols in the link map, rather than just
the symbols going in to the target. That's a bit unexpected, but not
normally insurmountable. But the other thing, I eventually traced down
to this:
[root@pjones2 ~]# for x in /usr/lib/debug/lib64/*.so.debug ; do \
echo -n "${x}: " ; grep -c _dl_argv ${x} ; done
/usr/lib/debug/lib64/ld-2.17.so.debug: 3
/usr/lib/debug/lib64/libBrokenLocale-2.17.so.debug: 0
/usr/lib/debug/lib64/libSegFault.so.debug: 0
/usr/lib/debug/lib64/libanl-2.17.so.debug: 0
/usr/lib/debug/lib64/libc-2.17.so.debug: 2
/usr/lib/debug/lib64/libcidn-2.17.so.debug: 0
/usr/lib/debug/lib64/libcrypt-2.17.so.debug: 0
/usr/lib/debug/lib64/libdl-2.17.so.debug: 0
/usr/lib/debug/lib64/libm-2.17.so.debug: 0
/usr/lib/debug/lib64/libnsl-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_compat-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_db-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_dns-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_files-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_hesiod-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_nis-2.17.so.debug: 0
/usr/lib/debug/lib64/libnss_nisplus-2.17.so.debug: 0
/usr/lib/debug/lib64/libpthread-2.17.so.debug: 0
/usr/lib/debug/lib64/libresolv-2.17.so.debug: 0
/usr/lib/debug/lib64/librt-2.17.so.debug: 0
/usr/lib/debug/lib64/libthread_db-1.0.so.debug: 0
/usr/lib/debug/lib64/libutil-2.17.so.debug: 0
[root@pjones2 ~]# nm /usr/lib/debug/lib64/ld-2.17.so.debug | grep _dl_argv
00031060 B _dl_argv
00031060 b _dl_argv_internal
[root@pjones2 ~]# nm /usr/lib/debug/lib64/libc-2.17.so.debug | grep _dl_argv
U _dl_argv@@GLIBC_PRIVATE
(The same basic outcome applies to e.g. __tls_get_addr as well.)
So that, I assume, is because large amounts of libdl are really shared
code from ld.so's version. If I add --add-needed, this all works - but I
wouldn't think it would be necessary, since libc.so has "AS_NEEDED (
/lib/ld-linux-aarch64.so.1 )".
So to me it looks like libdl gets those symbols from the dl
implementation in ld.so, and libc.so tells it to add them automatically,
but unless I manually specify --add-needed that doesn't happen. The result is
that using --no-allow-shlib-undefined to guarantee hygiene in a DSO
being built won't work unless you also use --add-needed, which doesn't
seem right. If I use --add-needed, DT_NEEDED just winds up with:
NEEDEDShared library: [libdl.so.2]
NEEDEDShared library: [libc.so.6]
which is the same thing it would be without
-Wl,--add-needed,--no-allow-shlib-undefined
Somewhat confusingly, if I add /lib/ld-linux-aarch64.so.1 to my gcc
command line it works fine (as you&
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 pjones at redhat dot com changed: What|Removed |Added CC||pjones at redhat dot com --- Comment #6 from pjones at redhat dot com --- FYI I've got a partial implementation here: https://github.com/vathpela/binutils/tree/efi-app-aa64 ; it still needs some work. Among other problems, I'm very not thrilled with the way the common header file is generated, as it's racy and failure prone during the build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #8 from pjones at redhat dot com --- (In reply to Tamar Christina from comment #7) > (In reply to pjo...@redhat.com from comment #6) > > FYI I've got a partial implementation here: > > https://github.com/vathpela/binutils/tree/efi-app-aa64 ; it still needs some > > work. Among other problems, I'm very not thrilled with the way the common > > header file is generated, as it's racy and failure prone during the build. > > Hi!, > > Awesome, thanks for getting the ball rolling on this! > > Unfortunately I can't look at the code to give any feedback until the > copyright has been assigned to the FSF. Would it be possible for you to > push the branch to the binutils repo on sourceware? > > Cheers, > Tamar I don't have access push to the binutils repo on sourceware, but Red Hat does have a copyright assignment agreement for this sort of thing. Additionally, there's really nothing here that isn't derived from existing binutils code. >From my perspective, in terms of copyright it is safe to assume this is is acceptable for upstream. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #19 from pjones at redhat dot com --- Can you share your tree so we can replicate this locally? Aside from that, "objdump -f" or even "objdump -x" would be helpful. My initial suspicion is that it's not seeing your binary as relocatable, and EFI_NOT_FOUND is coming from edk2's GetPeCoffImageFixLoadingAssignedAddress(), indicating that the fixed load address is not available. On other arches we solve this with a dummy .reloc section in crt0-efi-ARCH.S (such as this https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/crt0-efi-x86_64.S#L65 ), and of course you'll need the .reloc section in the linker script (such as https://github.com/rhboot/gnu-efi/blob/shim-15.5/gnuefi/elf_x86_64_efi.lds#L28 ). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #22 from pjones at redhat dot com --- Created attachment 13739 --> https://sourceware.org/bugzilla/attachment.cgi?id=13739&action=edit add aarch64_pei_vec to aarch64-*-linux* as well I had to add the attached patch as well to get the targets we build for to include it. With this, some basic support does appear to be functional, though I'm nowhere near done trying it. One thing I have noticed is that the objdump arch list is... a little surprising. We configure the build as such: ../binutils-2.37/configure --disable-dependency-tracking --disable-silent-rules --enable-checking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=aarch64-linux-gnu --program-prefix=aarch64-linux-gnu- --disable-shared --disable-install_libbfd --with-sysroot=/usr/aarch64-linux-gnu/sys-root --enable-deterministic-archives=no --enable-compressed-debug-sections=none --enable-generate-build-notes=no --enable-lto --enable-64-bit-bfd --enable-targets=x86_64-pep --enable-relro=yes --enable-plugins --with-bugurl=http://bugzilla.redhat.com/bugzilla/ When we do that, we get these targets in "objdump --help": aarch64-linux-gnu-objdump: supported targets: elf64-littleaarch64 elf64-bigaarch64 elf32-littleaarch64 elf32-bigaarch64 elf32-littlearm elf32-bigarm pei-aarch64-little elf64-little elf64-big elf32-little elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om elf64-k1om pe-i386 pei-i386 elf32-i386 elf32-iamcu srec symbolsrec verilog tekhex binary ihex plugin It's not surprising to see the x86 targets there (we have --enable-targets=x86_64-pep after all), but I don't see the pe*-aarch64* or efi-* targets here at all, nor do I see them in objcopy. That said, clearly the basic support has *worked* in objdump: random:~/devel/fedora/cross-binutils/f35$ aarch64-linux-gnu-objdump -fh shimaa64.efi shimaa64.efi: file format pei-aarch64-little architecture: aarch64, flags 0x0103: HAS_RELOC, EXEC_P, D_PAGED start address 0x1000 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00094000 1000 1000 1000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 000325f0 00095000 00095000 00095000 2**2 CONTENTS, ALLOC, LOAD, DATA That's a big step forward, and I'd support upstreaming the patch as is (plus my minor tweak) just for that. Next I'll try building stuff more like we do on x86_64, but that probably won't happen until next week due to other commitments. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26206] Add pei-aarch64 support for native EFI support
https://sourceware.org/bugzilla/show_bug.cgi?id=26206 --- Comment #24 from pjones at redhat dot com --- (In reply to Tamar Christina from comment #23) > (In reply to pjo...@redhat.com from comment #22) > > When we do that, we get these targets in "objdump --help": > > aarch64-linux-gnu-objdump: supported targets: elf64-littleaarch64 > > elf64-bigaarch64 elf32-littleaarch64 elf32-bigaarch64 elf32-littlearm > > elf32-bigarm pei-aarch64-little elf64-little elf64-big elf32-little > > elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om > > elf64-k1om pe-i386 pei-i386 elf32-i386 elf32-iamcu srec symbolsrec verilog > > tekhex binary ihex plugin > > > > It's not surprising to see the x86 targets there (we have > > --enable-targets=x86_64-pep after all), but I don't see the pe*-aarch64* or > > efi-* targets here at all, nor do I see them in objcopy. > > It's in the list you pasted, `elf32-bigarm pei-aarch64-little elf64-little` > the sorting is just a bit weird. Indeed, I guess I got a little blinded by all the chaff while I was looking for efi-*. -- You are receiving this mail because: You are on the CC list for the bug.
