Re: AltiVec register ptrace support

Re: AltiVec register ptrace support

[Kevin Buettner]

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

Re: AltiVec register ptrace support

[Daniel Jacobowitz]

On Fri, Dec 07, 2001 at 03:23:02PM -0700, Kevin Buettner wrote:
> 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?

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

Re: AltiVec register ptrace support

[Kumar Gala]

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:
> > 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?
>
> 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/
>

Re: AltiVec register ptrace support

[Jason R Thorpe]

On Fri, Dec 14, 2001 at 12:52:33PM -0600, Kumar Gala wrote:

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

I'll chime in...

Other systems that support ptrace(2) don't have PEEK/POKE/READ_U/WRITE_U
methods.

I'm currently working on AltiVec for NetBSD/powerpc, and ptrace(2) interface
for AltiVec is going to look like:

	PT_GETALTIVECREGS
	PT_SETALTIVECREGS

...both of which using the following structure as an argument:

	struct vreg {
		uint32_t vreg[32][4];	/* vector register contents */
		register_t vscr;	/* vector status and control reg */
		register_t vrsave;	/* SPR 238 */
	};

This is consistent with how e.g. SSE/SSE2 registers are handled on
NetBSD/i386 (PT_GETXMMREGS/PT_SETXMMREGS).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: AltiVec register ptrace support

[Andrew Cagney]

> 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

Re: AltiVec register ptrace support

[Kumar Gala]

> 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

Re: AltiVec register ptrace support

[Paul Mackerras]

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.

Re: AltiVec register ptrace support

[Kumar Gala]

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