RFC: [PATCH] ELF: Don't require section header on ELF objects
Kaylee Blake
klkblake@gmail.com
Mon Mar 9 13:28:59 GMT 2020
More information about the Binutils mailing list
Mon Mar 9 13:28:59 GMT 2020
- Previous message (by thread): RFC: [PATCH] ELF: Don't require section header on ELF objects
- Next message (by thread): RFC: [PATCH] ELF: Don't require section header on ELF objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 9/3/20 11:46 pm, Florian Weimer wrote: > * Kaylee Blake: > >> On 9/3/20 11:36 pm, Florian Weimer wrote: >>> * Kaylee Blake: >>> >>>> On 9/3/20 6:43 pm, Florian Weimer wrote: >>>>> * H. J. Lu: >>>>> >>>>>> Section header isn't mandatory on ELF executable nor shared library. >>>>>> This patch adds a new linker option, -z nosectionheader, to omit ELF >>>>>> section header when building an executable or shared library, adds >>>>>> an objcopy and strip option, --remove-section-header, to remove ELF >>>>>> section header from an executable or shared library. >>>>>> >>>>>> The PT_DYNAMIC segment contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, >>>>>> DT_STRTAB, DT_SYMTAB, DT_STRSZ and DT_SYMENT, which can be used to >>>>>> reconstruct dynamic symbol table when section header isn't available. >>>>>> For DT_HASH, the number of dynamic symbol table entries equals the >>>>>> number of chains. For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols >>>>>> with non-STB_LOCAL indings are in hash table. Since in dynamic symbol >>>>>> table, all symbols with STB_LOCAL binding are placed before symbols with >>>>>> other bindings and all defined symbols are placed before undefined ones, >>>>>> the highest symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest >>>>>> dynamic symbol table index. >>>>> >>>>> Does this patch enable ld to use shared objects without a section >>>>> header for linking? >>>>> >>>>> I think the NEWS and manual update should clarify this. >>>>> >>>>> In my opinion, it should NOT be possible to link against objects >>>>> without section headers. Lack of section headers clearly marks the >>>>> object as a run-time only object. This is useful if you want to >>>>> prevent developers to create DT_NEEDED dependencies on internal >>>>> libraries, for example. >>>> >>>> For shared objects without debug symbols, the section header table is >>>> ~2kB on average of redundant data. I'm also not a fan of the >>>> inconsistency of having shared libraries that the dynamic linker is >>>> perfectly happy to load, but ld can't link against, especially since >>>> this seems like an oversight rather than an intended design decision. >>> >>> You didn't answer my question. 8-) >> >> Ah, yes, sorry. It does enable that; that was my primary motivation for >> my part in it. > > I think that's conceptually the wrong thing to do for ELF, sorry. If > there is no section header, the object should be unlinkable. The > linker should not use the dynamic segment to locate the symbol > information, only the dynamic section (in case the link ABI and > run-time ABI are different). I'm confused by your comment about link and run-time ABIs differing; surely if the ABI at runtime differs from the ABI at link time, you are just going to crash at runtime? -- Kaylee Blake <klkblake@gmail.com> C is the worst language, except for all the others.
- Previous message (by thread): RFC: [PATCH] ELF: Don't require section header on ELF objects
- Next message (by thread): RFC: [PATCH] ELF: Don't require section header on ELF objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list