From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21600 invoked by alias); 19 Jan 2006 00:46:05 -0000 Received: (qmail 21575 invoked by uid 22791); 19 Jan 2006 00:46:03 -0000 X-Spam-Check-By: sourceware.org Received: from gum.itee.uq.edu.au (HELO gum.itee.uq.edu.au) (130.102.66.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Jan 2006 00:45:56 +0000 Received: from filter1.itee.uq.edu.au (filter1.itee.uq.edu.au [130.102.66.19]) by gum.itee.uq.edu.au (8.12.11/8.12.11) with ESMTP id k0J0jrZV014174 for ; Thu, 19 Jan 2006 10:45:53 +1000 (EST) Received: from nut.itee.uq.edu.au (nut.itee.uq.edu.au [130.102.66.13]) by filter1.itee.uq.edu.au (8.12.10/8.12.10) with ESMTP id k0J0jeuh027216 for ; Thu, 19 Jan 2006 10:45:45 +1000 Received: from itee.uq.edu.au (ss1-67.itee.uq.edu.au [130.102.67.251]) by nut.itee.uq.edu.au (8.12.10/8.12.9) with ESMTP id k0J0jeCT028265 for ; Thu, 19 Jan 2006 10:45:40 +1000 (EST) Message-ID: <43CEE12E.90504@itee.uq.edu.au> Date: Thu, 19 Jan 2006 00:50:00 -0000 From: John Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Triggering qSymbol packets References: <43CED634.4050503@itee.uq.edu.au> <20060119001944.GA21282@nevyn.them.org> In-Reply-To: <20060119001944.GA21282@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checked: This message probably not SPAM X-Spam-Score: 0.677 X-Spam-Tests: J_CHICKENPOX_44,J_CHICKENPOX_53,TW_BJ X-Spam-Report: 0.7 points, 8.0 required; 0.1 TW_BJ BODY: Odd Letter Triples with BJ 0.3 J_CHICKENPOX_44 BODY: 4alpha-pock-4alpha 0.3 J_CHICKENPOX_53 BODY: 5alpha-pock-3alpha 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/msg00181.txt.bz2 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