Re: Triggering qSymbol packets

[Daniel Jacobowitz <drow@false.org>]

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