On Dec 7, 2:57pm, Kumar Gala wrote:
I have two different patches to the ptrace mechanism to add support
for AltiVec registers.
linux-2.4.8-altivec-ptrace.patch: Adds support similar to existing
mechanisms to get/set registers via PEEK/POKE calls extending the FPU
model.
linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
that match sparc/x86 PTRACE_{GET,SET}*REGS. These dump the full register
state in a single call.
Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
for 2.4.x. RedHat is trying to push out some GDB changes for AltiVec that
require closure on this matter.
I would like to better understand your reasons for preferring
PTRACE_{GET,SET}*REGS. Is it just because that's what x86 does
or do you think that this mechanism improves GDB's performance?
My personal opinion is that GETREGS/SETREGS does not greatly enhance
performance. Try running strace on gdb debugging itself on x86 and on
PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
PTRACE_???? calls on x86. (The ???? is printed because strace
doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
tried it just a moment ago using gdb to debug itself and running to a
breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
PEEKUSR/POKUSR calls on PPC. Now, I admit that my testing wasn't very
exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
higher, I think you'd find that calls to PEEKTEXT (for prologue
analysis) would dominate. I.e, the majority of the ptrace() traffic
is due to reading memory, not reading registers.
Furthermore, I think that introducing GETREGS/SETREGS will make
ppc-linux-nat.c (in the GDB sources) more complicated. We'll need
compile time tests to check for the presence of GETREGS/SETREGS and
use these mechanisms if they exist. If they don't, this code will
have to fall back to using the old PEEKUSR/POKEUSR mechanism. Also,
it may be necessary to have runtime tests which attempt to use
GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR. In order to
see just how messy it can get, take a look at i386-linux-nat.c.
For the reasons stated above, I prefer your PEEKUSR/POKEUSR patch.
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, Dec 07, 2001 at 03:23:02PM -0700, Kevin Buettner wrote:
On Dec 7, 2:57pm, Kumar Gala wrote:
quoted
I have two different patches to the ptrace mechanism to add support
for AltiVec registers.
linux-2.4.8-altivec-ptrace.patch: Adds support similar to existing
mechanisms to get/set registers via PEEK/POKE calls extending the FPU
model.
linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
that match sparc/x86 PTRACE_{GET,SET}*REGS. These dump the full register
state in a single call.
Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
for 2.4.x. RedHat is trying to push out some GDB changes for AltiVec that
require closure on this matter.
I would like to better understand your reasons for preferring
PTRACE_{GET,SET}*REGS. Is it just because that's what x86 does
or do you think that this mechanism improves GDB's performance?
I think that it improves performance and that it is generally cleaner.
My personal opinion is that GETREGS/SETREGS does not greatly enhance
performance. Try running strace on gdb debugging itself on x86 and on
PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
PTRACE_???? calls on x86. (The ???? is printed because strace
doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
tried it just a moment ago using gdb to debug itself and running to a
breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
PEEKUSR/POKUSR calls on PPC. Now, I admit that my testing wasn't very
exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
higher, I think you'd find that calls to PEEKTEXT (for prologue
analysis) would dominate. I.e, the majority of the ptrace() traffic
is due to reading memory, not reading registers.
You get more because there are three sets, and we gratuitously fetch
all registers instead of just the needed type of register. I'd bet a
lot that a third of the 18 ????'s I see are for SSE registers and a
third for FP registers. That would bring it down to 6 vs the 16 on PPC
using PEEKUSER.
Also, while I think _GETREGS is better than PEEKUSER, we're talking
here specifically about VRREGS. It's four ptrace calls per vector
register, since ptrace() can only transfer a word at a time (so far at
least; I'm contemplating proposing a change to that). And when you
want one vector register the odds are very good that one wants to get
another.
Also, while single stepping there ought to be no PEEKTEXT calls, only
PEEKUSER, and at least two of them on PPC (in fact we do a lot of
gratuitous poking around in the text segment).
Furthermore, I think that introducing GETREGS/SETREGS will make
ppc-linux-nat.c (in the GDB sources) more complicated. We'll need
compile time tests to check for the presence of GETREGS/SETREGS and
use these mechanisms if they exist. If they don't, this code will
have to fall back to using the old PEEKUSR/POKEUSR mechanism. Also,
it may be necessary to have runtime tests which attempt to use
GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR. In order to
see just how messy it can get, take a look at i386-linux-nat.c.
This part is definitely true.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Is there any reason that we can not spport both methods. There are
applications in which having the ability to get all the registers is a
single syscall is a major performance improvement.
_ kumar
On Fri, 7 Dec 2001, Daniel Jacobowitz wrote:
On Fri, Dec 07, 2001 at 03:23:02PM -0700, Kevin Buettner wrote:
quoted
On Dec 7, 2:57pm, Kumar Gala wrote:
quoted
I have two different patches to the ptrace mechanism to add support
for AltiVec registers.
linux-2.4.8-altivec-ptrace.patch: Adds support similar to existing
mechanisms to get/set registers via PEEK/POKE calls extending the FPU
model.
linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
that match sparc/x86 PTRACE_{GET,SET}*REGS. These dump the full register
state in a single call.
Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
for 2.4.x. RedHat is trying to push out some GDB changes for AltiVec that
require closure on this matter.
I would like to better understand your reasons for preferring
PTRACE_{GET,SET}*REGS. Is it just because that's what x86 does
or do you think that this mechanism improves GDB's performance?
I think that it improves performance and that it is generally cleaner.
quoted
My personal opinion is that GETREGS/SETREGS does not greatly enhance
performance. Try running strace on gdb debugging itself on x86 and on
PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
PTRACE_???? calls on x86. (The ???? is printed because strace
doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
tried it just a moment ago using gdb to debug itself and running to a
breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
PEEKUSR/POKUSR calls on PPC. Now, I admit that my testing wasn't very
exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
higher, I think you'd find that calls to PEEKTEXT (for prologue
analysis) would dominate. I.e, the majority of the ptrace() traffic
is due to reading memory, not reading registers.
You get more because there are three sets, and we gratuitously fetch
all registers instead of just the needed type of register. I'd bet a
lot that a third of the 18 ????'s I see are for SSE registers and a
third for FP registers. That would bring it down to 6 vs the 16 on PPC
using PEEKUSER.
Also, while I think _GETREGS is better than PEEKUSER, we're talking
here specifically about VRREGS. It's four ptrace calls per vector
register, since ptrace() can only transfer a word at a time (so far at
least; I'm contemplating proposing a change to that). And when you
want one vector register the odds are very good that one wants to get
another.
Also, while single stepping there ought to be no PEEKTEXT calls, only
PEEKUSER, and at least two of them on PPC (in fact we do a lot of
gratuitous poking around in the text segment).
quoted
Furthermore, I think that introducing GETREGS/SETREGS will make
ppc-linux-nat.c (in the GDB sources) more complicated. We'll need
compile time tests to check for the presence of GETREGS/SETREGS and
use these mechanisms if they exist. If they don't, this code will
have to fall back to using the old PEEKUSR/POKEUSR mechanism. Also,
it may be necessary to have runtime tests which attempt to use
GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR. In order to
see just how messy it can get, take a look at i386-linux-nat.c.
This part is definitely true.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Is there any reason that we can not spport both methods. There are
applications in which having the ability to get all the registers is a
single syscall is a major performance improvement.
2/c worth.
Yes.
The Linux/PPC kernel supports PEEK/POKE for fetching registers. The
proposed Kernel interface _consistently_ extends that interface using
the exact same mechanims to obtain the altivec regiters. All the
required changes for this have been posted and have been demonstrated to
work.
Separate to that, it has been _proposed_ that the PPC ptrace() interface
be changed so that get/set reg for all register classes be added
(incomplete patch posted). Isn't this separate to the problem at hand?
enjoy,
Andrew
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
The Linux/PPC kernel supports PEEK/POKE for fetching registers. The
proposed Kernel interface _consistently_ extends that interface using
the exact same mechanims to obtain the altivec regiters. All the
required changes for this have been posted and have been demonstrated to
work.
Separate to that, it has been _proposed_ that the PPC ptrace() interface
be changed so that get/set reg for all register classes be added
(incomplete patch posted). Isn't this separate to the problem at hand?
I think you are correct they are separate issues. I posted both methods
so we could decide in which direction we wanted to go with the ptrace
interface. I would like to see the single word at a time interface that
currectly exists be patched to support AltiVec so we can get debugger
support working. I would like this done to the 2.4.x tree.
- kumar
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Andrew Cagney writes:
The Linux/PPC kernel supports PEEK/POKE for fetching registers. The
proposed Kernel interface _consistently_ extends that interface using
the exact same mechanims to obtain the altivec regiters. All the
required changes for this have been posted and have been demonstrated to
work.
Separate to that, it has been _proposed_ that the PPC ptrace() interface
be changed so that get/set reg for all register classes be added
(incomplete patch posted). Isn't this separate to the problem at hand?
If we are going to add a get/set reg interface for the altivec vector
registers, I would rather not extend the peek/poke interface to do
that as well.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Paul,
Can you please make a decision regarding which version (or both) of the
AltiVec ptrace support should go into the kernel.
The two patches are available here:
http://lists.linuxppc.org/linuxppc-dev/200112/msg00107.html
The change is holding up altivec support for gdb.
Thanks
- kumar
On Mon, 17 Dec 2001, Paul Mackerras wrote:
Andrew Cagney writes:
quoted
The Linux/PPC kernel supports PEEK/POKE for fetching registers. The
proposed Kernel interface _consistently_ extends that interface using
the exact same mechanims to obtain the altivec regiters. All the
required changes for this have been posted and have been demonstrated to
work.
Separate to that, it has been _proposed_ that the PPC ptrace() interface
be changed so that get/set reg for all register classes be added
(incomplete patch posted). Isn't this separate to the problem at hand?
If we are going to add a get/set reg interface for the altivec vector
registers, I would rather not extend the peek/poke interface to do
that as well.
Paul.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/