From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: ptrace(PTRACE_PEEKUSER, ..., PT_TEXT_ADDR, ...)
Date: Wed, 1 Sep 2010 08:17:01 +0100 [thread overview]
Message-ID: <20100901071701.GC8142@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20100820124118.GC6950@richter>
On Fri, Aug 20, 2010 at 02:41:28PM +0200, Simon Richter wrote:
> when patching gdbserver to work on MMUless ARM systems I found that
> there are two definitions for the magic values for PT_TEXT_ADDR (and the
> related fields) in different Linux versions. uClinux 2.4 kernels use
> values starting from 0xc4 (the same as the Coldfire port), while 2.6
> based kernels use magic numbers starting from 0x10000, which were
> introduced in 68b7f7153fa58df710924fbb79722717d2d16094 .
>
> As has been pointed out by Andreas Schwab from SuSE, the code
> responsible for returning the text segment address is never reached
> because the lines immediately before the code added in the commit
> already filter these out and return -EIO.
I've always regarded this PT_* stuff as a hack around the problem at
hand - and as you point out below...
> So apparently the new values have never really been in use (so I
> wouldn't consider them part of the kernel interface), and the old values
> now point to something else (because VFP registers were added to struct
> user).
... it has the potential to break horribly when the original API is
extended through additional hardware features.
Maybe this is something which should be fixed properly by introducing
a proper cross-arch API for getting this information.
next prev parent reply other threads:[~2010-09-01 7:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-20 12:41 ptrace(PTRACE_PEEKUSER, ..., PT_TEXT_ADDR, ...) Simon Richter
2010-09-01 7:17 ` Russell King - ARM Linux [this message]
2010-09-01 8:01 ` Simon Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100901071701.GC8142@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.