This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld: how can I get at the final strtab and symtab at link time?

On 4 Jul 2019, Nick Alcock said:

> So I'm working on .ctf section support for GNU ld and have run into a
> bit of a problem.
> CTF has internal string tables, meant to record things like structure
> member names that do not appear in the ELF strtab. It also has a pair of
> tables laid out in the same order as the final symtab, giving CTF types
> for (most) STT_OBJECTs and functions (for functions, the return type and
> the types of all args).
> We want to deduplicate the internal strtab against the ELF strtab, which
> means we need to get involved after the ELF strtab is laid out:
> similarly, to reorder our tables to match the ordering of the ELF
> symtab, we need to do things after the symtab is laid out, because our
> tables are laid out in 1:1 correspondence with the ELF symbol tables,
> after everything has been emitted into them

A disgusting hack that might just work is to detect whether any CTF
sections are present in the input, then if they are, *after ldwrite* but
before we get rid of all the input bfds, reopen the executable we just
wrote out -- which definitely has final-disposition strtab and symtab --
do all the CTF linking work, then invoke objcopy or in some other way
arrange to the resulting merged CTF section to the binary. (Relocatable
links don't need any of this, but only need to merge the CTF sections'
types sections, which we can do earlier, before ldwrite even starts: the
ELF symtab and strtab-related stuff only happens for final links, on the
grounds that before then we cannot rely on the symtab or strtab contents
not changing.)

Calling objcopy like this is *horrible*, but given that the strtab is
still being assembled via calls to elf_link_output_symstrtab() long
after the final sizes and file positions of all other sections have been
computed, I can't currently see any other approach that would even begin
to work. We can't even get in right after the call to
_bfd_elf_strtab_finalize(), because that is some way after everything
else's size has been worked out, including the very section we want to
deduplicate against that strtab (and thus shrink) -- and until that
point, we don't even know what strings will be in the strtab, let alone
what their section-relative offsets are.

... any better suggestions? Anyone?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]