Triggering qSymbol packets

[John Williams]

Hi Daniel,

Thanks for quick reply, comments inline below.

Daniel Jacobowitz wrote:
> On Thu, Jan 19, 2006 at 09:58:44AM +1000, John Williams wrote:
> 
>>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.

I agree 100%, and understand statute of limitations re: list support for
5.3.  However a gdb arch forward-port is not something I'm ready to take
on right now.  The CPU vendor (Xilinx, MicroBlaze softCPU) does their
toolchain maintenance in-house, and are settled on gdb5.3 + gcc3.4 for now.

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

Ah ha, good to know.

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

I got it from here:

http://www.cygwin.com/ml/gdb/2002-02/msg00098.html

I looked but didn't find any current references that describe gdbserver
+ pthread debugging - if there's something obvious I'm missing please
let me know.

> The correct sequence is "file" followed by "target remote".  Please try
> that instead.

Will do.

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

OK.  I'm guessing a back-port of the fixup will be much easer (short
term) than a forward port of the entire arch.    Am I maybe
over-estimating the work involved in migrating an arch from gdb 5.3 to 6.4?

Thanks again,

John