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

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

> Some questions:
> 
> * What is the nested symbol table used for? Could you give an example?

as(1) has a macro facility (.altmacro) which supports 'local' identifiers.
When the macro definition is used, such local names expand to unique
IDs, different for each use of the macro.   These local names go out of
scope when the macro ends, and can shadow symbols already seen in the
assembler source.

> * Is it possible to customize the elftc_symbol_table_to_image?
> 
>   For example, ld(1) sometimes searchs symbols by name and symbol version.
>   To achieve that, ld(1) stores symbol name is the form "symbol@version",
>   "atoi@FBSD_1.0" for instance. When elftc_symbol_table_to_image is called,
>   ld(1) will want the string "atoi" in the string table, not "atoi@FBSD_1.0".

The iterate() API is intended for these kind of transformations.

For example, the application could use the iterate() API to generate
a copy of the symbol table with the names transformed, and then use
elftc_symbol_table_to_image() on the transformed table:

    int
    myfn(Elftc_Symbol *entry, void *cookie)
    {
         Elftc_Elf_Symbol *elfsym = (Elftc_Elf_Symbol *) entry;
         Elftc_Symbol_Table *newtable = (Elftc_Symbol_Table *) cookie;

         ... insert a transformed symbol into 'newtable' ;

	 return (ELFTC_ITERATE_CONTINUE);
    }

    newtable = elftc_symbol_table_create(...);
    status = elftc_symbol_iterate(oldtable, myfn, newtable);

    if (status != ELFTC_ITERATE_SUCCESS)
	error("...");
    else
	elf_section_image = elftc_symbol_table_to_image(newtable, &nentries,
            &strtab);

Alternatively, we could add a 'transformfn()' parameter to the
elftc_symbol_table_to_image() API.   If non-null, the transformfn() would
be called for each entry, prior to the entry's (ELF) in-memory image
being created.  This function could effect an in-place transformation
of the symbol.

The revised prototype would then look like:

    Gelf_Sym *
    elftc_symbol_table_to_image(Elftc_Symbol_Table *table, size_t *nentries,
         int (*transformfn)(Elftc_Elf_Symbol *sym, void *cookie), 
         void *cookie, Elftc_String_Table **strtab);

However, this way seems less general than the first.

> * How does elftc_symbol_table_to_image know where to find symbol size, value,
>   shndx information?
> 
>   Suppose I define a struct:
> 
>   struct _MySymbol {
>         Elftc_Symbol    sym_base;
>         uint64_t            sym_size;
>         uint64_t            sym_value;
>         uint64_t            sym_shndx;
>   }
> 
>   How does elftc_symbol_table_to_image know it should use sym_size,
>   sym_value etc? Or it just return an array of GElf_Sym and let
>   the application to fill in the value?

The _to_image() function only works with subtypes of
"Elftc_Elf_Symbol". This type is:

     typedef struct _Elftc_Elf_Symbol {
        Elftc_Symbol	sym_base;
	Gelf_Sym	sym_elf;
	.. other fields and flags, e.g., controlling sort order that
	   haven't been finalized yet. ..
     } Elftc_Elf_Symbol;

I hadn't provided the definition of "Elftc_Elf_Symbol" in the manual page,
apologies.

> * Is it possible to provide a sort API? e.g.
> elftc_symbol_table_sort(Elftc_Symbol_Table *table,
>   int (*cmp)(Elftc_Symbol *s1, Elftc_Symbol *s2))

Good point.   For tables with entries that have some kind of ordering
associated with them, we could also have a 'step()' API:

    Elftc_Symbol *
    elftc_symbol_table_step(Elftc_Symbol_Table *table,
        Elftc_Symbol *sym, int stepdirection);

where 'stepdirection' would be one of ELFTC_STEP_NEXT | ELFTC_STEP_PREVIOUS.

There is another API that could be useful during disassembly:

    Elftc_Elf_Symbol *
    elftc_symbol_table_lookup_value(Elftc_Symbol_Table *table,
       uint64_t value,  off_t &offset, int searchflags);

This would return the symbol 'closest' to the specified value.
'searchflags' could be ELFTC_SEARCH_FORWARD | ELFTC_SEARCH_BACKWARD.

> * Is it possible to provide a "replace" API?
>   e.g. elftc_symbol_table_replace(Elftc_Symbol_Table *table,
> Elftc_Symbol *s1, Elftc_Symbol *s2)

>   This API can be used when, for example, symbol resolving in ld(1).
>   When application knows symbol s1 exists in the symbol table, it wants
>   to replace s1 with s2 and expects that s2 will have the same
>   position in the symbol table as s1.

Could you clarify what the difference between a replace API and a
'delete(s1)', 'insert(s2)' sequence would be?   Do you need 's2' to be
associated with the same (ELF) symbol table index as 's1'?

> * What kind of internal data structures are you going to use to
>   implement symbol table and string table?

I was thinking of some kind of hash table for name lookups for basic
symbol tables that have no concept of a sort order.  For "Elftc_Elf_Symbol"
entries, we would need additional fields for dealing with ordering
of symbols.  Suggestions welcome.

Regards,
Joseph Koshy