This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Triggering qSymbol packets
- From: Daniel Jacobowitz <drow at false dot org>
- To: John Williams <jwilliams at itee dot uq dot edu dot au>
- Cc: gdb at sourceware dot org
- Date: Wed, 18 Jan 2006 19:19:44 -0500
- Subject: Re: Triggering qSymbol packets
- References: <43CED634.4050503@itee.uq.edu.au>
On Thu, Jan 19, 2006 at 09:58:44AM +1000, John Williams wrote:
> Hi,
>
> The short version:
> Is there a way to trigger GDB to issue a remote qSymbol packet, other
> than the "symbol" command?
>
> The long version:
> I am working on multithreaded gdbserver support for a noMMU
> embedded Linux target (uClinux). The thread library is linuxthreads
> (and linuxthreads_db) in uClibc 0.9.x. gdbserver has all of the
> multithreading hooks and proc-service etc.
>
> The cross-gdb is version 5.3, which should have the necessary remote
> thread code in it.
I strongly recommend an upgrade, as a matter of principle. The current
version is GDB 6.4 and any answers you get off this list may not apply
well to 5.3.
> gdbserver initialises linuxthreads_db hooks in response to a qSymbol
> packet (generated by the gdb "sym" command). This necessarily must come
> after initial remote target connection.
>
> Here's the catch - in uClinux we use qOffset to find out where
> in the flat memory space is the application loaded - qOffset is
> triggered by gdb/remote.c:remote_start_remote()
Right so far...
> To trigger the qSymbol packet (and thus initialise gdbserver's
> linuxthreads_db stuff), requires the gdb "sym" command.
Wrong. It's triggered (A) on connection to a remote target, and (B)
whenever a new file is loaded.
(A) may be broken or missing in 5.3.
> From my searching, it seems the recommended sequence for gdbserver +
> pthreads should be
>
> 1. gdb% target remote host:port
> (connect to gdbserver, send qOffset packet, relocate the objfile
> accordingly)
> 2. gdb% sym myapp.elf
> (send qSymbol packet to gdbserver, to initialise the linuxthreads_db)
Incorrect. Please tell us where you found anything suggesting this.
People keep doing it, and so far, not a one has been able to point to
an incorrect reference (that I remember at the moment, anyway).
The correct sequence is "file" followed by "target remote". Please try
that instead.
> I'm torn on the cleanest way to fix this, if (1) and (2) are true. For
> now I've added a call to remote_check_symbols() inside
> remote_start_remote(), after get_offsets(), and that seems to do what I
> expect. At least it gets further this time, but still doesn't quite work.
Please take a look at the call site for remote_start_remote, in
remote_open_1.
--
Daniel Jacobowitz
CodeSourcery