[RFC PATCH] dwarf-reader: support ksymtab symbol lookup by name

[Dodji Seketeli]

Hello Matthias,

[...]

Matthias Maennich <maennich@google.com> a écrit:

>>> The ksymtab address entry might not be actually pointing to a GLOBAL
>>> visible symbol in .symtab of the same binary. E.g. that happens when
>>> compiling the kernel with clang's -fsanitize-cfi* and friends.

[...]

On Tue, Jan 07, 2020 at 06:07:49PM +0100, Dodji Seketeli wrote:

>>Just so that I understand better; in cases where the address part of a
>>ksymtab entry cointains a number that is not the address of a GLOBAL
>>visible symbol in .symtab, what does that number represent?
>>
>>I am thinking maybe that number is the address of an artificial "stub"
>>symbol that would have been generated by the sanitizer, but I am not
>>sure at this point.

Matthias Maennich <maennich@google.com> a écrit:


> The issue is caused by the modifications happening to .symtab and
> __ksymtab when using clang's -fsanitize-cfi* and friends.
>
> __ksymtab contains entries like (ignoring namespaces and PREL32 for simplicity):
>
> ksymtab {
>   addr  -> referring to an entry in .symtab
>   name  -> referring to an entry in __ksymtab_strings
> }
>
> Before CFI, .symtab would contain an entry for the symbol referring to
> the relevant .text.<symbol> section and ksymtab.addr would contain that
> particular addr that is referred to by .symtab.
>
> ksymtab.addr -> .symtab -> .text.<symbol>
>
> Now, with CFI, the .symtab contains two entries per symbol:
>
>  <symbol> points to the .text.<symbol> as before
>
>  <symbol>.cfi_jt points to an entry in the cfi jump table that is used
>  to reach the relevant .text.<symbol> section at runtime
>
> The newly introduced symbol is a HIDDEN entry in the .symtab.
>
> Unfortunately, ksymtab.addr refers now to the new entry, but since it is
> hidden, will not be discovered by the usual lookups in libabigail. Even
> if we would find the hidden symbol, the debug info associated with it is
> not sufficient for ABI analysis.

Thank you for the information.

In my understanding, it's true that a ksymtab.addr referring to the
hidden entry of the cfi jump is not useful to us and in any case,
looking that up in the map read_context::fun_entry_addr_sym_map() would
yield an empty result.

But then, if you want to look up the symbol from its name, my
understanding is that we already have a map, in libabigail, that
associates symbol names to the symbols.  That map is returns by the
function read_context::fun_syms().  Here is it's documentation:

  /// Getter for the map of function symbols (name -> sym).
  ///
  /// @return a reference to the map of function symbols.
  const string_elf_symbols_map_type&
  fun_syms() const

Is there a reason why looking up the symbol from that map, once you've
got its name wouldn't work?

Thanks.

-- 
		Dodji