From: "Smith, Stephen \(SWCOE\)" <Stephen.Smith@honeywell.com>
To: <gdb@sourceware.org>
Subject: RE: [rfc / remote protocol] Remote shared library events
Date: Wed, 09 May 2007 20:40:00 -0000 [thread overview]
Message-ID: <EF244E26469B2C42B2B72AC465843D6B04E612F1@AZ18EV808.global.ds.honeywell.com> (raw)
In-Reply-To: <20070509201627.GA23422@caradoc.them.org>
I used an earlier version of Daniel's patch to implement do something
similar on the os that I am working on. So I am interested in seeing
this go through.
sps
-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
Behalf Of Daniel Jacobowitz
Sent: Wednesday, May 09, 2007 1:16 PM
To: gdb-patches@sourceware.org
Cc: gdb@sourceware.org
Subject: [rfc / remote protocol] Remote shared library events
System V platforms (like GNU/Linux, Solaris, BSD, et cetera) have a
mostly userspace shared library loader. That means the loader already
has to keep track of what libraries are mapped, and GDB uses the same
data structures that the loader does to find the list. There's also
typically an application function like _dl_debug_state which is called
at every event; GDB can set a breakpoint there to be notified of
events.
Not all platforms work this way. The exceptions I'm looking at
recently are DLL-based platforms: Windows and SymbianOS. Both use an
OS-level loader instead. You have to query the OS to get the list
of libraries, and the OS provides event notification directly instead
of via a magic breakpoint. We can't poke and prod at the OS directly
during remote debugging, so to implement DLL support for these
platforms I extended the remote protocol.
The additions are three new stop replies for the "T" packet to report
events (load, unload, and dll for "something more complicated than
just a load or unload") and two new packets (qfDllInfo and qsDllInfo)
to query the current state. Detailed documentation is below and the
patch is attached.
This patch introduces a new solib_ops vector in solib-target.c. This
vector is target driven; it maintains a list based on the query packet
and event notices, instead of looking through memory.
I have tested this code on SymbianOS, Cygwin, and MinGW32. Pedro
Alves has tested a slightly earlier version on Windows CE (and wrote
the gdbserver bits I used to test it on Windows - thanks!).
What do you think, Kevin especially? I'm not entirely thrilled with
the way this interacts with other solib_ops vectors, but I'm not
unhappy with it either.
Eli, do the manual changes look OK?
All comments welcome!
next prev parent reply other threads:[~2007-05-09 20:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-09 20:16 Daniel Jacobowitz
2007-05-09 20:40 ` Smith, Stephen (SWCOE) [this message]
2007-05-10 3:18 ` Eli Zaretskii
2007-05-16 22:59 ` Jim Blandy
2007-05-18 0:27 ` Daniel Jacobowitz
2007-05-18 16:04 ` Jim Blandy
2007-05-18 16:10 ` Daniel Jacobowitz
2007-05-18 16:49 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EF244E26469B2C42B2B72AC465843D6B04E612F1@AZ18EV808.global.ds.honeywell.com \
--to=stephen.smith@honeywell.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox