From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: gdb-patches@sourceware.org
Subject: [rfc] Fix bitfield regressions on 64-bit big-endian targets
Date: Sun, 27 Sep 2009 21:48:00 -0000 [thread overview]
Message-ID: <200909272148.n8RLmY2f032091@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20090828184942.GA5711@caradoc.them.org> from "Daniel Jacobowitz" at Aug 28, 2009 02:49:42 PM
Daniel Jacobowitz wrote:
> value_offset for a bitfield is an offset to be added into the parent's
> contents. So including the parent's offset is incorrect; the attached
> test shows that we were reading the wrong location. With large enough
> offsets, we could wander off to another page of memory and fault.
This changes the value_offset for a bitfield, but does not adapt all
places where the offset is used; in particular value_assign still does
not take the parent's offset into account.
This causes a significant number of store.exp testsuite failures on
s390x-linux and ppc64-linux (and presumably other 64-bit big-endian
platforms).
The following patch updates value_assign to respect the parent offset,
which fixes all those failures.
Tested on s390(x)-linux and ppc(64)-linux with no regressions.
Does this look OK to you?
Bye,
Ulrich
ChangeLog:
* valops.c (value_assign): Respect parent offset when
assigning to a bitfield.
Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.225
diff -c -p -r1.225 valops.c
*** gdb/valops.c 31 Aug 2009 20:18:45 -0000 1.225
--- gdb/valops.c 25 Sep 2009 18:37:40 -0000
*************** value_assign (struct value *toval, struc
*** 827,832 ****
--- 827,835 ----
if (value_bitsize (toval))
{
+ struct value *parent = value_parent (toval);
+ changed_addr = value_address (parent) + value_offset (toval);
+
changed_len = (value_bitpos (toval)
+ value_bitsize (toval)
+ HOST_CHAR_BIT - 1)
*************** value_assign (struct value *toval, struc
*** 838,854 ****
registers. */
if (changed_len < TYPE_LENGTH (type)
&& TYPE_LENGTH (type) <= (int) sizeof (LONGEST)
! && ((LONGEST) value_address (toval) % TYPE_LENGTH (type)) == 0)
changed_len = TYPE_LENGTH (type);
if (changed_len > (int) sizeof (LONGEST))
error (_("Can't handle bitfields which don't fit in a %d bit word."),
(int) sizeof (LONGEST) * HOST_CHAR_BIT);
! read_memory (value_address (toval), buffer, changed_len);
modify_field (type, buffer, value_as_long (fromval),
value_bitpos (toval), value_bitsize (toval));
- changed_addr = value_address (toval);
dest_buffer = buffer;
}
else
--- 841,856 ----
registers. */
if (changed_len < TYPE_LENGTH (type)
&& TYPE_LENGTH (type) <= (int) sizeof (LONGEST)
! && ((LONGEST) changed_addr % TYPE_LENGTH (type)) == 0)
changed_len = TYPE_LENGTH (type);
if (changed_len > (int) sizeof (LONGEST))
error (_("Can't handle bitfields which don't fit in a %d bit word."),
(int) sizeof (LONGEST) * HOST_CHAR_BIT);
! read_memory (changed_addr, buffer, changed_len);
modify_field (type, buffer, value_as_long (fromval),
value_bitpos (toval), value_bitsize (toval));
dest_buffer = buffer;
}
else
*************** value_assign (struct value *toval, struc
*** 891,896 ****
--- 893,900 ----
{
if (value_bitsize (toval))
{
+ struct value *parent = value_parent (toval);
+ int offset = value_offset (parent) + value_offset (toval);
int changed_len;
gdb_byte buffer[sizeof (LONGEST)];
*************** value_assign (struct value *toval, struc
*** 903,917 ****
error (_("Can't handle bitfields which don't fit in a %d bit word."),
(int) sizeof (LONGEST) * HOST_CHAR_BIT);
! get_frame_register_bytes (frame, value_reg,
! value_offset (toval),
changed_len, buffer);
modify_field (type, buffer, value_as_long (fromval),
value_bitpos (toval), value_bitsize (toval));
! put_frame_register_bytes (frame, value_reg,
! value_offset (toval),
changed_len, buffer);
}
else
--- 907,919 ----
error (_("Can't handle bitfields which don't fit in a %d bit word."),
(int) sizeof (LONGEST) * HOST_CHAR_BIT);
! get_frame_register_bytes (frame, value_reg, offset,
changed_len, buffer);
modify_field (type, buffer, value_as_long (fromval),
value_bitpos (toval), value_bitsize (toval));
! put_frame_register_bytes (frame, value_reg, offset,
changed_len, buffer);
}
else
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2009-09-27 21:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-28 19:55 [commit] Fix bitfield errors - PR 10565 Daniel Jacobowitz
2009-09-27 21:48 ` Ulrich Weigand [this message]
2009-09-27 22:28 ` [rfc] Fix bitfield regressions on 64-bit big-endian targets Daniel Jacobowitz
2009-09-28 9:20 ` Ulrich Weigand
2009-09-28 16:33 ` Daniel Jacobowitz
2009-09-28 18:07 ` Joel Brobecker
2009-09-28 18:32 ` Daniel Jacobowitz
2009-09-29 0:44 ` Ulrich Weigand
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=200909272148.n8RLmY2f032091@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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