No PTRACE_READDATA for archs other than SPARC?

No PTRACE_READDATA for archs other than SPARC?

[Pradeep Padala]

Hi,
   I was trying to understand ptrace code in kernel. It seems there's
no PTRACE_READDATA for architectures other than sparc and sparc64.
There's a function named ptrace_readdata() in kernel/ptrace.c but I
couldn't find a way to invoke it from user space. Is the feature
missing? or Is it intended?
   Another thing I noticed, the prototype for do_ptrace() in
   arch/sparc/kernel/ptrace.c is

   asmlinkage void do_ptrace(struct pt_regs *regs)

   I thought it should be some thing like
   asmlinkage int sys_ptrace(long request, long pid, long addr, long
data)

   It would be great if some one can answer it.

Thank You,
Pradeep Padala

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl
--

Re: No PTRACE_READDATA for archs other than SPARC?

[David S. Miller]

   From: Pradeep Padala <ppadala@cise.ufl.edu>
   Date: Sun, 19 May 2002 23:08:36 -0400 (EDT)

      I was trying to understand ptrace code in kernel. It seems there's
   no PTRACE_READDATA for architectures other than sparc and sparc64.
   There's a function named ptrace_readdata() in kernel/ptrace.c but I
   couldn't find a way to invoke it from user space. Is the feature
   missing? or Is it intended?

Only Sparc implements this, that is correct.

If other platforms added PTRACE_READDATA support, they would
also need to add some way to do a feature test for it's presence
so that GDB and other debugging code could actually make use
of it portably.

      Another thing I noticed, the prototype for do_ptrace() in
      arch/sparc/kernel/ptrace.c is
   
      asmlinkage void do_ptrace(struct pt_regs *regs)
   
      I thought it should be some thing like
      asmlinkage int sys_ptrace(long request, long pid, long addr, long
   data)

The return values are set directly in the user's pt_regs.

Re: No PTRACE_READDATA for archs other than SPARC?

[Frank Schaefer]

On Mon, 2002-05-20 at 06:40, David S. Miller wrote:
>    From: Pradeep Padala <ppadala@cise.ufl.edu>
>    Date: Sun, 19 May 2002 23:08:36 -0400 (EDT)
> 
>       I was trying to understand ptrace code in kernel. It seems there's
>    no PTRACE_READDATA for architectures other than sparc and sparc64.
>    There's a function named ptrace_readdata() in kernel/ptrace.c but I
>    couldn't find a way to invoke it from user space. Is the feature
>    missing? or Is it intended?
> 
> Only Sparc implements this, that is correct.

... and that's the reason why GDB don't support follow-fork-mode for the
intel pltform - right? ( I had a related thread on the gdb mailing list
not soo long ago. )

Frank

Re: No PTRACE_READDATA for archs other than SPARC?

[Pradeep Padala]

> Only Sparc implements this, that is correct.
> 
> If other platforms added PTRACE_READDATA support, they would
> also need to add some way to do a feature test for it's presence
> so that GDB and other debugging code could actually make use
> of it portably.

You mean, it's an undocumented feature for sparc?

If I want to add it to i386, what do I need to add so that
gdb/debuggers know that the feature exists.


> The return values are set directly in the user's pt_regs.

I get it. Thanx for the info

--pradeep

Re: No PTRACE_READDATA for archs other than SPARC?

[David S. Miller]

   From: Frank Schaefer <frank.schafer@setuza.cz>
   Date: 20 May 2002 08:29:50 +0200

   On Mon, 2002-05-20 at 06:40, David S. Miller wrote:
   > Only Sparc implements this, that is correct.
   
   ... and that's the reason why GDB don't support follow-fork-mode for the
   intel pltform - right? ( I had a related thread on the gdb mailing list
   not soo long ago. )

I can't see any reason why lack of PTRACE_READDATA prevents follow
fork mode support in GDB.  But then again the GDB maintainers are a
bunch of pinheads so...

Re: No PTRACE_READDATA for archs other than SPARC?

[Daniel Jacobowitz]

On Sun, May 19, 2002 at 09:40:53PM -0700, David S. Miller wrote:
>    From: Pradeep Padala <ppadala@cise.ufl.edu>
>    Date: Sun, 19 May 2002 23:08:36 -0400 (EDT)
> 
>       I was trying to understand ptrace code in kernel. It seems there's
>    no PTRACE_READDATA for architectures other than sparc and sparc64.
>    There's a function named ptrace_readdata() in kernel/ptrace.c but I
>    couldn't find a way to invoke it from user space. Is the feature
>    missing? or Is it intended?
> 
> Only Sparc implements this, that is correct.
> 
> If other platforms added PTRACE_READDATA support, they would
> also need to add some way to do a feature test for it's presence
> so that GDB and other debugging code could actually make use
> of it portably.

Not really, we should just get EINVAL (ENOSYS?) back when we try to use
it, right?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: No PTRACE_READDATA for archs other than SPARC?

[Daniel Jacobowitz]

On Mon, May 20, 2002 at 02:18:00PM -0700, David S. Miller wrote:
>    From: Frank Schaefer <frank.schafer@setuza.cz>
>    Date: 20 May 2002 08:29:50 +0200
> 
>    On Mon, 2002-05-20 at 06:40, David S. Miller wrote:
>    > Only Sparc implements this, that is correct.
>    
>    ... and that's the reason why GDB don't support follow-fork-mode for the
>    intel pltform - right? ( I had a related thread on the gdb mailing list
>    not soo long ago. )
> 
> I can't see any reason why lack of PTRACE_READDATA prevents follow
> fork mode support in GDB.

It doesn't.  Follow-fork support is possible now, with a speed hit, but
I am waiting for better kernel support; it should be forthcoming with
the task ornament-based debugging interface proposed some time ago.

>  But then again the GDB maintainers are a
> bunch of pinheads so...

Hey, I resemble this remark.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: No PTRACE_READDATA for archs other than SPARC?

[William Lee Irwin III]

On Mon, May 20, 2002 at 02:18:00PM -0700, David S. Miller wrote:
>> I can't see any reason why lack of PTRACE_READDATA prevents follow
>> fork mode support in GDB.

On Wed, May 29, 2002 at 07:51:16PM -0400, Daniel Jacobowitz wrote:
> It doesn't.  Follow-fork support is possible now, with a speed hit, but
> I am waiting for better kernel support; it should be forthcoming with
> the task ornament-based debugging interface proposed some time ago.

What is this and who is working on it?


Cheers,
Bill

Re: No PTRACE_READDATA for archs other than SPARC?

[Daniel Jacobowitz]

On Wed, May 29, 2002 at 05:03:11PM -0700, William Lee Irwin III wrote:
> On Mon, May 20, 2002 at 02:18:00PM -0700, David S. Miller wrote:
> >> I can't see any reason why lack of PTRACE_READDATA prevents follow
> >> fork mode support in GDB.
> 
> On Wed, May 29, 2002 at 07:51:16PM -0400, Daniel Jacobowitz wrote:
> > It doesn't.  Follow-fork support is possible now, with a speed hit, but
> > I am waiting for better kernel support; it should be forthcoming with
> > the task ornament-based debugging interface proposed some time ago.
> 
> What is this and who is working on it?

David Howells, at the same time as the rest of the task ornaments
stuff.  You'd have to ask him what the current state of it is.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: No PTRACE_READDATA for archs other than SPARC?

[David S. Miller]

   From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
   Date: Wed, 29 May 2002 19:49:51 -0400

   On Sun, May 19, 2002 at 09:40:53PM -0700, David S. Miller wrote:
   > If other platforms added PTRACE_READDATA support, they would
   > also need to add some way to do a feature test for it's presence
   > so that GDB and other debugging code could actually make use
   > of it portably.
   
   Not really, we should just get EINVAL (ENOSYS?) back when we try to use
   it, right?

You'd get -EIO, but otherwise yes you are right.

Re: No PTRACE_READDATA for archs other than SPARC?

[Daniel Jacobowitz]

On Wed, May 29, 2002 at 05:31:18PM -0700, David S. Miller wrote:
>    From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
>    Date: Wed, 29 May 2002 19:49:51 -0400
> 
>    On Sun, May 19, 2002 at 09:40:53PM -0700, David S. Miller wrote:
>    > If other platforms added PTRACE_READDATA support, they would
>    > also need to add some way to do a feature test for it's presence
>    > so that GDB and other debugging code could actually make use
>    > of it portably.
>    
>    Not really, we should just get EINVAL (ENOSYS?) back when we try to use
>    it, right?
> 
> You'd get -EIO, but otherwise yes you are right.

Really?  That's inconvenient; the same result as for an invalid memory
address.

Oh well, it can still be worked around in GDB.  I'd like to see this on
more/all architectures.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: No PTRACE_READDATA for archs other than SPARC?

[Pradeep Padala]

> Oh well, it can still be worked around in GDB.  I'd like to see this on
> more/all architectures.

I will try to get the feature for i386 architecture. I will let you
know when I amd done.

--pradeep

Re: No PTRACE_READDATA for archs other than SPARC?

[David S. Miller]

   From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
   Date: Wed, 29 May 2002 19:49:51 -0400
   
   Not really, we should just get EINVAL (ENOSYS?) back when we try to use
   it, right?
   
I answered this last week, you will get -EIO which turns out to also a
valid return from PTRACE_READDATA.  So a backwards compatible way to
test for existence of PTRACE_READDATA is going to be difficult.