This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] PR gdb/21226: Take DWARF stack value pieces from LSB end
- From: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 13 Mar 2017 13:17:50 +0100
- Subject: Re: [PATCH] PR gdb/21226: Take DWARF stack value pieces from LSB end
- Authentication-results: sourceware.org; auth=none
- References: <20170310200108.14140D806AB@oc3748833570.ibm.com>
On Fri, Mar 10 2017, Ulrich Weigand wrote:
> Andreas Arnez wrote:
>> On Fri, Mar 10 2017, Ulrich Weigand wrote:
>>
>> > Andreas Arnez wrote:
>> >
>> > Sorry, I overlooked one other issue:
>> >
>> >> + /* Piece offset is from least significant bit end. */
>> >> + if (bits_big_endian)
>> >> + source_offset_bits += obj_size - (p->offset + p->size);
>> >> + else
>> >> + source_offset_bits += p->offset;
>> >
>> > Should this really consult bits_big_endian, as opposed to the
>> > regular byte order? Note that in the DWARF_VALUE_REGISTER case,
>> > we have the same issue, and there the byte order is consulted.
>>
>> Using the byte order would strictly be more correct, yes. As opposed to
>> register pieces, we would have to get it from a different gdbarch,
>> though. I think the right one would be the objfile gdbarch of the
>> underlying CU, right?
>
> That sounds right, and is compatible with what is done for full
> DWARF_VALUE_STACK values in dwarf2_evaluate_loc_desc_full.
Right -- which reminds me... A month ago I provided a patch for that as
well:
https://sourceware.org/ml/gdb-patches/2017-03/msg00041.html
--
Andreas