gdbserver relocation?

gdbserver relocation?

[Miles Bader]

Hi,

I've been trying to get gdbserver working on the v850, and I'm wondering
the m68k port deals with the address offset between the symbol file and
the actual executable, since unlike in normal linux, the executable gets
relocated at runtime in uClinux in a user visible way.

Does gdb itself have a `set base address' command?  I saw the `section'
command, but it didn't seem to have any useful effect.

It seems to me that it has to be gdb that does the offseting, since
gdbserver doesn't know which values would need adjustment (e.g.,
returned register values).

Thanks,

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: gdbserver relocation?

[Daniel Jacobowitz]

On Mon, Feb 24, 2003 at 05:28:33PM +0900, Miles Bader wrote:
> Hi,
> 
> I've been trying to get gdbserver working on the v850, and I'm wondering
> the m68k port deals with the address offset between the symbol file and
> the actual executable, since unlike in normal linux, the executable gets
> relocated at runtime in uClinux in a user visible way.
> 
> Does gdb itself have a `set base address' command?  I saw the `section'
> command, but it didn't seem to have any useful effect.
> 
> It seems to me that it has to be gdb that does the offseting, since
> gdbserver doesn't know which values would need adjustment (e.g.,
> returned register values).

You're right.  Gdbserver doesn't do anything with symbol lookup at
all; so this has to happen in the client.

You're wrong about referencing the m68k port though.  GDB's m68k/linux
port (I assume that's what you meant) is for Linux, not uClinux.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver relocation?

[Miles Bader]

On Mon, Feb 24, 2003 at 09:28:31AM -0500, Daniel Jacobowitz wrote:
> You're wrong about referencing the m68k port though.  GDB's m68k/linux
> port (I assume that's what you meant) is for Linux, not uClinux.

Actually I was referring to the version of gdbserver that comes with the
uClinux distribution; that's rather hardwired for the m68k, and has certainly
been hacked on to some degree relative to the gdb version.

-Miles
-- 
We live, as we dream -- alone....

Re: gdbserver relocation?

[Andrew Cagney]

Miles,

you should check the following packets:

The `N' reply packet (yes obsolete):
http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#SEC634

The qOffsets packet:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#SEC635

I suspect you want to send something back using qOffsets.

Andrew

Re: gdbserver relocation?

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

Andrew Cagney <ac131313@redhat.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:



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gdb-5.3-qoffsets-20030304.patch --]
[-- Type: text/x-patch, Size: 3424 bytes --]

2003-03-04  Miles Bader  <miles@gnu.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;
+}
+
 \f
 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

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]



-- 
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

Re: gdbserver relocation?

[Daniel Jacobowitz]

On Tue, Mar 04, 2003 at 11:27:46AM +0900, Miles Bader wrote:
> Andrew Cagney <ac131313@redhat.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)?

It looks reasonable to me.  Do you have GDB copyright papers on file?

Content-Description: gdb-5.3-qoffsets-20030304.patch


> +      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.  */

Hmm, this only works if the executable is linked at 0 with data right
after text.  Is that the case for all/most uClinux targets?  I don't
know anything about uClinux.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver relocation?

[Miles Bader]

Daniel Jacobowitz <drow@mvista.com> writes:
> > What do you think of the following patch (I added the `handle_query'
> > target callback, and then provided a linux-low.c implementation)?
> 
> It looks reasonable to me.  Do you have GDB copyright papers on file?

I don't think so; ac131313 sent me a form to do this, which I CC'd to
the FSF a week ago or so, but I haven't received any reply yet (I will
certainly sign an assignment, but it may take a while to get a copyright
disclaimer from my work).

> Hmm, this only works if the executable is linked at 0 with data right
> after text.  Is that the case for all/most uClinux targets?

Yes, so far as I know.

Also, so far there's no standardization of the ptrace PT_TEXT_ADDR &c
macros; I justed added them to the v850 implementation.  The m68knommu
target uses hardwired numeric constants for the same functionality, but
hopefully the maintainers will add defines so this implementation will
work on it (gerg?  davidm?).

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: [uClinux-dev] Re: gdbserver relocation?

[Greg Ungerer]

Hi Miles,

Miles Bader wrote:
> Also, so far there's no standardization of the ptrace PT_TEXT_ADDR &c
> macros; I justed added them to the v850 implementation.  The m68knommu
> target uses hardwired numeric constants for the same functionality, but
> hopefully the maintainers will add defines so this implementation will
> work on it (gerg?  davidm?).

Sure, we can do this.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com

Re: gdbserver relocation?

[Andrew Cagney]

> Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> > What do you think of the following patch (I added the `handle_query'
>> > target callback, and then provided a linux-low.c implementation)?
> 
>> 
>> It looks reasonable to me.  Do you have GDB copyright papers on file?
> 
> 
> I don't think so; ac131313 sent me a form to do this, which I CC'd to
> the FSF a week ago or so, but I haven't received any reply yet (I will
> certainly sign an assignment, but it may take a while to get a copyright
> disclaimer from my work).

It's a legal process and as such can take a little time.  Once the paper 
work is resolved, can you please submit this patch to 
gdb-patches@sources.redhat.com

Andrew

Re: gdbserver relocation?

[Daniel Jacobowitz]

On Mon, Feb 24, 2003 at 10:26:08AM -0500, Miles Bader wrote:
> On Mon, Feb 24, 2003 at 09:28:31AM -0500, Daniel Jacobowitz wrote:
> > You're wrong about referencing the m68k port though.  GDB's m68k/linux
> > port (I assume that's what you meant) is for Linux, not uClinux.
> 
> Actually I was referring to the version of gdbserver that comes with the
> uClinux distribution; that's rather hardwired for the m68k, and has certainly
> been hacked on to some degree relative to the gdb version.

OK - in that case I can't help you, since they never submtted their
patches :P  Didn't notice the cc to uclinux-dev until it rejected my
mail.

Please don't CC addresses that people can't respond to... it's
aggravating.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer