From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7449 invoked by alias); 7 Jul 2009 16:24:21 -0000 Received: (qmail 7438 invoked by uid 22791); 7 Jul 2009 16:24:21 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 07 Jul 2009 16:24:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n67GO7Lg030211 for ; Tue, 7 Jul 2009 16:24:07 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n67GO70S2388168 for ; Tue, 7 Jul 2009 18:24:07 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n67GO7Ba015898 for ; Tue, 7 Jul 2009 18:24:07 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n67GO6bj015890; Tue, 7 Jul 2009 18:24:06 +0200 Message-Id: <200907071624.n67GO6bj015890@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 07 Jul 2009 18:24:06 +0200 Subject: Re: [patch] Fix i386 memory-by-register access on amd64 To: jan.kratochvil@redhat.com (Jan Kratochvil), drow@false.org Date: Tue, 07 Jul 2009 16:24:00 -0000 From: "Ulrich Weigand" Cc: tromey@redhat.com (Tom Tromey), mark.kettenis@xs4all.nl (Mark Kettenis), gdb-patches@sourceware.org In-Reply-To: <20090706081927.GA18324@host0.dyn.jankratochvil.net> from "Jan Kratochvil" at Jul 06, 2009 10:19:27 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00201.txt.bz2 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