This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

[Bug libc/2328] _dl_debug_state() RT_CONSISTENT called too early


http://sourceware.org/bugzilla/show_bug.cgi?id=2328

--- Comment #9 from Gary Benson <gbenson at redhat dot com> 2011-08-16 15:10:13 UTC ---
(In reply to comment #6)
> If we need more state information it is better to expose some APIs.  We have
> libthread_db, maybe we need librtld_db as well.  If we'd have a specification
> of what information of the implementation gdb currently contains and what it
> still wants we can design such a library.
> 
> I guess I am waiting for gdb people to provide this information.

What gdb needs is not so much more information per se as more (and more
finely-grained notifications).  I would say as a minimum a new interface should
allow debuggers to do everything that the existing interface does, so the new
interface needs to be able to notify the debugger at every point the existing
interface does.  Then, to be able to fix this particular issue (which
incidentally prevents gdb from being able to debug programs that dlopen
libpthread) we need a notification after relocation is complete -- basically in
the location John Reiser proposed moving the RT_CONSISTENT notification to.  In
the probes-based interface I proposed I also added a notification before
relocation occurs, for symmetry with all the other notifications which all have
before and after versions.

We also need the ability to be able to enable and disable the various
notifications.  In the probes-based interface this is done on the gdb side:
each notification has its own address, so debuggers can install breakpoints on
only the set of notifications they care about.  Another way to do this would be
to have one breakpoint address but calls into glibc to enable/disable the
various notifications individually.  I didn't go down that route as it would
mean debuggers altering the controlled program more than necessary, but it's
not unfeasable.

Also, to allow debugging of programs that use dlmopen the interface needs to
provide some way for debuggers to inspect namespaces other than the default. 
The existing interface only exposes the initial namespace so any others are
effectively invisible.

Finally, it is desirable to minimise the amount of data than needs to flow
between the inferior and the debugger, as this has performance issues when
debugging applications with large numbers of shared libraries, especially when
debugging remotely.  The probes-based interface as it stands does not do this
yet, but it could be extended to do so without breaking compatibility.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


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