From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22289 invoked by alias); 18 Jan 2006 23:59:15 -0000 Received: (qmail 22281 invoked by uid 22791); 18 Jan 2006 23:59:14 -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; Wed, 18 Jan 2006 23:59:11 +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 k0INx4N0005861 for ; Thu, 19 Jan 2006 09:59:04 +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 k0INwouh022924 for ; Thu, 19 Jan 2006 09:58:55 +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 k0INwnCT027784 for ; Thu, 19 Jan 2006 09:58:50 +1000 (EST) Message-ID: <43CED634.4050503@itee.uq.edu.au> Date: Thu, 19 Jan 2006 00:19: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: Triggering qSymbol packets 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/msg00179.txt.bz2 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