On Tue, Mar 09 2021, Frank Ch. Eigler via Dwarf-Discuss wrote:
[...]
> FWIW, gcc does not leave ABI-dependent gaps in the DWARF generated for
> function parameters. First class location lists are given, whether or
> not they are in the ABI-governed locations, or whether they've been
> moved some
On Fri, Jan 24 2020, Bishop, John E via Dwarf-Discuss wrote:
> With split lifetimes, the debugger can ask the user which of the
> lifetimes the user wants to set.
>
> debugger-prompt> set A = 3
> Variable 'A' has more than one location. Choose which to set:
> 1.The location us
On Thu, Dec 06 2018, David Stenberg via Dwarf-Discuss wrote:
> [...] variables in outer frames using such location list entries will
> incorrectly be evaluated using the inner-most frame's register values
> when debugging in GDB.
If GDB uses caller-saved register values from the inner-most frame
On Wed, Jun 21 2017, rupesh potharla wrote:
> Hi,
>
> I am looking for a document which has all the newly added dwarf tags for
> Dwarf3 and Dwarf4 at one place.
> Could someone help me with this?
GNU Binutils defines DWARF tags in a simple format, arranged by DWARF
version/extension:
https://s
On Fri, Jan 27 2017, Cary Coutant wrote:
>>> I think the original intent of this wording was to describe the bit
>>> offset of a field within a structure, given the byte address of the
>>> beginning of the structure. Said bit offset would be the total number
>>> of bits occupied by preceding field
On Fri, Jan 27 2017, Robinson, Paul wrote:
>> So, from a DWARF perspective, you'd expect that all libraries shall be
>> recompiled when migrating from an older x86-64 CPU to a newer one that
>> has AVX-512? Or, as in the z/Architecture case, from a zEC12 to a z13
>> system? You don't consider it
On Thu, Jan 26 2017, Andrew Cagney wrote:
>> I thought your example specifically addressed DW_OP_piece (not
>> DW_OP_bit_piece), and that it illustrated the usefulness of involving
>> the resulting object's DW_AT_type into the ABI-dependent placement rule.
>> If that's what you meant, then the exa
On Fri, Jan 27 2017, Michael Eager wrote:
> On 01/27/2017 06:49 AM, Andreas Arnez wrote:
>> But if some "even less significant" bits were added (such as with
>> z/Architecture, where a newer release extended 64-bit FP-registers to
>> 128-bit vectors), then the
On Thu, Jan 26 2017, Michael Eager wrote:
> I don't understand the assertion that "most significant" can not be
> applied to registers. In the case where a register contains a single
> value, this appears to be unambiguous. When a register contains
> multiple values (some architectures support 2
On Thu, Jan 26 2017, Michael Eager wrote:
> On 01/26/2017 11:17 AM, Andreas Arnez wrote:
>> Exactly: the current DWARF text*differs* from the usual "defined by the
>> ABI"-principle when it states for DW_OP_bit_piece: "If the location is a
>> register, the
On Wed, Jan 25 2017, Andrew Cagney wrote:
The definition of DW_OP_piece differs, though: "[...] the placement of
the piece within that register is defined by the ABI."
>>>
>>> Right.
>>
>> Right, and...? Is it intentional that DW_OP_piece(n)" is not
>> necessarily equivalent to "DW_OP_b
On Tue, Jan 24 2017, Andrew Cagney wrote:
> On 12 December 2016 at 09:28, Andreas Arnez wrote:
>> On Fri, Dec 09 2016, Adrian Prantl wrote:
>>
>>> Here's my take on this.
>>
>> Thanks!
>>
>>>> On Dec 9, 2016, at 11:11 AM, Andreas Arnez
On Fri, Dec 09 2016, Adrian Prantl wrote:
> Here's my take on this.
Thanks!
>> On Dec 9, 2016, at 11:11 AM, Andreas Arnez wrote:
>>
>> Although I've already created public comments for (most of) this,
>> Michael Eager suggested that I post my questions r
Although I've already created public comments for (most of) this,
Michael Eager suggested that I post my questions regarding DWARF pieces
on this list (again).
All of these questions are related to the definition of DW_OP_piece and
DW_OP_bit_piece:
* Is "DW_OP_piece(n)" equivalent to "DW_OP_bit_p
On Thu, Dec 01 2016, Michael Eager wrote:
> Andreas --
>
> Please submit comments about the Public Draft at
> http://dwarfstd.org/Comment.php.
OK, I've submitted three requests for clarifying separate aspects of the
DW_OP_piece and DW_OP_bit_piece operations.
--
Andreas
___
On Thu, Dec 01 2016, Mark Wielaard wrote:
> BTW. It would be handy if there were sources for the spec so one can
> create patches for simple typos. Also it is somewhat opaque how Issues
> are handled. Could they and any comments from the committee be sent to
> the mailinglist to make tracking chan
vious bugs, I'm still trying to figure out how the piece
operations should really behave.
For a more in-depth discussion about issues with register pieces see my
article here:
https://sourceware.org/ml/gdb/2016-01/msg00013.html
--
Andreas Arnez
_
) always
equivalent to omitting the DW_OP_piece operation?
Answers are welcome, since I'm currently trying to fix various issues
with GDB's handling of composite location descriptions. More questions
about DWARF pieces came up as well:
https://sourceware.org/ml/gdb/2016-01/msg00013
18 matches
Mail list logo
