Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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



  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