[PATCH] Set dynobj to a normal input file if possible
H.J. Lu
hjl.tools@gmail.com
Fri Apr 22 12:35:00 GMT 2016
More information about the Binutils mailing list
Fri Apr 22 12:35:00 GMT 2016
- Previous message (by thread): [PATCH] Set dynobj to a normal input file if possible
- Next message (by thread): [PATCH] add casts to avoid arithmetic on void *
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Apr 22, 2016 at 1:55 AM, Alan Modra <amodra@gmail.com> wrote: > On Thu, Apr 21, 2016 at 09:49:50PM -0700, H.J. Lu wrote: >> On Thu, Apr 21, 2016 at 8:39 PM, Hans-Peter Nilsson >> <hans-peter.nilsson@axis.com> wrote: >> >> Date: Wed, 20 Apr 2016 20:31:50 -0700 >> >> From: "H.J. Lu" <hongjiu.lu@intel.com> >> > >> >> * elflink.c (_bfd_elf_link_create_dynstrtab): Set dynobj to a >> >> normal input file if possible. >> > >> > Looks like this caused, for a cross -m32 build to arm-unknown-eabi: >> > >> > Running /tmp/hpautotest-binutils/bsrc/src/ld/testsuite/ld-arm/arm-elf.exp ... >> > FAIL: Indirect cross-library function reference >> > FAIL: TLS dynamic application >> > FAIL: GOT relocations in executables >> > FAIL: Thumb and -gc-sections >> > FAIL: Simple dynamic application >> > FAIL: Simple dynamic application without .rel.plt in linker script >> > FAIL: Non-pcrel function reference >> > FAIL: Mixed ARM/Thumb dynamic application >> > FAIL: Mixed ARM/Thumb arch5 dynamic application >> > FAIL: Using Thumb lib by another lib >> > FAIL: MOVW/MOVT against shared libraries >> > FAIL: Mixed ARM/Thumb dynamic application with farcalls >> > FAIL: Mixed ARM/Thumb arch5 dynamic application with farcalls >> > FAIL: TLS long plt >> > FAIL: IFUNC test 7 >> > FAIL: IFUNC test 8 >> > FAIL: IFUNC test 9 >> > FAIL: IFUNC test 10 >> > FAIL: IFUNC test 13 >> > FAIL: IFUNC test 14 >> > FAIL: IFUNC test 15 >> > FAIL: IFUNC test 16 >> > FAIL: Preempt Thumb symbol >> > FAIL: ld-arm/unresolved-1-dyn > > Sounds like something should be fixed in the arm backend. Powerpc64 > deliberately sets dynobj to the linker created "stub bfd", so there > isn't some underlying generic problem with attaching the linker > sections to a linker created bfd. In fact, it's a good idea. > > Hmm. > ld-new: linker stubs: file class ELFCLASSNONE incompatible with ELFCLASS32 > ld-new: final link failed: File in wrong format > > Yes, looks like there needs to be a small tweak. See bfd/elf64-ppc.c > ppc64_elf_init_stub_bfd They need something like elf_elfheader (fake_bfd)->e_ident[EI_CLASS] = (get_elf_backend_data (link_info.output_bfd)->s->arch_size == 64 ? ELFCLASS64 : ELFCLASS32); Currently, we hold linker created dynamic sections in an input shared object, which has its own dynamic sections, when the first input file from linker is a shared object. It may lead to conflicts between linker created dynamic sections and shared object's dynamic sections. We can use a a fake bfd to hold linker created dynamic sections. Unfortunately, it doesn't work due to BFD_LINKER_CREATED. Dynamic sections in bfd with BFD_LINKER_CREATED may be ignored. -- H.J. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-a-fake-bfd-to-hold-linker-created-dynamic-sectio.patch Type: text/x-patch Size: 12553 bytes Desc: not available URL: <https://sourceware.org/pipermail/binutils/attachments/20160422/3a58f3ea/attachment.bin>
- Previous message (by thread): [PATCH] Set dynobj to a normal input file if possible
- Next message (by thread): [PATCH] add casts to avoid arithmetic on void *
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list