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

["Matthias Maennich via libabigail" <libabigail@sourceware.org>]

Hi Dodji!

On Tue, Jan 07, 2020 at 06:07:49PM +0100, Dodji Seketeli wrote:
> Hello,
>
> Thank you for working on this.
>
> Before going deep in the patch itself, I'd have some questions about
> basic understanding of what is going on, if you don't mind.
>
> 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.
>
> 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.

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.

One way to get out of this without breaking other binary versions (which
we have) is to make this lookup by name rather by address. That is what
this change attempts.

> > In contrast, the ksymtab.name entry has to match an entry in
> > .symtab. It would otherwise upset linkers very much.
>
> It does seem odd to me that the address part of a ksymtab entry does not
> point to a symbol in .symtab that we can use, and yet the name part of
> that same entry points to the name of a symbol in .symtab that we can
> use.  Doesn't it?  I guess the information I am missing is related to my
> earlier question.

Let me know if you need more clarifications than the above. Took me a
bit to get my head around that as well :-)

Anyway, it also made me thinking of doing _all_ ksymtab lookups by name.
Then we could simplify the code at this point. We would just need to
make the by-name access a bit more convenient.

Cheers,
Matthias

> Thanks,
>
> --
> 		Dodji