This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Can't build ppc32 GDB
- From: "Mark Kettenis" <mark dot kettenis at xs4all dot nl>
- To: pgilliam at us dot ibm dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 4 May 2006 09:12:14 +0200 (CEST)
- Subject: Re: [patch] Can't build ppc32 GDB
- References: <1145924338.18934.45.camel@dufur.beaverton.ibm.com> <1145924593.18934.48.camel@dufur.beaverton.ibm.com> <200604251938.k3PJc9dl014571@elgar.sibelius.xs4all.nl> <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