From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76372 invoked by alias); 1 Jun 2017 08:15:55 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 15070 invoked by uid 89); 1 Jun 2017 08:15:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:sk:mailhos, H*RU:sk:mailhos, transfers, H*MI:internal X-HELO: smtprelay.synopsys.com Received: from smtprelay2.synopsys.com (HELO smtprelay.synopsys.com) (198.182.60.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Jun 2017 08:15:30 +0000 Received: from mailhost.synopsys.com (mailhost2.synopsys.com [10.13.184.66]) by smtprelay.synopsys.com (Postfix) with ESMTP id C7F6E10C1351 for ; Thu, 1 Jun 2017 01:15:28 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id ADA20216 for ; Thu, 1 Jun 2017 01:15:28 -0700 (PDT) Received: from US01WXQAHTC1.internal.synopsys.com (us01wxqahtc1.internal.synopsys.com [10.12.238.230]) by mailhost.synopsys.com (Postfix) with ESMTP id A0F94215 for ; Thu, 1 Jun 2017 01:15:28 -0700 (PDT) Received: from IN01WEHTCB.internal.synopsys.com (10.144.199.106) by US01WXQAHTC1.internal.synopsys.com (10.12.238.230) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 1 Jun 2017 01:15:22 -0700 Received: from IN01WEMBXB.internal.synopsys.com ([169.254.4.98]) by IN01WEHTCB.internal.synopsys.com ([::1]) with mapi id 14.03.0266.001; Thu, 1 Jun 2017 13:45:19 +0530 From: Ashutosh Pal To: "gdb@sourceware.org" Subject: word addressing issues Date: Thu, 01 Jun 2017 08:15:00 -0000 Message-ID: <40DC337867FFD941BD18FA705989F8F901617A443D@IN01WEMBXB.internal.synopsys.com> x-dg-ref: =?us-ascii?Q?PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNcYXBhbFxhcHBk?= =?us-ascii?Q?YXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjll?= =?us-ascii?Q?MzViXG1zZ3NcbXNnLTcxNmY5ODNiLTQ2YTItMTFlNy05MTI0LWU0YTQ3MTM4?= =?us-ascii?Q?M2M2N1xhbWUtdGVzdFw3MTZmOTgzYy00NmEyLTExZTctOTEyNC1lNGE0NzEz?= =?us-ascii?Q?ODNjNjdib2R5LnR4dCIgc3o9IjQ3NjkiIHQ9IjEzMTQwNzc4NTE3MjAwMDcz?= =?us-ascii?Q?NyIgaD0iZWEvVis4OE84ZWZ5RTRMSExaejk3VklRQ2M0PSIgaWQ9IiIgYmw9?= =?us-ascii?Q?IjAiIGJvPSIxIiBjaT0iY0FBQUFFUkhVMVJTUlVGTkNnVUFBQlFKQUFEaDMr?= =?us-ascii?Q?VXpyOXJTQWNzMVJla2RMcDF5eXpWRjZSMHVuWElPQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUhBQUFBQ2tDQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVB?= =?us-ascii?Q?QVFBQkFBQUEyTWVlUkFBQUFBQUFBQUFBQUFBQUFKNEFBQUJtQUdrQWJnQmhB?= =?us-ascii?Q?RzRBWXdCbEFGOEFjQUJzQUdFQWJnQnVBR2tBYmdCbkFGOEFkd0JoQUhRQVpR?= =?us-ascii?Q?QnlBRzBBWVFCeUFHc0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBRUFB?= =?us-ascii?Q?QUFBQUFBQUFnQUFBQUFBbmdBQUFHWUFid0IxQUc0QVpBQnlBSGtBWHdCd0FH?= =?us-ascii?Q?RUFjZ0IwQUc0QVpRQnlBSE1BWHdCbkFHWUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFDQUFBQUFB?= =?us-ascii?Q?Q2VBQUFBWmdCdkFIVUFiZ0JrQUhJQWVRQmZBSEFBWVFCeUFIUUFiZ0JsQUhJ?= =?us-ascii?Q?QWN3QmZBSE1BWVFCdEFITUFkUUJ1QUdjQVh3QmpBRzhBYmdCbUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQm1BRzhBZFFC?= =?us-ascii?Q?dUFHUUFjZ0I1QUY4QWNBQmhBSElBZEFCdUFHVUFjZ0J6QUY4QWN3QmhBRzBB?= =?us-ascii?Q?Y3dCMUFHNEFad0JmQUhJQVpRQnpBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFF?= =?us-ascii?Q?QUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUdZQWJ3QjFBRzRBWkFCeUFIa0FYd0J3?= =?us-ascii?Q?QUdFQWNnQjBBRzRBWlFCeUFITUFYd0J6QUcwQWFRQmpBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQUNBQUFB?= =?us-ascii?Q?QUFDZUFBQUFaZ0J2QUhVQWJnQmtBSElBZVFCZkFIQUFZUUJ5QUhRQWJnQmxB?= =?us-ascii?Q?SElBY3dCZkFITUFkQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFJQUFBQUFBSjRBQUFCbUFHOEFk?= =?us-ascii?Q?UUJ1QUdRQWNnQjVBRjhBY0FCaEFISUFkQUJ1QUdVQWNnQnpBRjhBZEFCekFH?= =?us-ascii?Q?MEFZd0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUVBQUFBQUFBQUFBZ0FBQUFBQW5nQUFBR1lBYndCMUFHNEFaQUJ5QUhrQVh3?= =?us-ascii?Q?QndBR0VBY2dCMEFHNEFaUUJ5QUhNQVh3QjFBRzBBWXdBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFRQUFBQUFBQUFBQ0FB?= =?us-ascii?Q?QUFBQUNlQUFBQVp3QjBBSE1BWHdCd0FISUFid0JrQUhVQVl3QjBBRjhBZEFC?= =?us-ascii?Q?eUFHRUFhUUJ1QUdrQWJnQm5BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFCQUFBQUFBQUFBQUlBQUFBQUFKNEFBQUJ6QUdF?= =?us-ascii?Q?QWJBQmxBSE1BWHdCaEFHTUFZd0J2QUhVQWJnQjBBRjhBY0FCc0FHRUFiZ0FB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBRUFBQUFBQUFBQUFnQUFBQUFBbmdBQUFITUFZUUJzQUdVQWN3QmZBSEVB?= =?us-ascii?Q?ZFFCdkFIUUFaUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVFBQUFBQUFBQUFD?= =?us-ascii?Q?QUFBQUFBQ2VBQUFBY3dCdUFIQUFjd0JmQUd3QWFRQmpBR1VBYmdCekFHVUFY?= =?us-ascii?Q?d0JoQUhVQWRBQm9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBSUFBQUFBQUo0QUFBQnpB?= =?us-ascii?Q?RzRBY0FCekFGOEFiQUJwQUdNQVpRQnVBSE1BWlFCZkFITUFkQUJoQUhJQWRB?= =?us-ascii?Q?QmZBR1FBWVFCMEFHVUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFFQUFBQUFBQUFBQWdBQUFBQUFuZ0FBQUhNQWJnQndBSE1BWHdCc0FH?= =?us-ascii?Q?a0FZd0JsQUc0QWN3QmxBRjhBZEFCbEFISUFiUUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB?= =?us-ascii?Q?QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFB?= =?us-ascii?Q?QUNBQUFBQUFBPSIvPjwvbWV0YT4=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2017-06/txt/msg00001.txt.bz2 Hi Experts, The following gdbarch hook was introduced in GDB (I guess in v7.11) to be a= ble to tackle architectures with word-addressed (where word =3D any multipl= e of 8-bits) memories.=20 'gdbarch_addressable_memory_unit_size(gdbarch*)' I have been making use of this hook for a word addressed processor architec= ture, in which I return back the word-size (aka addressable-unit size) of t= he memory. I am using gdb 7.12. Of late, I noticed a few places inside GDB = code, where it seems that the word size is not being taken into account. I = am listing those code snippets with some comments below: 1. ) I assume that now (i.e. after v7.11) the memory data transfers functions li= ke read_value_memory, target_xfer_partial, memory_xfer_partial etc. operate= at the word (or the unit) level, where the unit-size is obtained from gdba= rch_addressable_memory_unit_size hook. So, for example, in case of 'memory_= xfer_partial' i.e. memory_xfer_partial (struct target_ops *ops, .., c= onst gdb_byte *writebuf, ULONGEST memaddr, ULONGEST len, ULONGEST *xfered_= len) the arguments 'memaddr' and 'len' will contain the address and the length r= esp. in terms of units which can be potentially bigger than 8-bits, right? = But, looking inside the body of memory_xfer_partial: 1262 static enum target_xfer_status 1263 memory_xfer_partial (struct target_ops *ops, enum target_object object= , ..) ... 1284 else 1285 { 1286 gdb_byte *buf; 1287 struct cleanup *old_chain; ... 1295 len =3D min (ops->to_get_memory_xfer_limit (ops), len); 1296=20 1297 buf =3D (gdb_byte *) xmalloc (len); 1298 old_chain =3D make_cleanup (xfree, buf); 1299 memcpy (buf, writebuf, len); ... Here the 'buf' is being allocated only 'len' bytes (instead of 'len' units)= and similarly memcpy is copying only 'len' bytes (instead of 'len' units).= I think here we should obtain the 'unit_size' from the gdbarch hook and us= e 'len*unit_size' instead of just 'len'. Do you agree? 2.) The offsets for members in structs and classes when saved in the GDB's 'val= ue' struct, should also now be saved in terms of words/units. I noticed a c= ouple of places where the offsets are still being saved as byte offsets. Fo= r example, looking inside the 'value_primitive_field' function in value.c f= ile i.e. 3115 struct value * 3116 value_primitive_field (struct value *arg1, LONGEST offset, ..) ... 3118 { 3163 else if (fieldno < TYPE_N_BASECLASSES (arg_type)) 3164 { ... 3177 if (BASETYPE_VIA_VIRTUAL (arg_type, fieldno)) 3178 boffset =3D baseclass_offset (arg_type, fieldno, 3179 value_contents (arg1), 3180 value_embedded_offset (arg1), 3181 value_address (arg1), 3182 arg1); 3183 else 3184 boffset =3D TYPE_FIELD_BITPOS (arg_type, fieldno) / 8; 3185=20 .... 3196 v->embedded_offset =3D offset + value_embedded_offset (arg1) + boff= set; The 'boffset' here is still being computed in terms of bytes and not units.= Even the 'baseclass_offset' function returns the offset in terms of bytes.= I assume the embedded_offset is now (i.e. from v7.11) saved in terms of un= its and so this looks like incorrect. I see the issue when accessing the "b= ase" part of a derived object. 3.) Noticed similar issue as (2) in functions cp_print_value_fields in cp-valpr= int.c: 155 void 156 cp_print_value_fields (struct type *type, struct type *real_type, 157 const gdb_byte *valaddr, LONGEST offset, ..) ... 350 else 351 { 352 struct value_print_options opts =3D *options; 353=20 354 opts.deref_ref =3D 0; 355 val_print (TYPE_FIELD_TYPE (type, i), 356 valaddr, 357 offset + TYPE_FIELD_BITPOS (type, i) / 8, 358 address, 359 stream, recurse + 1, val, &opts, 360 current_language); 361 } 362 } Here again the term ' TYPE_FIELD_BITPOS (type, i) / 8' added to 'offset' is= in terms of bytes and not units. And a similar issue in do_search_struct_field in valops.c: 1805 static void 1806 do_search_struct_field (const char *name, struct value *arg1, LONGEST = offset, ..) ... 1835 if (t_field_name 1836 && t_field_name[0] =3D=3D '\0') 1837 { 1838 struct type *field_type =3D TYPE_FIELD_TYPE (type, i); 1839=20 ... 1864 if (TYPE_CODE (field_type) =3D=3D TYPE_CODE_STRUCT 1865 || (TYPE_NFIELDS (field_type) > 0 1866 && TYPE_FIELD_BITPOS (field_type, 0) =3D=3D 0)) 1867 new_offset +=3D TYPE_FIELD_BITPOS (type, i) / 8; Could you please check and let me know if my above observations are correct= and if a bug request needs to be filed? Thanks and Regards, Ashutosh