Re: dl symbol search path; Was: Corefile -arch 32 test failures with breakpoint and stacktrace tests

[Roland McGrath <roland@redhat.com>]

Sorry, there is indeed no handy function to help you with this.
I'm sure we will have one eventually.  But doing it really right
does involve really severe amounts of hair, which are all in the
90% to get the last 10%.  The best we can try to do for now is to
stub it out with the trivial naive search, but inside an interface
that asks the question the right way.

The goal is to resolve the ELF symbol reference that would have been
done by referring to a particular name in a particular source context.
When reduced to ELF terms, these components describe a reference:

1. symbol name
2. symbol version binding
3. Dwfl_Module making the reference
4. purpose of the reference

To take each of these in detail:

1. This is the name string used in the ELF symbol table, obviously.
   Resolving what a name used in a particular context in the source
   would actually yield as an ELF name is in fact quite difficult for
   all the complex cases, though 90% of cases are trivial.  I won't go
   into all the gory details of those problems now.  It suffices to
   observe the context necessary to do the best possible job: DWARF
   scope DIE of the desired context, if available (either CU or inner);
   language mode if not implicit from CU; module the reference is being
   made from.

2. The symbol version is approximately a second and third part to the
   symbol name.  It is usually determined (bound) only at link time,
   not by the compiler nor in assembly source code; DWARF is never
   much help figuring it out.  It's only an issue when there are two
   definitions with the same name and different symbol versions.  This
   is likely for e.g. printf and some libstdc++ name-mangled symbols,
   but not very common in Joe Blow's DSO.

   Given a module to consider as the context making the reference, when
   there is an existing external reference in that module to a given
   symbol name, that pretty much makes it easy.  (It's possible to refer
   to two different symbols with the same name and different versions
   inside one module.  But it's so inconvenient that even DSOs like libc
   that define multiple symbols by the same name don't use the versioned
   mechanism to refer to their own symbols between CUs, they just use
   private aliases with different names.)  If there was no reference to
   this symbol linked into the context module, then you can't in all
   cases get an unambiguously right answer.  But there is no information
   helpful to that guessing more granular than just the module as
   context.

3. Every reference is in the context of some module or other, even if not
   in the context of a known CU/scope.  If the context of the user request
   seems to be "global, I don't care exactly what I mean", then either
   this means the main program module, or it means accepting the result is
   a map of different results given different contexts in cases of ambiguity.

4. The purposes for reference that we must distinguish are:
   a. like a PLT reloc, a jump target
   b. like a COPY reloc, an initializer value
   c. like all others, an object address
   
   For "func(args)", and probably for a breakpoint on func, it's (a).
   For "&func", it's (c).  In module A using PIC that calls func in module B,
   (a) means func's real definition in B; (c) means func's PLT symbol in A.

   For a non-PIC object (i.e. the main program) that does "extern int foo;"
   and links to a DSO that does "int foo = 1;", then (b) is foo's symbol in
   the main program; (c) is foo's definition in the DSO.  When the
   reference is to "the variable foo", to see its live value in the
   program, change it, place a watchpoint, it's (c).  When the reference is
   to print the static initializer value, offline or before the program has
   finished dynamic loading at startup/dlopen, then it's (b).

   The (a) vs (c) and (b) vs (c) distinctions often apply to a module's
   own references to its own symbols, though I used less confusing examples
   above.  So purpose is relevant to every lookup.

   At high level, we can describe the purpose distinctions as "for actual
   code address", "for static initializer data", and "for object address".

So, gleaned from that, the lookup function should have at hand:

* symbol name
* DWARF scope DIE of the desired context, if available
* language mode, if no scope/CU context
* referring module, if available
* purpose of reference

Furthermore, it should be able to return ambiguous results.  That is,
the result of the lookup is either "this one is it", or a list of
candidates each annotated with "this would be it if you were to give
foobar as the referring module" and/or "this would be it if this
reference by module foobar were resolved to symbol version V in module
M".  It's fine for now if the only plan for the ambiguous cases is an
exception "couldn't figure it out" or even "blindly pick the first one".
But one should contemplate how the description of the ambiguity and the
options for resolving it might percolate up to the user.


Thanks,
Roland