[PATCH v2] gdbserver: uclinux: pull in ptrace offset definitions from asm/ptrace.h

[PATCH v2] gdbserver: uclinux: pull in ptrace offset definitions from asm/ptrace.h

[Will Deacon]

When debugging a uclinux target, it is necessary to retrieve the text
and data offsets of the running program in order for symbol resolution
to work correctly.

This patch pulls in definitions for PT_{TEXT,DATA,TEXT_END}_ADDR from
the kernel's exported ptrace header, which can be issued as `magic'
addresses to the PTRACE_PEEKUSER request in order to retrieve the child
offsets.
---

2012-04-17  Will Deacon  <will.deacon@arm.com>

	* linux-low.c: Pull in PT_TEXT_ADDR, PT_TEXT_END_ADDR and
	PT_DATA_ADDR definitions from asm/ptrace.h.

 gdb/gdbserver/linux-low.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
index 35d7e69..93d1f36 100644
--- a/gdb/gdbserver/linux-low.c
+++ b/gdb/gdbserver/linux-low.c
@@ -4772,6 +4772,8 @@ linux_stopped_data_address (void)
 #define PT_TEXT_ADDR     (0x10000*4)
 #define PT_DATA_ADDR     (0x10004*4)
 #define PT_TEXT_END_ADDR (0x10008*4)
+#else
+#include <asm/ptrace.h>
 #endif
 
 /* Under uClinux, programs are loaded at non-zero offsets, which we need
-- 
1.7.4.1

Re: [PATCH v2] gdbserver: uclinux: pull in ptrace offset definitions from asm/ptrace.h

[Pedro Alves]

On 04/26/2012 04:54 PM, Will Deacon wrote:

> When debugging a uclinux target, it is necessary to retrieve the text
> and data offsets of the running program in order for symbol resolution
> to work correctly.
> 
> This patch pulls in definitions for PT_{TEXT,DATA,TEXT_END}_ADDR from
> the kernel's exported ptrace header, which can be issued as `magic'
> addresses to the PTRACE_PEEKUSER request in order to retrieve the child
> offsets.
> ---
> 
> 2012-04-17  Will Deacon  <will.deacon@arm.com>
> 
> 	* linux-low.c: Pull in PT_TEXT_ADDR, PT_TEXT_END_ADDR and
> 	PT_DATA_ADDR definitions from asm/ptrace.h.

>

>  gdb/gdbserver/linux-low.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
> index 35d7e69..93d1f36 100644
> --- a/gdb/gdbserver/linux-low.c
> +++ b/gdb/gdbserver/linux-low.c
> @@ -4772,6 +4772,8 @@ linux_stopped_data_address (void)
>  #define PT_TEXT_ADDR     (0x10000*4)
>  #define PT_DATA_ADDR     (0x10004*4)
>  #define PT_TEXT_END_ADDR (0x10008*4)
> +#else
> +#include <asm/ptrace.h>
>  #endif


I'd much rather we include asm/ptrace.h unconditionally at the top, and wrap the
existing #defines in (a single) #ifndef PT_TEXT_ADDR.  That'll allow easily trimming
that section in a few years time, if/when we bump the minimum kernel version
required past a version that is known to define those for those archs.  If that breaks
one of those archs, we'll hear about it soon enough, don't sweat about it.  :-)

-- 
Pedro Alves

Re: [PATCH v2] gdbserver: uclinux: pull in ptrace offset definitions from asm/ptrace.h

[Will Deacon]

On Thu, Apr 26, 2012 at 05:02:18PM +0100, Pedro Alves wrote:
> On 04/26/2012 04:54 PM, Will Deacon wrote:
> > 
> > diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
> > index 35d7e69..93d1f36 100644
> > --- a/gdb/gdbserver/linux-low.c
> > +++ b/gdb/gdbserver/linux-low.c
> > @@ -4772,6 +4772,8 @@ linux_stopped_data_address (void)
> >  #define PT_TEXT_ADDR     (0x10000*4)
> >  #define PT_DATA_ADDR     (0x10004*4)
> >  #define PT_TEXT_END_ADDR (0x10008*4)
> > +#else
> > +#include <asm/ptrace.h>
> >  #endif
> 
> 
> I'd much rather we include asm/ptrace.h unconditionally at the top, and wrap the
> existing #defines in (a single) #ifndef PT_TEXT_ADDR.  That'll allow easily trimming
> that section in a few years time, if/when we bump the minimum kernel version
> required past a version that is known to define those for those archs.  If that breaks
> one of those archs, we'll hear about it soon enough, don't sweat about it.  :-)

Right-o. I did actually try that initially but it gets fairly ugly if you
want to deal with the case where only a subset of the #defines exist in the
header. If breaking these archs isn't a big concern up-front, then I'm happy
just to test PT_TEXT_ADDR for each of them and be done with it. Plus, that
should take care of the sane configurations.

Will

Re: [PATCH v2] gdbserver: uclinux: pull in ptrace offset definitions from asm/ptrace.h

[Pedro Alves]

On 04/26/2012 05:09 PM, Will Deacon wrote:

> On Thu, Apr 26, 2012 at 05:02:18PM +0100, Pedro Alves wrote:
>> On 04/26/2012 04:54 PM, Will Deacon wrote:
>>>
>>> diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
>>> index 35d7e69..93d1f36 100644
>>> --- a/gdb/gdbserver/linux-low.c
>>> +++ b/gdb/gdbserver/linux-low.c
>>> @@ -4772,6 +4772,8 @@ linux_stopped_data_address (void)
>>>  #define PT_TEXT_ADDR     (0x10000*4)
>>>  #define PT_DATA_ADDR     (0x10004*4)
>>>  #define PT_TEXT_END_ADDR (0x10008*4)
>>> +#else
>>> +#include <asm/ptrace.h>
>>>  #endif
>>
>>
>> I'd much rather we include asm/ptrace.h unconditionally at the top, and wrap the
>> existing #defines in (a single) #ifndef PT_TEXT_ADDR.  That'll allow easily trimming
>> that section in a few years time, if/when we bump the minimum kernel version
>> required past a version that is known to define those for those archs.  If that breaks
>> one of those archs, we'll hear about it soon enough, don't sweat about it.  :-)
> 
> Right-o. I did actually try that initially but it gets fairly ugly if you
> want to deal with the case where only a subset of the #defines exist in the
> header. If breaking these archs isn't a big concern up-front, then I'm happy
> just to test PT_TEXT_ADDR for each of them and be done with it. Plus, that
> should take care of the sane configurations.


Yes, let's try that first please.  Looking at Linux's git, I see that
sh's definition of those symbols came in be6514c6 (all three of them), arm in
68b7f715 (ditto), bfin in 1394f032 (ditto), microblaze in c47f10ba (ditto).  I can't
find any reference to those symbols under arch/m68k or arch/c6x (maybe those are
still out of tree?  though that surprises me, so it may be I should be looking
for something else), but still, I don't think we need to worry about
only a subset being defined.

-- 
Pedro Alves