This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdbserver relocation?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]