Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: cagney@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/RFC] Replace call_ptrace and ptrace_wait in inf-ptrace.c
Date: Fri, 24 Sep 2004 22:37:00 -0000	[thread overview]
Message-ID: <200409242237.i8OMbNSY001761@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <41502790.1080100@gnu.org> (message from Andrew Cagney on Tue, 21 Sep 2004 09:07:28 -0400)

   Date: Tue, 21 Sep 2004 09:07:28 -0400
   From: Andrew Cagney <cagney@gnu.org>

I committed the patch:

2004-09-24  Mark Kettenis  <kettenis@gnu.org>

	* inf-ptrace.c (inf_ptrace_kill_inferior): Call ptrace directly
	instead of call_ptrace.  Call wait directly instead of
	ptrace_wait.
	(inf_ptrace_me): Call ptrace directly instead of call_ptrace.
	(inf_ptrace_wait): Inline ptrace_wait call.

But this doesn't mean we shouldn't continue this discussion. It
actually makes things easier for us whatever the outcome because now
we can forget about replacing call_ptrace, and can just focus on
ptrace().  Please read on.

   > The variety in ptrace(2) prototypes is pretty big.  Arguments can be
   > integer or pointer types of various sizes (32-bit, 64-bit).  We simply
   > cannot get that right for all supported operating systems.  So we have
   > to guess.  Being conservative, we use a long integer type, say
   > CORE_ADDR, for the n-th argument of call_ptrace().  Suppose that on an
   > LP64 platform we pass, by mistake, a pointer as the n-th argument of
   > ptrace, but that argument should really be an int.  Because of the
   > intermediate call_ptrace() the compiler doesn't warn us about it.  The
   > result is probably a mysterious bug.

   Either way we'll end up with casts:
	   CORE_ADDR -> (void *)
	   (void *) -> long
   etc, why not have methods that at least avoid the casts (or do it 
   locally to GDB's ptrace code?).

The problem here is that the third argument of ptrace is used for two
purposes:

1. For specifying memory addresses of objects in the debugger's
   address space (PT_GETREGS, PT_SETREGS, PT_IO).

2. For specifying memory addresses in the inferior.

This gets especially complicated with 32x64 "native" cross-debugging
and is further complicated by the fact that some systems use an
integer type and other systems use a pointer type for this third
arguments.  I've tried to come up with a function signature for
gdb_ptrace() that would work for all targets, and I failed.

Mark


  reply	other threads:[~2004-09-24 22:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-20 19:14 Mark Kettenis
2004-09-20 19:37 ` Andrew Cagney
2004-09-20 19:42   ` Daniel Jacobowitz
2004-09-20 21:48   ` Mark Kettenis
2004-09-21 13:09     ` Andrew Cagney
2004-09-24 22:37       ` Mark Kettenis [this message]
2004-09-24 22:46         ` Andrew Cagney

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=200409242237.i8OMbNSY001761@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox