Re: Improved linker-debugger interface

[Gary Benson <gbenson@redhat.com>]

Tom Tromey wrote:
> Gary> I've attached a patch for glibc that implements its side of
> Gary> the interface, designed to apply after the SystemTap support
> Gary> that was added for F15, so if what I've written doesn't make
> Gary> sense then maybe at least the code will!
> 
> Gary> Does this all seem ok?
> 
> It makes sense as far as I understand it.  I don't know glibc very
> well.  I'd suggest asking Andreas Schwab for a review.

Cool, I'll mail him.

> Gary> +void
> Gary> +_dl_debug_state_extended (Lmid_t ns, struct r_debug *r)
> Gary> +{
> Gary> +  if (r->r_state == RT_CONSISTENT)
> Gary> +    {
> Gary> +      LIBC_PROBE (r_debug_mod_complete, 2, ns, r);
> Gary> +    }
> Gary> +  else
> Gary> +    {
> Gary> +      LIBC_PROBE (r_debug_mod_starting, 2, ns, r);
> Gary> +    }
> 
> Will 'ns' give gdb enough information to do its work in the dlmopen
> case?  Or will we want gdb to have access to some other thing?  I am
> wondering Lmid_t is just some internal-to-glibc cookie, where gdb
> will actually want a pointer to some ld.so data structure.  I don't
> actually know anything about this though.

The way glibc handles multiple namespaces is to have a separate
r_debug structure for each one.  The problem is that the current
interface only has provision for exposing one of these to the
debugger, so gdb can only see the initial namespace.  The "r"
argument to the probe is the r_debug structure for the namespace
being modified.

The "ns" argument isn't internal (at least, I don't think it is).
It's the argument you pass to dlmopen to tell it which namespace
to load the library into:

  extern void *dlmopen (Lmid_t nsid, const char *file, int mode);

It might be internal, though.  There are two special values,
LM_ID_BASE (load into the initial namespace) and LM_ID_NEWLM
(create a new namespace and load into that).  It may be that
these are the only values external code should call.  I couldn't
see any obvious way of discovering the namespace id of a loaded
object so you could then load other things into it, but I haven't
looked exhaustively.

Anyway, the "ns" argument isn't enough for gdb to work on, but
the "r" argument is.  I put them both into the probe because
gdb will probably have to maintain some internal list and the
"ns" argument would be useful to track them against (and maybe
get displayed in a column in "info shared").

Cheers,
Gary

-- 
http://gbenson.net/