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
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
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
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
mailto: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
>
# 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
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
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
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,
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.
# 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
> > 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
> >
> 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
> 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,
> 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_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
> 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
> > >
> 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
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.
(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:
> -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:
roduce 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:
> >
> > Do
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
> -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
> 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
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
27 matches
Mail list logo
