From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: raunaq12@in.ibm.com
Cc: gdb-patches@sourceware.org, tromey@redhat.com
Subject: Re: [PATCH 3/5] powerpc64-aix inf-ptrace patch
Date: Tue, 23 Jul 2013 14:25:00 -0000 [thread overview]
Message-ID: <201307231425.r6NEPDxM001322@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <OFC9A62BB4.E1D080B4-ON65257BB1.00459CFE-65257BB1.00472817@in.ibm.com> (message from Raunaq 12 on Tue, 23 Jul 2013 18:26:01 +0530)
> From: Raunaq 12 <raunaq12@in.ibm.com>
> Date: Tue, 23 Jul 2013 18:26:01 +0530
>
> > No this will break other systems. Instead, make sure PTRACE_TYPE_ARG3
> > gets defined to the proper type of the 3rd argument of ptrace64 when
> > you choose to use it. I'd expect that if you add the autoconf check I
> > mentioned you could simply change the #ifdef PTRACE_TYPE_ARG5 in
> > gdb_ptrace.h to something like:
> >
> > #ifdef PTRACE_TYPE_ARG5
> > # ifdef HAVE_PTRACE64
> > # define ptrace(request, pid, addr, data) \
> > ptrace64 (request, pid, addr, data, 0)
> > # undef PTRACE_TYPE_ARG3
> > # define PTRACE_TYPE_ARG3 long long
> > # else
> > # define ptrace(request, pid, addr, data) \
> > ptrace (request, pid, addr, data, 0)
> > # endif
> > #endif
>
> The above suggestion of defining PTRACE_TYPE_ARG3 in gdb_ptrace.h works
> very fine.
Great!
> I can add an autoconf check like -
>
> AC_CHECK_FUNCS(ptrace64)
Just add it to the existing AC_CHECK_FUNCS() call in configure.ac.
> and then in gdb_ptrace.h i can add -
>
> #ifdef PTRACE_TYPE_ARG5
> # if defined (__64BIT__) && defined (HAVE_PTRACE64)
> # ....
>
> Note:- ptrace64 is defined in both 32 and 64 bit mode. But we need to use
> ptrace64 only when we compile gdb in 64 BIT mode hence the __64BIT__ check.
> Or I can also use the AC_CHECK_SIZEOF(long) to check if we are in 64 bit
> mode.
>
> Which do you suggest? or, is there a better way of checking this ?
Well, is there any downside to using ptrace64 in a 32-bit GDB. The
AIX 6.1 online manual page for ptrace, ptracex, ptrace64 suggests that
will work just fine. If that is indeed the case, I would simply not
bother with the check and use ptrace64 whenever it is available.
next prev parent reply other threads:[~2013-07-23 14:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-23 5:35 Raunaq 12
2013-07-23 9:01 ` Mark Kettenis
2013-07-23 12:57 ` Raunaq 12
2013-07-23 14:25 ` Mark Kettenis [this message]
2013-07-23 19:40 ` Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2013-07-10 9:15 Raunaq 12
2013-07-10 17:47 ` Tom Tromey
2013-07-10 19:07 ` Mark Kettenis
2013-07-15 7:32 ` Raunaq 12
2013-07-15 9:12 ` Mark Kettenis
2013-07-16 10:48 ` Raunaq 12
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=201307231425.r6NEPDxM001322@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb-patches@sourceware.org \
--cc=raunaq12@in.ibm.com \
--cc=tromey@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