This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFA 0/4] Improved linker-debugger interface


Hi all,

This patch series implements an improved debug interface with the
runtime linker to help address the following bugs:

  https://bugzilla.redhat.com/show_bug.cgi?id=658851
  aka http://sources.redhat.com/bugzilla/show_bug.cgi?id=2328
  "_dl_debug_state() RT_CONSISTENT called too early"

  https://bugzilla.redhat.com/show_bug.cgi?id=698001
  "improve GDB performance on an application performing
  a lot of object loading."

  http://sourceware.org/bugzilla/show_bug.cgi?id=11839
  "gdb does not detect calls to dlmopen"

The current linker-debugger interface has a structure (r_debug)
containing a list of loaded libraries, and an empty function
(_dl_debug_state) for debuggers to set breakpoints on and which
the linker calls both before and after modifying this list.
The problems with the current interface are as follows:

  - There is one place where glibc calls _dl_debug_state earlier than
    Solaris libc.  This is #658851.  It is unlikely that glibc will
    ever be changed to make it compatible with Solaris libc, which
    means GDB reports libraries as loaded and ready before they
    really are.

  - This interface was presumably invented before dlmopen() was, so
    there's only provision in it for one namespace.  In glibc each
    namespace has it's own r_debug structure, but there is no way for
    the linker to communicate the addresses of the others to the
    debugger.  This is PR 11839.

  - In normal use GDB only needs to stop _after_ the list is modified.
    Because _dl_debug_state is called both before and after, GDB stops
    twice as often as it needs to.  There is also no provision for
    communicating what has changed, so GDB must load the entire list
    of loaded libraries at every stop.  This is #698001.
    
  - When stop-on-solib-events is set, however, it is useful to stop
    both before and after library loads.

My proposed solution is to insert a number of named probes into glibc.
My current setup has a probe everywhere _dl_debug_state is called, and
an extra pair to surround relocation events.  New probes can be added
as and when necessary without breaking the interface, and likewise new
arguments can be added to existing probes.

This approach solves the various problems like so:

  - Debuggers can pick and choose which probes to set breakpoints
    on.  By using the "relocation completed" probe instead of the
    one mirroring _dl_debug_state debuggers can stop after relocations
    have occurred, matching the behaviour of Solaris libc.

  - All probes have namespace id and r_debug address arguments,
    allowing debuggers to see namespaces other than the default.

  - When stop-on-solib-events is unset, GDB does not have to stop
    before changes are made, only after.  By disabling the "before"
    breakpoints the number of stops made can be halved.

  - Probes adding new libraries may optionally supply the address
    of the link-map entry of the first newly added library.  This
    enables debuggers to skip past libraries they already saw.

This patch series modifies GDB to search for named probes in
the runtime linker, and to use them instead of _dl_debug_state
if found. If the probes are not found then GDB will fall back
to its previous behaviour.  When probes are used, GDB stops
after relocation.  Stops before changes are made will be
inhibited when stop-on-solib-events is off, and if the linker
supplies the information to allow incremental updating then
GDB will use it.  I've not done anything on the GDB side to
address the dlmopen() issue, but it's now possible to fix it
using the data supplied by the new interface.

Cheers,
Gary

-- 
http://gbenson.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]