From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>,
Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: drow@false.org, Tom Tromey <tromey@redhat.com>,
gdb-patches@sourceware.org
Subject: Re: [patch] Fix i386 memory-by-register access on amd64
Date: Wed, 08 Jul 2009 14:42:00 -0000 [thread overview]
Message-ID: <20090708144136.GA6490@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <200907071624.n67GO6bj015890@d12av02.megacenter.de.ibm.com>
On Tue, 07 Jul 2009 18:24:06 +0200, Ulrich Weigand wrote:
> target_thread_architecture is wrong for this purpose;
+
> This should be done inside the TARGET_OBJECT_MEMORY case;
Fixed in the patch.
> (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.)
Originally I thought OFFSET should be later changed to CORE_ADDR. Now I see
for other `enum target_object' larger OFFSET may make sense.
On Tue, 07 Jul 2009 20:43:18 +0200, Mark Kettenis wrote:
> > Date: Tue, 7 Jul 2009 20:22:04 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> >
> > On Tue, 07 Jul 2009 19:59:43 +0200, Mark Kettenis wrote:
> > > But then I don't understand Jan's diff at all. Linux has its own
> > > implementation for TARGET_OBJECT_MEMORY in linux-nat.c. Why isn't
> > > that one used?
> >
> > Expecting the same problem must affect even non-Linux ptrace usage. I will
> > move it to linux-nat.c if you think so.
>
> I suppose I should have been more specific. You are trying to fix a
> bug that you see on Linux isn't it?
Yes.
> And this fix should only be relevant for TARGET_OBJECT_MEMORY isn't
> it?
Yes. I was not sure before and I though it would not hurt other
`enum target_object's but - you are right, yes.
> But Linux has its own implementation for doing TARGET_OBJECT_MEMORY
> xfers in linux_proc_xfer_partial.
I did not much notice linux_proc_xfer_partial role in this bug, thanks.
* I was not able to reproduce the problem for linux_proc_xfer_partial without
removing there:
/* Don't bother for one word. */
if (len < 3 * sizeof (long))
return 0;
because:
* x/gx is the largest size - 8 bytes - which is still smaller.
* x/NUMx generates NUM small transfers (not one NUM*8 transfer).
* These already truncate the address to gdbarch_addr_bit in the caller:
* dump memory
* print *(struct large *) $ebx
* inf_ptrace_xfer_partial gets silently used as a fallback when
linux_proc_xfer_partial fails.
* linux_proc_xfer_partial has been broken so far even on native 32bit GDB
debugging 32bit inferior with GDB built using --enable-64-bit-bfd (and
thus having 64-bit CORE_ADDR). Due to the silent fallback just nobody has
noticed it.
Therefore fixed linux_xfer_partial. Therefore it no longer needs the fix to
be present also in inf_ptrace_xfer_partial. I do not know how non-Linux OSes
handle the debugging of 32bit inferior on 64bit GDB so I have no opinion
whether the inf_ptrace_xfer_partial patch makes sense, i can drop it.
> So I don't understand how this change fixes anything on Linux.
With my former patch linux_proc_xfer_partial failed and the fix in the ptrace
backend did handle the transfer.
Thanks,
Jan
2009-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix memory access from signed 32bit inferior registers on 64bit GDB.
* inf-ptrace.c (inf_ptrace_xfer_partial <TARGET_OBJECT_MEMORY>): New
variable addr_bit. Mask OFFSET by the ADDR_BIT width.
* linux-nat.c (linux_xfer_partial <TARGET_OBJECT_MEMORY>): Likewise.
2009-07-08 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-i386-address.exp, gdb.arch/amd64-i386-address.S: New.
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -457,6 +457,19 @@ inf_ptrace_xfer_partial (struct target_ops *ops, enum target_object object,
switch (object)
{
case TARGET_OBJECT_MEMORY:
+ {
+ int addr_bit = gdbarch_addr_bit (target_gdbarch);
+
+ /* GDB calculates all the addresses in possibly larget width of the
+ address. Address width needs to be masked before its final use
+ - either by linux_proc_xfer_partial or inf_ptrace_xfer_partial.
+
+ Compare ADDR_BIT first to avoid a compiler warning on shift
+ overflow. */
+
+ if (addr_bit < (sizeof (ULONGEST) * HOST_CHAR_BIT))
+ offset &= ((ULONGEST) 1 << addr_bit) - 1;
+ }
#ifdef PT_IO
/* OpenBSD 3.1, NetBSD 1.6 and FreeBSD 5.0 have a new PT_IO
request that promises to be much more efficient in reading
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -4260,6 +4260,20 @@ linux_xfer_partial (struct target_ops *ops, enum target_object object,
return linux_nat_xfer_osdata (ops, object, annex, readbuf, writebuf,
offset, len);
+ /* GDB calculates all the addresses in possibly larget width of the address.
+ Address width needs to be masked before its final use - either by
+ linux_proc_xfer_partial or inf_ptrace_xfer_partial.
+
+ Compare ADDR_BIT first to avoid a compiler warning on shift overflow. */
+
+ if (object == TARGET_OBJECT_MEMORY)
+ {
+ int addr_bit = gdbarch_addr_bit (target_gdbarch);
+
+ if (addr_bit < (sizeof (ULONGEST) * HOST_CHAR_BIT))
+ offset &= ((ULONGEST) 1 << addr_bit) - 1;
+ }
+
xfer = linux_proc_xfer_partial (ops, object, annex, readbuf, writebuf,
offset, len);
if (xfer != 0)
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/amd64-i386-address.S
@@ -0,0 +1,24 @@
+/* Copyright 2009 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+ This file is part of the gdb testsuite. */
+
+_start: .globl _start
+ movl $0xdeadf00d, %eax
+ pushl %eax
+ movl %esp, %ebx
+ int3
+ nop
+ nop
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/amd64-i386-address.exp
@@ -0,0 +1,43 @@
+# Copyright 2009 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# This file is part of the gdb testsuite.
+
+# Test UNsigned extension of the 32-bit inferior address on a 64-bit host.
+# On native 32-bit host the test always PASSed.
+
+if {![istarget "x86_64-*-*"] && ![istarget "i?86-*-*"]} then {
+ verbose "Skipping amd64->i386 adress test."
+ return
+}
+
+if [prepare_for_testing amd64-i386-address.exp amd64-i386-address amd64-i386-address.S [list debug "additional_flags=-m32 -nostdlib"]] {
+ return -1
+}
+
+gdb_run_cmd
+
+set test "trap stop"
+gdb_test_multiple "" $test {
+ -re "Program received signal SIGTRAP,.*_start .*$gdb_prompt $" {
+ pass $test
+ }
+}
+
+gdb_test "x/wx \$esp" "0x\[0-9a-f\]*:\t0xdeadf00d"
+
+# Failure case would be:
+# 0xff8d7f00: Cannot access memory at address 0xff8d7f00
+gdb_test "x/wx \$ebx" "0x\[0-9a-f\]*:\t0xdeadf00d"
next prev parent reply other threads:[~2009-07-08 14:42 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
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 ` Jan Kratochvil [this message]
2009-07-13 18:10 ` [patch] Fix i386 memory-by-register access on amd64 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=20090708144136.GA6490@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=tromey@redhat.com \
--cc=uweigand@de.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