PT_TEXT_ADDR on ARM

PT_TEXT_ADDR on ARM

[Simon Richter]

Hi,

I'm a bit unsure on how to proceed here: ARM has two different
definitions for PT_TEXT_ADDR, "49*4" in 2.4 uClinux and "0x10000" in
current Linux, which appears to be used on systems without a MMU as
well. The former definition "emulates" the behaviour of the Coldfire
port, and I've made a working gdbserver for such a system by simply
enabling the #ifdef'd code in linux-low.c, however that will most likely
fail on more recent kernels.

I'd like to prepare a patch that ideally fixes both 2.4 uClinux and 2.6
uClinux (normal Linux doesn't really need the offsets). Should I

 a) check the kernel version
 b) try 0x10000 first, if it returns zero, use the value from 0xc4
 c) use 0x10000 only?

   Simon

Re: PT_TEXT_ADDR on ARM

[Andreas Schwab]

Simon Richter <Simon.Richter@hogyros.de> writes:

> I'd like to prepare a patch that ideally fixes both 2.4 uClinux and 2.6
> uClinux (normal Linux doesn't really need the offsets). Should I
>
>  a) check the kernel version
>  b) try 0x10000 first, if it returns zero, use the value from 0xc4
>  c) use 0x10000 only?

I wonder how 0x10000 can actually work.  I'm pretty sure that
sizeof(struct user) < 0x10000, so this would always return EIO
(according to arch/arm/kernel/ptrace.c:ptrace_read_user).

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: PT_TEXT_ADDR on ARM

[Simon Richter]

Hi,

On Fri, Aug 20, 2010 at 11:06:04AM +0200, Andreas Schwab wrote:

> I wonder how 0x10000 can actually work.  I'm pretty sure that
> sizeof(struct user) < 0x10000, so this would always return EIO
> (according to arch/arm/kernel/ptrace.c:ptrace_read_user).

Good point. Taking this to the kernel mailing list...

   Simon