Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: jan.kratochvil@redhat.com (Jan Kratochvil), drow@false.org
Cc: tromey@redhat.com (Tom Tromey),
	mark.kettenis@xs4all.nl (Mark Kettenis),
	        gdb-patches@sourceware.org
Subject: Re: [patch] Fix i386 memory-by-register access on amd64
Date: Tue, 07 Jul 2009 16:24:00 -0000	[thread overview]
Message-ID: <200907071624.n67GO6bj015890@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20090706081927.GA18324@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Jul 06, 2009 10:19:27 AM

Jan Kratochvil wrote:

> Updated the patch to do on 64bit hosts exactly the same what 32bit hosts do.
> 32bit hosts do all the CORE_ADDR calculations 64bit, just the final ptrace
> call strips the width to 32bits.

Hmm, I'm wondering how this would affect platforms where addresses are
generally treated as signed integers (MIPS ?).  Dan, do you know if the
kernel expects the ptrace address argument to be sign-extended on MIPS?

> There is some suspection a similiar patch would be appropriate for theses
> functions but I have no such test OSes/machines available:
> 	config/pa/hpux.mh	inf-ttrace.c	inf_ttrace_xfer_memory
> 	config/powerpc/aix.mh	rs6000-nat.c	rs6000_xfer_partial

It seems the AIX version already performs truncations via casts:

                  buffer.word = rs6000_ptrace32 (PT_READ_I, pid,
                                                 (int *)(uintptr_t)rounded_offset,
                                                 0, NULL);

> @@ -452,8 +452,20 @@ inf_ptrace_xfer_partial (struct target_ops *ops, enum target_object object,
>  			 const gdb_byte *writebuf,
>  			 ULONGEST offset, LONGEST len)
>  {
> +  struct gdbarch *gdbarch = target_thread_architecture (inferior_ptid);
> +  int addr_bit = gdbarch_addr_bit (gdbarch);

target_thread_architecture is wrong for this purpose; it is the user-visible
architecture to be used for this thread.  The architecture to be used for
target (e.g. ptrace) operations is target_gdbarch.

For example, on an SPU thread on the Cell/B.E. target_thread_architecture might 
be SPU, while target_gdbarch is PPC32 or PPC64.  ptrace operations need to operate
according to the latter.

> +  /* 32-bit host will pass only the lower 32-bits of OFFSET to the ptrace
> +     syscall.  64-bit host debugging 32-bit inferior would get EIO for non-zero
> +     higher 32-bits in the same case.  Match the behavior of 32-bit host GDB
> +     for 64-bit host GDB debugging 32-bit inferior.
> +
> +     Compare ADDR_BIT first to avoid a compiler warning on shift overflow.  */
> +  gdb_assert (sizeof (offset) == sizeof (ULONGEST));
> +  if (addr_bit < (sizeof (ULONGEST) * HOST_CHAR_BIT))
> +    offset &= ((ULONGEST) 1 << addr_bit) - 1;

This should be done inside the TARGET_OBJECT_MEMORY case; there is no reason
why the same truncation should be performed for other object types.

(The assert seems superfluous to me; "offset" is a local variable to this
function, so we should know its type already.  Other code in this function
would already fail if offset were of any other type.)


Otherwise, the patch looks reasonable to me -- if the MIPS question above
can be resolved.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


  reply	other threads:[~2009-07-07 16:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 10:27 Jan Kratochvil
2009-04-29 19:05 ` Mark Kettenis
2009-04-29 20:29   ` Jan Kratochvil
2009-04-29 20:45     ` Jan Kratochvil
2009-06-25 16:33     ` Tom Tromey
2009-07-06  8:19       ` Jan Kratochvil
2009-07-07 16:24         ` Ulrich Weigand [this message]
2009-07-07 16:54           ` Daniel Jacobowitz
2009-07-07 18:00           ` Mark Kettenis
2009-07-07 18:22             ` Jan Kratochvil
2009-07-07 18:43               ` Mark Kettenis
2009-07-08 13:20           ` [patch] /* */ for target_thread_architecture [Re: [patch] Fix i386 memory-by-register access on amd64] Jan Kratochvil
2009-07-09 12:51             ` Ulrich Weigand
2009-07-09 16:36               ` Jan Kratochvil
2009-07-08 14:42         ` [patch] Fix i386 memory-by-register access on amd64 Jan Kratochvil
2009-07-13 18:10           ` Ulrich Weigand
2009-07-13 19:42             ` Mark Kettenis
2009-07-13 20:32             ` Jan Kratochvil

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=200907071624.n67GO6bj015890@d12av02.megacenter.de.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=mark.kettenis@xs4all.nl \
    --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