From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3873 invoked by alias); 4 Mar 2003 02:28:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3817 invoked from network); 4 Mar 2003 02:27:58 -0000 Received: from unknown (HELO TYO202.gate.nec.co.jp) (202.32.8.202) by 172.16.49.205 with SMTP; 4 Mar 2003 02:27:58 -0000 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h242RoU02108; Tue, 4 Mar 2003 11:27:50 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate52.nec.co.jp [10.7.69.198]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h242RnN20727; Tue, 4 Mar 2003 11:27:49 +0900 (JST) Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id h242Rlq20365; Tue, 4 Mar 2003 11:27:48 +0900 (JST) Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id h242RlB09317; Tue, 4 Mar 2003 11:27:47 +0900 (JST) Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 1E775370F; Tue, 4 Mar 2003 11:27:46 +0900 (JST) To: Andrew Cagney Cc: uclinux-dev@uclinux.org, gdb@sources.redhat.com Subject: Re: gdbserver relocation? References: <20030224142831.GB24793@nevyn.them.org> <20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com> Reply-To: Miles Bader System-Type: i686-pc-linux-gnu Blat: Foop From: Miles Bader Date: Tue, 04 Mar 2003 02:28:00 -0000 In-Reply-To: <3E5A3E20.5040706@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2003-03/txt/msg00070.txt.bz2 --=-=-= Content-length: 295 Andrew Cagney writes: > I suspect you want to send something back using qOffsets. Yes, that's exactly what I needed. What do you think of the following patch (I added the `handle_query' target callback, and then provided a linux-low.c implementation)? -Miles Patch: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=gdb-5.3-qoffsets-20030304.patch Content-Description: gdb-5.3-qoffsets-20030304.patch Content-length: 3424 2003-03-04 Miles Bader * target.h (struct target_ops): Add `handle_query' op. * server.c (handle_query): If target has a handle_query op, try to use it first. * linux-low.c (linux_handle_query): New function. (linux_target_ops): Refer to it. diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/target.h gdb-5.3/gdb/gdbserver/target.h --- gdb-5.3.orig/gdb/gdbserver/target.h 2002-08-30 03:50:25.000000000 +0900 +++ gdb-5.3/gdb/gdbserver/target.h 2003-03-04 10:41:49.000000000 +0900 @@ -104,6 +104,11 @@ symbols. */ void (*look_up_symbols) (void); + + /* If non-zero, handle a `q' op from gdb, updating OWN_BUF with the result. + Should return 1 if the op was handled, otherwise 0. */ + + int (*handle_query) (char *own_buf); }; extern struct target_ops *the_target; diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/server.c gdb-5.3/gdb/gdbserver/server.c --- gdb-5.3.orig/gdb/gdbserver/server.c 2002-08-30 03:50:25.000000000 +0900 +++ gdb-5.3/gdb/gdbserver/server.c 2003-03-04 10:43:12.000000000 +0900 @@ -88,6 +88,10 @@ { static struct inferior_list_entry *thread_ptr; + /* First see if the target-specific code wants to deal with this. */ + if (the_target->handle_query && (*the_target->handle_query) (own_buf)) + return; + if (strcmp ("qSymbol::", own_buf) == 0) { if (the_target->look_up_symbols != NULL) diff -ruN -X../cludes gdb-5.3.orig/gdb/gdbserver/linux-low.c gdb-5.3/gdb/gdbserver/linux-low.c --- gdb-5.3.orig/gdb/gdbserver/linux-low.c 2002-11-18 09:40:01.000000000 +0900 +++ gdb-5.3/gdb/gdbserver/linux-low.c 2003-03-04 11:15:14.000000000 +0900 @@ -1228,6 +1229,49 @@ #endif } +/* Some linux-specific handling for extended 'q' packets. */ +static int +linux_handle_query (char *own_buf) +{ +#if defined(PT_TEXT_ADDR) && defined(PT_DATA_ADDR) && defined(PT_TEXT_LEN) + /* Under uClinux, programs are loaded at non-zero offsets, which we need + to tell gdb about. */ + if (strcmp ("qOffsets", own_buf) == 0) + { + unsigned long text, text_len, real_data; + int pid = get_thread_process (current_inferior)->head.id; + + errno = 0; + + text = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_ADDR, 0); + text_len = ptrace (PTRACE_PEEKUSER, pid, (long)PT_TEXT_LEN, 0); + real_data = ptrace (PTRACE_PEEKUSER, pid, (long)PT_DATA_ADDR, 0); + + if (errno == 0) + { + /* Both text and data offsets produced at compile-time (and so + used by gdb) are relative to the beginning of the program, + with the data segment immediately following the text segment. + However, the actual runtime layout in memory may put the data + somewhere else, so when we send gdb a data base-address, we + use the real data base address and subtract the compile-time + data base-address from it (which is just the length of the + text segment). BSS immediately follows data in both cases. */ + unsigned long data = real_data - text_len; + unsigned long bss = data; + sprintf (own_buf, "Text=%lx;Data=%lx;Bss=%lx", text, data, bss); + } + else + sprintf (own_buf, "ENN"); + + return 1; + } +#endif + + /* Something we don't handle. */ + return 0; +} + static struct target_ops linux_target_ops = { linux_create_inferior, @@ -1241,6 +1285,7 @@ linux_read_memory, linux_write_memory, linux_look_up_symbols, + linux_handle_query }; static void --=-=-= Content-length: 158 -- I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff --=-=-=--