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

[Kai W. <kai...@gm...>]

On Sat, Dec 29, 2012 at 08:34:26AM +0100, Kai Wang wrote:
> I see. My only concern is that for ld(1) the symbol table can be
> really huge, create another copy of symbol table might be expensive.
> 
> ...
>
> How about, we keep the current elftc_symbol_table_to_image as is, and add another
> more generic transform API:
> 
> void *
> elftc_symbol_table_to_image_generic(Elftc_Symbol_Table *table, size_t *nentries,
>     int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie, void *entry),
>     size_t entsize, void *cookie, Elftc_String_Table **strtab);
> 
> Rationale:
> * API returns untyped buffer.
> * `entsize' spcifies the entry size of the returned buffer.
> * `entry' points to the entry buffer where application provided `transformfn'
>    should fill in. (The API advance the `entry' pointer internally, by adding
>    `entsize')
> 
> The idea is that elftc_symbol_table_to_image_generic can return an array of
> Elf32_Sym/Elf64_Sym instead of GElf_Sym. The returned array can be assigned to
> the `d_buf' field of an Elf_Data descriptor directly, thus avoid one more memory
> copy. (comparing to using gelf_update_sym() on returned GElf_Sym array)
> 
> Also, ld(1) can use this API to transform symbol with customized name,
> as I mentioned in my preivous mail.

Please ignore above comment.

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

Thanks,
Kai