Michael Eager wrote:
>On 07/20/2012 12:56 PM, Frank Ch. Eigler wrote:
>> [...]
>> Would the committee consider a faster-track number-assignment process,
>> kind of like IANA, for proposals that do not constitute material
>> structural changes to DWARF, but mere non-conflicting assignment of
>> magi
From: dwarf-discuss-boun...@lists.dwarfstd.org
[dwarf-discuss-boun...@lists.dwarfstd.org] on behalf of Michael Eager
[ea...@eagercon.com]
Sent: Thursday, July 26, 2012 8:37 AM
To: Joeri van Ruth
Cc: dwarf-discuss@lists.dwarfstd.org
Subject: Re: [Dwarf-Di
Joeri van Ruth wrote:
> However, I assume that if the DWARF standard were explicit about the
> size of a byte, it would define a byte to be 8 bits.
As Michael said, if DWARF were to say anything more than it does, it
should be in terms of memory-addressable units; although finding specific
wordi
As the original proposer, I say, Hear hear. The main reasons to choose
that particular scheme were:
- producers that use type sections must already have an MD5 implementation;
- Visual Studio debugger integration uses it.
But a more flexible scheme allowing other schemes would be a Good Thing.
--p
> > A default location list entry (as proposed in 130121.1) gives the
> location
> > of an object for address values which are not otherwise specified in
> the
> > location list.
>
> Maybe an example of this would be helpful too. I am under the (wrong)
> impression that a default location list ent
> -Original Message-
> From: dwarf-discuss-boun...@lists.dwarfstd.org [mailto:dwarf-discuss-
> boun...@lists.dwarfstd.org] On Behalf Of Pierre-Marie de Rodat
> Sent: Wednesday, May 14, 2014 5:39 AM
> To: Agovic, Sanimir
> Cc: DWARF Discuss
> Subject: Re: [Dwarf-Discuss] About self-referenci
> On Mon, 2014-06-02 at 14:07 +0200, Mark Wielaard wrote:
> > I'll try to prototype an implementation for GCC this week and see what
> > it looks like in practice so we can discuss things a bit more
> > concretely.
>
> s/this week/next month/ :) I finally did some prototypes for some of the
> DWAR
The DW_AT_default_value attribute on a formal_parameter DIE can be used to
express a default argument for the parameter; C++ allows this, for example.
int foo(int a, int b = 2);
int bar(int x = foo(3)); // default for x is foo(3,2)
The description of the attribute in DWARF 4 (section 4.1 it
> Paul, could you be more specific about where the 'similar verbiage' is?
> Thanks.
> DavidA.
In DWARF 2, section 4.1 item 8 on p.34.
In DWARF 3, section 4.1 item 9 on p.60.
In DWARF 4, section 4.1 item 9 on p.70.
DWARF 2 did not say the attribute could be a constant; that appeared
in DWARF 3. E
e the DW_AT_default_value "subroutine" thing (I've
found other related terminology issues so it seemed prudent to file them all
together as one issue for everyone to look at).
--paulr
From: Ron Brender [mailto:ron.bren...@gmail.com]
Sent: Tuesday, September 16, 2014 2:08 PM
T
> My first intuition would be to still use DW_TAG_imported_module according
> to the DWARF standard (DWARF is supposed to describe concepts, not
> specific language features); but there is a risk of confusing existing
> debuggers that expect exactly an imported C++ namespace inside a
> DW_TAG_impor
I tried a CU with an int variable instead of float, and enough other
stuff to keep it from being optimized away completely.
gcc produced DW_OP_reg3, while Clang produced "DW_OP_reg3; DW_OP_piece 4"
for the same variable.
DW_OP_piece is really meant for assembling partial values in different
places
> On 03/09/2016 02:53 PM, Cary Coutant wrote:
> >> A value which is contained in a register larger than the size of
> >> the value should be described by a DW_TAG_base_type. (DWARF 4,
> >> Sect. 5.1, bottom of page 75).
> >>
> >> For a 32-bit float in a 128-bit container, use something like the
>
In principle you could have generated source JIT-compiled on a device that has
no filesystem in the usual sense, or maybe has one but it isn't writable.
Seems like a reasonable approach.
--paulr
From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf
Of Bishop, John E
Sen
Thanks for reporting this stuff! I see a few things you found have
already been reported, but please make sure to file issues for the
rest so we can clean up as much as we can.
> New FORMs. DW_FORM_ref_sup doesn't describe how the offset is
> represented. Currently the assumption in elfutils is t
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Andreas Arnez
> Sent: Friday, January 27, 2017 11:16 AM
> To: Michael Eager
> Cc: DWARF Discussion; Ulrich Weigand
> Subject: Re: [Dwarf-Discuss] DWARF piece questions
>
> On Fri,
It's on my personal roadmap to do DWARF 5 split-DWARF for LLVM, but there's no
timeframe. I promise it won't be soon. ☺
--paulr
From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On Behalf
Of John DelSignore
Sent: Friday, February 03, 2017 12:21 PM
To: dwarf-discuss@lists.dwa
I think David is correct, that we did not consider LTO and assumed a .dwo file
would have a single compilation unit in the .debug_info section. It seems to
me not hard to fix, but my idea would require an extension to the package-file
index and I don't see provision in the package-file index fo
In a split-DWARF scenario producing multiple CUs, it's clear that each
split-full unit in the .dwo file would need a corresponding skeleton unit in
the .o file,
Eric was tossing around an idea that would diverge from that - having a single
skeleton for the whole DWO file (where the DWO file wou
Skeleton units are pretty small; it's a 20-byte header, plus values for the
compile_unit DIE, which is spec'd to have no children. I would not be
concerned about space there. And having unique DWO IDs per unit seems pretty
useful.
I tend to agree, though - what sort of uses do you have in mind
tire
.debug_info contribution containing the CU, so that consumers can know how to
resolve DW_FORM_ref_addr.
You're probably still thinking of wrinkles I haven't addressed; let me know.
--paulr
From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Thursday, May 04, 2017 5:30 PM
To: Robinson
I was mentioning this mostly by way of opportunistically suggesting "it might
be a thing that would be good to think explicitly about, possibly allow, and
design this new stuff around the possibility, perhaps".
The entire point of a type unit is to allow size reduction by deduplication.
Any kin
What guarantees that the information referred to is the same across all
"duplicate" TUs or otherwise does not affect the semantic content of the TU?
The same guarantees that exist without TU->CU references, I would think? It's
up to the implementation to ensure that any two TUs are semantically
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Jan Kratochvil
> Sent: Tuesday, June 13, 2017 2:23 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-Discuss] .debug_names: Preallocation of DW_IDX_* for
> static/extern s
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of David Blaikie
> Sent: Wednesday, July 26, 2017 11:04 AM
> To: Doug Evans; dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] address pool + offset representation
>
>
> On Wed, Jul 26, 2017 at 10:51
>> This discussion is about reducing the number of .debug_addr entries you
>> need, so the place to look would be the "class address" attributes.
>> There aren't all that many of them, and the one most likely to benefit
>> would be DW_AT_low_pc.
>>
>> We made it okay to have DW_AT_high_pc be a cons
>> Well... why not just use ranges, in that case? .debug_rnglists is
>> already tuned to reduce relocations. A range list with only one
>> entry is the same as a contiguous range, and DW_RLE_offset_pair is
>> basically the same as using constant low_pc and high_pc.
>
|
> I don't really know just how much LLDB cares about fixed-size forms/DIEs,
> but rumor has it it's important to some degree, so I continue to have a
> slight preference towards fixed size representat
>>> I don't really know just how much LLDB cares about fixed-size forms/DIEs,
>>> but rumor has it it's important to some degree, so I continue to have a
>>> slight preference towards fixed size representations (or at least having
>>> the option to do so, even if there are variable length forms too
Hello Chirag,
Regarding a byte-swap operation, it seems that you have a reasonable use-case
on a bi-endian machine. Feel free to request a new operator on the "public
comments" page at http://dwarfstd.org/Comment.php
Note that a byte-swap operator would swap all bytes in the top-of-stack value
> I am trying to consume the file name of a compile unit. Fortunately
> DW_TAG_compile_unit has a member DW_AT_name and DW_AT_comp_dir.
> Unfortunately it is not clear which kind of encoding is used to
> store these strings. I tried around with GCC and clang. GCC under
> Windows produces latin1 enc
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Philip Craig via Dwarf-Discuss
> Sent: Monday, February 17, 2020 10:02 PM
> To: David Anderson
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] DW_AT_decl_file etc understood now. Question
> answered.
>
> O
Hmmm.
When the committee was reworking the file/dir tables for DWARF v5,
one thing that came up was that the root file/directory were *not*
in the .debug_line section, and therefore the line table could not
be interpreted fully without a .debug_info section, because that
was where the root fil
> -Original Message-
> From: Philip Craig
> Sent: Tuesday, February 25, 2020 3:44 AM
> To: Robinson, Paul
> Cc: David Anderson ; dwarf-
> disc...@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] line table dir/file
>
> On Tue, 25 Feb 2020 at 05:34, Robin
This recently came up in the LLVM project. Harvard architectures
put code and data into separate address spaces, but those spaces
are not explicit; instructions that load/store memory implicitly
use the data space, while things like taking a function address or
doing indirect branches will implic
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Adrian Prantl via Dwarf-Discuss
> Sent: Friday, March 20, 2020 1:29 PM
> To: Michael Eager
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Use of Location Description operations in
> DWARF Expressions?
>
>
Does anyone know of a tool that can strip debug info for specified
CUs from an executable? I'm not aware of a way to do this, but
there are many things I'm not aware of. 😊
The use case is someone who wants to build the entire program
(which includes a number of 3rd-party libraries) with debug inf
> -Original Message-
> From: Greg Clayton
> Sent: Thursday, April 9, 2020 6:32 PM
> To: Robinson, Paul
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Selectively strip CUs from .debug_info?
>
> Not aware of any tools that can do this, bu
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Xing GUO via Dwarf-Discuss
> Sent: Tuesday, July 14, 2020 10:39 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-Discuss] Segment selectors for the range list table.
>
> Hi there,
>
> The DWARFv5 spec mentioned that
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:22 PM
> To: John DelSignore ; todd.allen@concurrent-
> rt.com; Metzger, Markus T
> Cc: dwarf-discuss@lists.dwarfstd.org; Tye, Tony
> Subject: Re: [Dwarf-Discuss]
(resending, this time without dropping the list from the cc: grump grump)
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Michael Eager via Dwarf-Discuss
> Sent: Thursday, July 16, 2020 2:12 PM
> To: todd.al...@concurrent-rt.com; Metzger, Markus T
>
> Cc: dwarf-discuss@lists.dw
David Blaikie has brought this up with me (or in conversations that
I observed) a couple of times:
It's common to want to refer to a particular address plus an offset,
for example for DW_AT_low_pc or DW_AT_ranges to describe a lexical
block or inlined subprogram within another subprogram. General
> On Thu, Oct 15, 2020 at 11:46:55AM -0400, Eric Christopher via Dwarf-
> Discuss wrote:
> > "This margin is too narrow to contain..." ;)
> >
> > I'd like to see the doc - it's easy to believe we've gotten something
> wrong
> > here.. Might be good to fix this as textual edits rather than waiting o
> On Thu, Oct 15, 2020 at 04:27:16PM +0000, Robinson, Paul wrote:
> > > Yes. Please do publish the document somewhere. It would be interesting
> > > to know exactly what is being said to be inconsistent. As far as I
> > > know the issue of the file index defa
DW_AT_artificial generally means the item is compiler-generated, or otherwise
has no explicit representation in the source.
An artificial member in a structure takes up however much space it takes, just
like any other member, and the compiler should have generated the correct
offsets for the oth
> Could someone help to point out what kind of DWARF info should
> be generated for below c++ source? Thanks
>
> ```
> template
> using ptr = T*;
>
> ptr abc;
> ```
>
> We declare a template alias here, so we may generate
> `DW_TAG_template_type_parameter` like:
>
> ```
> 0x0057: DW_TAG_
> Pedro Alves wrote:
> On 2022-05-09 16:48, Ron Brender via Dwarf-Discuss wrote:
> > So my suggestion is to file a bug report with CLANG, requesting they
> correct their DWARF output to reflect all details needed
> > by your language.
>
> An issue here is that DWARF does say this, in (DWARF 5, 5.7
> Looks like gdb and lldb both have issues with C++ local types (either
> types defined in anonymous namespaces, or otherwise localized - eg: a
> non-local template with a local type or variable in one of its
> parameters).
> ...
> So... what could/should we do about this?
Do you have a strong ar
> > If it ever became necessary, you can always add a 2nd attribute for it.
> > As an example, in our Ada compiler decades ago, we did this for
> > DW_AT_artificial. It's just a flag, so either present or not-present.
> > We added a 2nd DW_AT_artificial_kind with a whole bunch of different
> > enu
# Error: DW_OP_entry_value description and examples
## Overview
DW_OP_entry_value provides a way to compute a value as if the value
had been computed on entry to the current subprogram. Its operand is
either a DWARF expression, which assumes nothing is already on the
DWARF stack and leaves one va
I suppose it didn't seem useful to provide ranges on namespaces. A C++
namespace isn't a program entity of its own, it's a way of managing names of
entities. It doesn't even restrict the scope of those names; you can refer to
them anywhere if you use the fully qualified version of the name. (Wit
A "location description [that] is a register operation" is the language in
DWARF v3; in later versions, it is "a simple register location description."
This means something like DW_OP_reg5, which is allowed in a location
description but not in a DWARF expression.
Form DW_FORM_data4, value 0, wo
DWARF strongly recommends UTF-8 in all cases, and there's an attribute on the
compile unit that allows the producer to claim it uses UTF-8. But, whether the
producer actually uses UTF-8 or something else is up to the individual producer
(usually the compiler).
--paulr
From: Dwarf-discuss
On B
Speaking only for myself: Questions about ETA seem reasonable, as the interval
between v4 and v5 was 6 years 8 months, and it has already been 6 years 9
months since v5 was published. That said, the committee has never worked to a
specific timeline.
There is indeed a fair amount of work left to
# Allow padding in all tables
Enhancement; multiple sections.
## Background
Issue 230329.1 requires all tables to be contiguous. During the discussion of
that issue, the question came up of whether all tables allowed padding, so that
contiguous concatenated contributions could be aligned reaso
> > ### .debug_abbrev
> >
> > In Section 7.5.3 "Abbreviations Tables" (p.207), at the end of the
> section, add a new non-normative paragraph:
> >
> > *This table may be padded by adding an unused abbreviation entry. The
> minimum number of bytes in an abbreviation entry is four (abbreviation
> num
provide padding has to re-invent the wheel), feel free to write a
counter-proposal removing the existing mentions.
--paulr
From: David Blaikie
Sent: Tuesday, January 30, 2024 6:01 PM
To: Robinson, Paul
Cc: dwarf-discuss@lists.dwarfstd.org
Subject: Re: [Dwarf-discuss] Proposal: Allow padding in
y adding 0 bytes
at the end.*
> -Original Message-
> From: Dwarf-discuss bounces+paul.robinson=sony@lists.dwarfstd.org> On Behalf Of Robinson,
> Paul via Dwarf-discuss
> Sent: Thursday, January 18, 2024 2:08 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-d
After today's call, hearing some viewpoints and hopefully learning a
few things, I thought I'd take a stab at reframing 240108.1. (Without
once mentioning CFI!) It ended up becoming an alternative proposal,
but I'm fine with Zoran taking it over if he wants to.
# Describe prologue and epilogue ran
Andrew Cagney wrote:
> > A single location description (which can be either simple or composite
> > location descriptions) has the lifetime of its closest containing scope.
> > The case we care about here is when that scope is a subprogram, and
> > therefore the lifetime spans the entire subprog
I believe this is an issue with the implementations, although it is a bit odd
that both gcc and clang behave the same way. There should be a
DW_TAG_call_site_parameter for each parameter. DW_AT_location should describe
the stack slot where the parameter is passed. It should not be a problem for
Jakub probably
does. The spec does not clearly say that parameter entries can be omitted,
though.
--paulr
From: Sergey
Sent: Friday, June 14, 2024 1:12 PM
To: dwarf-discuss@lists.dwarfstd.org; Robinson, Paul
Subject: RE: [Dwarf-discuss] Request for clarification of handling stack-passed
It’s not written down anywhere (probably should be) but in order to assign a
new language code, we need some additional information. Specifically, we need a
default lower bound for arrays (as seen at https://dwarfstd.org/languages.html
) and for the upcoming DWARF v6, a versioning scheme (as see
Thanks. CC’ing the list as that’s what we use for the record of requests.
--paulr
From: Chris Dodd
Sent: Sunday, July 28, 2024 1:38 AM
To: Robinson, Paul
Subject: Re: [Dwarf-discuss] Dwarf language code for P4 langauge
For P4, the lower bound for arrays is 0, and the versioning scheme is
64 matches
Mail list logo
