This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdbserver relocation?
- From: Miles Bader <miles at lsi dot nec dot co dot jp>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: uclinux-dev at uclinux dot org, gdb at sources dot redhat dot com
- Date: 04 Mar 2003 11:27:46 +0900
- Subject: Re: gdbserver relocation?
- References: <buok7fqqdzi.fsf@mcspd15.ucom.lsi.nec.co.jp><20030224142831.GB24793@nevyn.them.org><20030224152608.GB2206@gnu.org> <3E5A3E20.5040706@redhat.com>
- Reply-to: Miles Bader <miles at gnu dot org>
Andrew Cagney <ac131313 at redhat dot com> 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:
2003-03-04 Miles Bader <miles at gnu dot org>
* 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
--
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