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 VVMMPP
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
The spec does say they occur in the same order, which strongly implies that
there is a DW_TAG_call_site_parameter for each actual parameter. Although, now
that I say that, I have a memory of some discussion where a parameter entry
might be omitted entirely. I don’t remember the details, but Jaku
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
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
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
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
s that might be created for
padding if developers of such consumers feel so inclined (though I'd probably
push back a bit on it in the consumers I work on - in the absence of any
evidence of particular need/use case).
On Thu, Jan 18, 2024 at 11:08 AM Robinson, Paul via Dwarf-discuss
> > ### .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
# 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
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
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
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
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
# 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
> > 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
> 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
> 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
> 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_
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
> On Thu, Oct 15, 2020 at 04:27:16PM +, 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 defaulting to one and not having a
> > > way
> 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
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
(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
> -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]
> -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
two links did produce exactly the same
non-debug-info parts; but it seems likely the linker would be idempotent
enough for that to work. Thanks!
--paulr
>
>
>
>
> > On Apr 9, 2020, at 2:50 PM, Robinson, Paul via Dwarf-Discuss disc...@lists.dwarfstd.org> wrote:
> &g
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: 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?
>
>
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: 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
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: 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
> 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
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
35 matches
Mail list logo
