From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26031 invoked by alias); 20 Jul 2011 21:03:35 -0000 Received: (qmail 26022 invoked by uid 22791); 20 Jul 2011 21:03:34 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate5.uk.ibm.com (HELO mtagate5.uk.ibm.com) (194.196.100.165) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 21:03:00 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate5.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p6KL2ocl017554 for ; Wed, 20 Jul 2011 21:02:50 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6KL2nqI2449522 for ; Wed, 20 Jul 2011 22:02:49 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p6KL2nbP030067 for ; Wed, 20 Jul 2011 15:02:49 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p6KL2mAq030051; Wed, 20 Jul 2011 15:02:48 -0600 Message-Id: <201107202102.p6KL2mAq030051@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 20 Jul 2011 23:02:48 +0200 Subject: Re: RFC: partially available registers To: tromey@redhat.com (Tom Tromey) Date: Thu, 21 Jul 2011 05:23:00 -0000 From: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gdb-patches@sourceware.org In-Reply-To: from "Tom Tromey" at Jul 20, 2011 02:14:08 PM 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: 2011-07/txt/msg00567.txt.bz2 Tom Tromey wrote: > 2011-07-20 Tom Tromey > > * amd64-tdep.c (amd64_pseudo_register_read_into_value): Rename > from amd64_pseudo_register_read. Change arguments. Call > mark_value_bytes_unavailable when needed. > (amd64_init_abi): Use set_gdbarch_pseudo_register_read_value, not > set_gdbarch_pseudo_register_read. > * sentinel-frame.c (sentinel_frame_prev_register): Use > regcache_cooked_read_into_value. > * regcache.h (regcache_cooked_read_into_value): Declare. > * regcache.c (regcache_cooked_read_into_value): New function. > (regcache_cooked_read): Call > gdbarch_pseudo_register_read_into_value if available. > * i386-tdep.h (i386_pseudo_register_read_into_value): Declare. > (i386_pseudo_register_read): Remove. > * i386-tdep.c (i386_pseudo_register_read_into_value): Rename from > i386_pseudo_register_read. Change arguments. Call > mark_value_bytes_unavailable when needed. > (i386_gdbarch_init): Call > set_gdbarch_pseudo_register_read_into_value, not > set_gdbarch_pseudo_register_read. > * gdbarch.sh (pseudo_register_read_into_value): New method. > * gdbarch.c, gdbarch.h: Rebuild. > * findvar.c (value_from_register): Call get_frame_register_value. I'm not completely happy about the "read into value" style interface; this leaves unclear just how the value passed into that interface is supposed to have been set up. Should the callback have to cope with different types (or even lengths), value offset, or more complex value properties like enclosing type? Apparently not -- the actual callback implementations of your don't attempt to with (or even check for!) any of that, they just blindly assume the value has been set up as they expect. I'd prefer an interface that simply *returns* a value, which then the callback would be free to set up as desired. This would also be much more in line with all the other interfaces that produce values ... > @@ -647,14 +647,16 @@ value_from_register (struct type *type, int regnum, struct frame_info *frame) > else > { > int len = TYPE_LENGTH (type); > + struct value *v2; > > /* Construct the value. */ > v = gdbarch_value_from_register (gdbarch, type, regnum, frame); > > /* Get the data. */ > - ok = get_frame_register_bytes (frame, regnum, value_offset (v), len, > - value_contents_raw (v), > - &optim, &unavail); > + v2 = get_frame_register_value (frame, regnum); > + > + value_contents_copy (v, 0, v2, 0, len); > + ok = 1; > } This seems to introduce a bug by ignoring value_offset (v). If v is of a smaller type than the full register width, only the appropriate bytes of v2 (which do not always start at the beginning, in particular on big-endian machines) ought to be copied over to v. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com