Triggering qSymbol packets

[John Williams <jwilliams at itee dot uq dot edu dot au>]

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.

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()

To trigger the qSymbol packet (and thus initialise gdbserver's
linuxthreads_db stuff), requires the gdb "sym" command.

>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)

Here's the problem - the sym command resets gdb's symbol table, thus
undoing the relocation done in response to the qOffset packet.  This
means that when linuxthreads_db sends symbol query packets, gdb replies
with *unrelocated* symbol addresses, and everything falls apart.

This is a pretty specific issue - not sure if gdbserver+threads+noMMU
Linux has ever been done before.  So, I suppose my question(s) are:

1. has this been reported as an issue before, maybe resolved in a newer
gdb? (I've googled for 2 days and found no direct answer, just many
different pieces of the puzzle)

2. Am I correct thinking that for gdbserver+threads the user must
manually do the gdb "sym" command to trigger the qSymbol packet, and
thus initialise linuxthreads_db?

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.

Do my ramblings above ring any bells with anyone?  Any suggestions or
advice greatfully appreciated.

Thanks,

John