Re: [Elftoolchain-developers] Review request: elftc_string_table*(3) and elftc_symbol_table*(3)

[Joseph K. <jk...@us...>]

Thank you for your review comments.

kw> I see. My only concern is that for ld(1) the symbol table can be
kw> really huge, create another copy of symbol table might be
kw> expensive.

You are right.  The proposed *_to_image() API is is flawed, because it
will lead to unnecessary memory allocation and data copying when used
with libelf.

kw> On a second thought, you're right, ld(1) can use the `iterate' API
kw> to create the Elf32_Sym/Elf64_Sym table directly, thus all of the
kw> above is not needed.

Agreed.

We would also need a `elftc_symbol_table_count()` API to help the
application size its buffers.  If we are implementing a _step() API,
the application can step through the symbol table, filling its buffer
and discarding the symbols it does not want.

(If we are supporting *_step() for unsorted tables too, then the
*_iterate() API would be redundant).

kw> The `replace' API depends on the implementation, see below. And you're
kw> right, I want 's2' to have the same symbol table index as 's1'.

Ok.

kw> I was thinking the symbol table is both a doublely linked list and
kw> a hash table. The table is iterated in insertion order, or sort
kw> order if the `sort' API has been called. The `replace' API make
kw> sure symbol `s2' has the same position in the linked list as
kw> symbol `s1', thus the same symbol index. This is useful for ld(1).

kw> If it's implemented as above, the `step' API can be used in sorted
kw> and unsorted tables?

Yes, that would be a good way to implementing it, given the desired
behaviors for the _step() and _replace() APIs.

I will update the manual page to reflect our current understanding of the
API shortly.

Regards,
Joseph Koshy