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

[Nick Alcock <nick dot alcock at oracle dot com>]

On 4 Jul 2019, Nick Alcock uttered the following:

> 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

OK, I may have something. I think I can do strtab deduplication
immediately after the call to _bfd_elf_strtab_finalize(), then write out
the CTF section itself much later, right before the call to
elf_final_link_free(). By this point the symtab section is finalized as
well and I can reshuffle everything appropriately.

I *think*. At least it's not horribly tangled up with everything else
like I feared it might be.

Let's see if I can make this work.

-- 
NULL && (void)