This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Can't build ppc32 GDB


>  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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]