From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8045 invoked by alias); 19 Jan 2006 00:19:50 -0000 Received: (qmail 8037 invoked by uid 22791); 19 Jan 2006 00:19:49 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 19 Jan 2006 00:19:47 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EzNWi-0005Z1-JH; Wed, 18 Jan 2006 19:19:44 -0500 Date: Thu, 19 Jan 2006 00:46:00 -0000 From: Daniel Jacobowitz To: John Williams Cc: gdb@sourceware.org Subject: Re: Triggering qSymbol packets Message-ID: <20060119001944.GA21282@nevyn.them.org> Mail-Followup-To: John Williams , gdb@sourceware.org References: <43CED634.4050503@itee.uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CED634.4050503@itee.uq.edu.au> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00180.txt.bz2 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