From: "Mark Kettenis" <mark.kettenis@xs4all.nl>
To: pgilliam@us.ibm.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] Can't build ppc32 GDB
Date: Thu, 04 May 2006 07:12:00 -0000 [thread overview]
Message-ID: <25493.192.87.1.22.1146726734.squirrel@webmail.xs4all.nl> (raw)
In-Reply-To: <1146699224.16180.4.camel@dufur.beaverton.ibm.com>
> Sorry if this is a dup, I seem to be having mailer problems...
I sort of remember seeing your reply before, but I can't find it in my
mailbox. So the dup was very welcome :).
> On Tue, 2006-04-25 at 21:38 +0200, Mark Kettenis wrote:
> > > From: PAUL GILLIAM <pgilliam@us.ibm.com>
> > > Date: Mon, 24 Apr 2006 17:23:13 -0700
> > >
> > > Darn! I forgot to 'trim' the patch'.
> > >
> > > I have attached the 'trimmed' version.
> >
> > Get rid of the PTRACE_XFER_TYPE and PTRACE_ARG3_TYPE. Replace them
> > with PTRACE_TYPE_RET and PTRACE_TYPE_ARG3. Or better yet, if the
> > prototype for ptrace(2) is consistent for all powerpc Linux variants,
> > simply replace them with the proper type (which is probably "long").
> >
> > Oh and while you're there, get rid of PT_READ_U/PT_WRITE_U in favour
> > of PTRACE_PEEKUSR/PTRACE_POKEUSR.
> >
> > Mark
> >
> Changeing the PTRACE_... stuff had kind of a wrinkle (see below)
> but the big problem is with this line in ppc_linux_nat.c:
>
> last_stopped_data_address = (CORE_ADDR) siginfo.si_addr;
>
> in subroutine ppc_linux_stopped_by_watchpoint()
>
> A 'CORE_ADDR' is a 'bfd_vma' and on ppc64 systems, a 'bfd_vma' is an
> 'unsigned long long'. If gdb is built on such a system with CC='gcc
> -m64', an 'unsigned long long' is 64 bits as are an 'unsigned long' and
> a 'void *'. No problem.
>
> But if CC is just 'gcc', then an 'unsigned long long' is still 64 bits,
> but an 'unsigned long' and a 'void *' are 32 bits.
>
> Changing the line to:
> last_stopped_data_address = (CORE_ADDR) (unsigned long)
> siginfo.si_addr;
>
> Fixes the problem because the extra cast does nothing when CC='gcc -m64'
> but when CC='gcc', siginfo.si_addr is cast from a 'void *' to an integer
> of the same size, which is then cast to an integer of a larger size,
> avoiding the warning.
This is where the new ISO C99 <stdint.h> types come in handy. Instead of
casting to CORE_ADDR, try casting to uintptr_t.
> I have attached the new patch, OK to commit?
>
> -=# Paul #=-
>
> PS:
>
> Here is the wrinkle
>
> On a ppc64 system:
>
> This is from /usr/include/sys/ptrace.h:
> extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
>
> So I think PTRACE_TYPE_RET should default to 'long' in ppc_linux_nat.c
I really think you should get rid of the PTRACE_RET_TYPE and
PTRACE_XFER_TYPE nonsense in ppc-linux-nat.c. Just use long because
that's
what they will be defined to on Linux. The #define's only make the code
harder to read I think.
> Also from /usr/include/sys/ptrace.h:
> enum __ptrace_request
> {
> ...
> /* Return the word in the process's user area at offset ADDR. */
> PTRACE_PEEKUSER = 3,
> #define PT_READ_U PTRACE_PEEKUSER
> ...
> /* Write the word DATA into the process's user area at offset ADDR.
> */
> PTRACE_POKEUSER = 6,
> #define PT_WRITE_U PTRACE_POKEUSER
> ...
>
> Even though the man pages says PTRACE_PEEKUSR and PTRACE_POKEUSR
Think someone got fooled by the man page then. PTRACE_PEEKUSER/POKEUSER
are also used by the i386 and hppa code. So use those instead of
PT_READ_U/PTRACE_PEEKUSR, and get rid of the #ifdef maze. Well, it's
not really a maze, but it's all useless unless you're compiling on a Linux
system that predates glibc 2. And I don't think the current GDB will
run on such a system (if there ever were pre-glibc 2 ppc systems).
Cheers,
Mark
next prev parent reply other threads:[~2006-05-04 7:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-25 0:18 PAUL GILLIAM
2006-04-25 0:22 ` PAUL GILLIAM
2006-04-25 19:38 ` Mark Kettenis
2006-05-03 23:32 ` PAUL GILLIAM
2006-05-04 7:12 ` Mark Kettenis [this message]
2006-05-05 16:30 ` Daniel Jacobowitz
2006-05-05 16:50 ` Mark Kettenis
2006-05-05 18:31 ` PAUL GILLIAM
2006-05-05 19:55 ` Mark Kettenis
2006-05-05 20:18 ` PAUL GILLIAM
2006-05-05 20:21 ` PAUL GILLIAM
2006-05-05 20:29 ` Mark Kettenis
2006-05-05 20:47 ` PAUL GILLIAM
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=25493.192.87.1.22.1146726734.squirrel@webmail.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb-patches@sources.redhat.com \
--cc=pgilliam@us.ibm.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