(hopefully this doesn't get too lost in all the other discussion in this
thread - maybe best to spin things out under separate subject
lines/subthreads?)
(I'm looking into this more in the context of LLVM trying to solve the
downcasting part of this, motivated by Sony's SCE debugger but also with
On Wed, Apr 23, 2025 at 2:53 PM Kyle Huey wrote:
> On Wed, Apr 23, 2025 at 2:20 PM David Blaikie wrote:
> >>
> >> Do you object to anything I proposed other than removing the
> >> representation of the anonymous class compilers generate for lambdas?
> &
>
> Do you object to anything I proposed other than removing the
> representation of the anonymous class compilers generate for lambdas?
>
I'm not a /super/ fan of introducing a bunch of locals in addition to the
member descriptions - it'll be a bunch of extra DWARF that'd be nice to
avoid if we c
On Wed, Apr 16, 2025 at 8:59 AM Kyle Huey via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> This may be more of an implementation question than a spec question,
> but this seems like the place to have the discussion regardless.
>
> C++ debuggers that support expression evaluation need
On Fri, Mar 28, 2025 at 9:14 AM David Anderson wrote:
> On 3/28/25 08:30, David Blaikie wrote:
> > I believe the intent is that version numbers are able to be compared
> > numerically.
> >
> > In any case, they are numbers per https://dwarfstd.org/
> > issues/21
I believe the intent is that version numbers are able to be compared
numerically.
In any case, they are numbers per https://dwarfstd.org/issues/210419.1.html
- "A DW_AT_language_version attribute may be specified whose constant value
is an integer code indicating the version of the source language
On Mon, Feb 3, 2025 at 8:01 AM Paul Robinson wrote:
> Also, fixed-size DIEs are much easier when quickly scanning for something;
> you can derive the size of the DIE from the abbrev without having to look
> at the DIE content. When you have variable-size values such as LEB128 then
> you need to p
As an alternative to the indexed proposal in 250130.1, which proposes
allowing a constant classed value for DW_AT_object_pointer, as an index
into the formal parameters of the subprogram, I was wondering how folks
would feel about something a bit different:
What about a reference classed form that
Yeah, I'm good either way - describing the artificiality of object_pointer
as optional, or removing that entirely & leaving that up to consumers to
use as needed. I think I'd lean towards removing the wording & leaving it
up to users to decide what's artificial and what isn't.
On Wed, Jan 22, 2025
+1, thanks for bringing this up, Tom - seems like just specing it as class
"constant" would be fine. And in fact in table 7.5 it's already specified
that way...
So might just be a matter of removing the leb128 wording from the quoted
area?
@Cary Coutant could we get an issue filed for this?
On M
On Mon, Jan 13, 2025 at 4:56 PM David Anderson
wrote:
> On 1/13/25 11:31, David Blaikie wrote:
> > I still think the commentary on the indexes isn't quite right. They're
> > separate from this issue - you'd still need the rnglists base, or have
> > to assume
On Tue, Jan 14, 2025 at 4:52 AM John DelSignore via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> In-line below...
> On 1/13/25 20:10, David Anderson via Dwarf-discuss wrote:
>
> On 1/13/25 11:35, David Blaikie via Dwarf-discuss wrote:
>
> I guess Jon is refe
On Mon, Jan 13, 2025 at 10:45 AM David Anderson via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> On 1/13/25 07:17, John DelSignore via Dwarf-discuss wrote:
> > Hi,
> >
> > Section 6.2 (Line Number Information) of the DWARF 5 spec does not seem
> to constrain which DW_LNCT content typ
I still think the commentary on the indexes isn't quite right. They're
separate from this issue - you'd still need the rnglists base, or have to
assume that it's sizeof(header), to go that far into the region described
by the index.
The index essentially makes a DWP look like a bunch of separate D
On Fri, Dec 20, 2024 at 9:36 AM David Anderson via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
>
> The examples of .debug_tu_index in DWARF5 Section F.2.3
> show the hash as computed by Type Signature Computation
> Section 7.32 and referenced by DW_AT_LOCATION DW_FORM_ref_sig8.
>
do
This is probably more of a question for the DWARF producer, like GCC, than
the DWARF workgroup, but let's take a look anyway...
Ah, OK, simplifying things down a bit. You've got this case:
```
struct t1
{
typedef struct
{
} t2;
#ifdef USE_VIRTUAL
virtual void f1();
#endif
};
t1::
What sort of string-like behavior would one want on a bit-string? Seems
like array would be the better fit to me...
On Wed, Dec 18, 2024 at 9:03 AM pogo 59 via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> My first thought would be that DW_TAG_string_type with a one-bit base
> type,
On Thu, Dec 12, 2024 at 11:26 AM Ron Brender via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> >The current DWARF 5 specification's statement in Section 2.17.3 (p. 53,
> line 15) that "Bounded range entries in a range list may not >overlap" is
> overly restrictive and doesn't reflect
On Thu, Dec 12, 2024 at 9:41 AM David Anderson via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> On 12/11/24 16:59, Alex via Dwarf-discuss wrote:
> > ## Proposed Changes
> >
> > In Section 2.17 (Location Descriptions), replace the text on p. 53, line
> 15:
> >
> > From:
> > ```
> > Bo
+1. Best not to encourage use of things we haven't finished standardizing -
though we made an explicit carveout for the language codes themselves.
On Wed, Nov 20, 2024 at 9:49 AM pogo 59 via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Sorry, meant to reply-all.
>
> -- Forwa
Thanks for taking an interest - and nice work on the DWARF parsing library!
Joining the dwarf-discuss list is open to anyone and can be done here:
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss - though it's
pretty low-traffic.
If you're interested in joining the DWARF committee proper
On Thu, Sep 12, 2024 at 11:08 AM Jakub Jelinek wrote:
> On Thu, Sep 12, 2024 at 10:52:33AM -0700, David Blaikie via Dwarf-discuss
> wrote:
> > Looks probably like a bug in GCC and best discussed in their forum?
> (clang
> > seems to produce the macro in the macinf
Looks probably like a bug in GCC and best discussed in their forum? (clang
seems to produce the macro in the macinfo if you compile with
`-fdebug-macro` (& you have to put some emitted entity (like a function
definition) in the file before Clang will produce any debug info for the
file))
On Wed, S
Some context:
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/44
https://github.com/llvm/llvm-project/pull/77457
Essentially clang/llvm produces DW_IDX_parent with DW_FORM_flag_present
when the entry has a parent, but that parent isn't indexed (I think
On Sat, Jul 27, 2024 at 10:50 PM Alexandre Oliva wrote:
> On Jul 27, 2024, David Blaikie wrote:
>
> > If I'm following correctly, Alexandre - you're suggesting a situation
> where
> > an instance of a type, when it appears within a packed struct, may become
>
If I'm following correctly, Alexandre - you're suggesting a situation where
an instance of a type, when it appears within a packed struct, may become
smaller than it would otherwise be? (usually in C that's not the case -
packing only changes the alignment of instances of the type - which may
chang
On Sun, Jul 21, 2024 at 3:54 PM Jacob Young wrote:
> > On 12/07/2024 19:04, David Blaikie wrote:
> > > Thanks for all the context (I noticed you replied directly to me - are
> > > you happy/OK having this discussion on the mailing list, rather than
> > > in p
On Mon, Jul 8, 2024 at 2:18 PM David Blaikie wrote:
> Hi Matthew,
>
> I'm looking into your issue & I have some broad questions:
>
> This seems like it'd speed up generics-heavy code, to be sure - though I
> assume you hit a perf issue in some prototype tool
Hi Matthew,
I'm looking into your issue & I have some broad questions:
This seems like it'd speed up generics-heavy code, to be sure - though I
assume you hit a perf issue in some prototype tool already, that lead you
to this issue? Do you have further details on the tooling you've
prototyped/the
allow a consumer to match them up would be good.
On Tue, Feb 28, 2023 at 4:07 PM David Blaikie wrote:
> Hmm - I guess one complication of only putting the mangling number on
> the type, is that you need the scope of the lambda too... which is
> tricky in this case:
>
> extern int i;
On Tue, May 28, 2024 at 12:38 PM David Anderson via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Issue: Clarification
>
> I cannot find any mention of these issues as open
> in the DWARF6 issues list.
>
> Dwarf5, Appendix F, table F.1:
>
> DW_AT_loclists_base has a checkmark for co
On Thu, May 16, 2024 at 1:05 PM Martin via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> On 16/05/2024 21:58, Martin via Dwarf-discuss wrote:
>
> >
> > If there is code (with debug info) that uses a class/struct that is
> > defined in a unit with debug info (or at least a base class i
On Thu, May 16, 2024 at 10:20 AM Mark Wielaard via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Hi,
>
> Section 6.2.4.1 Standard Content Descriptions under 1. DW_LNCT_path has
> the following description on using DW_FORM_strx forms:
>
>In a .debug_line.dwo section, the forms DW_F
On Thu, May 16, 2024 at 7:10 AM Martin via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> If a compiler adds a DW_TAG_subprogram for a routine from a different
> compilation unit ...
> Maybe because
> - the other CU has no debug info
> - The compiler does not support referencing cross
I'd be curious what compilers have been doing for Pascal for the last few
decades - not exactly a new problem? But, yeah, might've all been getting
by with extensions.
On Wed, May 1, 2024 at 2:47 PM Adrian Prantl via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Just a quick very gen
Not that I'm aware of - there might be some existing features that are used
by languages that've had coroutines longer than C++? Not sure.
I think LLVM does produce some DWARF for coroutines, but I haven't looked
at it/seen how viable it is/how much consumers would need to know really
specific det
o anyone who feels
> moved to 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-di
Is anyone actually using this? In my experience linkers are generally
concatenating these sections together with no extra padding/alignment.
I'd rather not spec something that's not used/needed. I'm happy for
consumers to be improved in the face of degenerate entries that might be
created for padd
On Fri, Dec 1, 2023 at 1:43 PM David Anderson via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> On 12/1/23 05:24, Ben Woodard via Dwarf-discuss wrote:
> > My reasoning is that the reason why we are running out of vendor defined
> > space is that within in the various vendor spaces the
>
> 5. Re 1.3.13: Blaming "reduced tool compatibility" on the skipability of
> unknown constructs seems a huge and unjustified claim. I don't buy it.
>
> In most cases, I can see your point but in this case I cannot. To me this
> seems obvious.
>
> Of course a consumer should be able to skip over s
Yeah - I mostly don't mind it taking as long as it takes.
Eleanor - is there something you're particularly interested in/waiting
for/etc? At least for myself, speaking as a clang/llvm debug info
maintainer, I'd be happy to see DWARFv6 prototyped there (with a "no
stability guarantee" caveat, becau
On Tue, Oct 24, 2023 at 6:09 AM Claudio Eterno via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Hi, I'm taking a look at docs.
> On dwarf-2.0.0.pdf I see at "7.20 Address Range Table"
>
For what it's worth, I'd encourage you to consider other options for
address lookup, as the plan
On Mon, Oct 16, 2023 at 9:12 AM David Blaikie wrote:
>
>
> On Mon, Oct 16, 2023 at 8:57 AM Alexander Yermolovich
> wrote:
>
>> For background llvm discussion on how to implement it:
>>
>> https://discourse.llvm.org/t/debuginfo-dwarfv5-lld-debug-names-with-fdebug
ings that could be referenced within a type unit?
>
> Alex
>
>
>
>
>
>
>
> --
> *From:* David Blaikie
> *Sent:* Monday, September 25, 2023 9:02 AM
> *To:* Alexander Yermolovich
> *Cc:* dwarf-discuss@lists.dwarfstd.org
> *Subject:* Re: [Dwarf-discuss] [DWARF5]
(derived from:
https://lists.dwarfstd.org/mailman/private/dwarf-workgroup/2023-October/002444.html
)
# Tombstoning TU entries in `.debug_names`
## Background
Local type unit entries in `.debug_names` reference type units via their
offset in the `.debug_info` section.
Assuming a non-DWARF-aware
On Fri, Sep 15, 2023 at 2:45 PM Alexander Yermolovich via
Dwarf-discuss wrote:
>
> Hello
>
> I am trying to enable debug names acceleration table with
> fdebug-types-sections in LLVM. One part I am not sure about is the local TU
> list. It contains an offset into .debug_info section. All the ent
If what you're searching for could be encoded in the fast lookup
tables (.debug_names) that could save you some parsing effort.
Otherwise, if you're searching for an address and you have a lot of
non-addressable DWARF, or really large CUs or something - I can see
how namespace address ranges could
> But please don't sent HTML email. It will make DKIM verification of
> your email impossible.
Hmm - how does HTML email relate to/interfere with DKIM verification?
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
On Fri, Apr 21, 2023 at 2:16 PM John DelSignore
wrote:
>
> On 4/21/23 16:36, David Blaikie wrote:
>
> On Fri, Apr 21, 2023 at 12:44 PM John DelSignore
> wrote:
>
>> Well, it took a long time to compile 5 CUs that contained your test code,
>> and things were l
ose
threads/discussions if you need them, I think some happened in the LLVM
open source community.
- Dave
> Cheers, John D.
> On 4/21/23 13:28, John DelSignore wrote:
>
> Thanks David, this is useful. I'll see what I can cobble together.
>
> Cheers, John D.
> On 4/20/23 21:5
l
off hand) - would make it arbitrarily large without the need to tax the
compiler creating novel/real DWARF, etc.
On Thu, Apr 20, 2023 at 6:54 PM David Blaikie wrote:
> I /believe/ that Chromium (maybe specifically on ARM? not sure) may have
> hit/had problems with the 4GB limit - probabl
I /believe/ that Chromium (maybe specifically on ARM? not sure) may have
hit/had problems with the 4GB limit - probably trivially if you build with
clang but pass `-fstandalone-debug` which disables many type
reduction/deduplication strategies.
If you want something more standalone... this:
#def
Yeah - agreed with this whole description & I'd feel comfortable with
either of the proposed additions.
On Wed, Mar 29, 2023 at 2:15 AM Keith Walker via Dwarf-discuss
wrote:
>
> # Problem
>
>
>
> There is no statement if tables must be contiguous or if
>
> there can be padding between the tables.
> DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but
> rather as a marker that "this type is eligible to be passed in hardware
> vector registers at function boundaries according to the platform ABI".
My 2c would not be to describe these in terms of
hardware/implementa
FWIW, I like the idea/reckon it's worth a revisit.
I'd shy away from equipping the dwarves with weapons/combat imagery -
maybe a smithy's hammer (or pickaxe) would be more suitable for
tooling? (this sort of thing:
https://www.kctool.com/picard-1c-blacksmiths-hammer-with-ash-handle-1800g/
- has a
number in an attribute, maybe being able to scope
the type inside a variable DIE? though that sounds a bit frightening)
to help in those cases, even if in some of the worst cases we'd have
to use the mangled name to reassociate anonymous types?
- Dave
On Mon, Aug 22, 2022 at 12:44 PM D
Ping - any thoughts here?
On Sun, Jul 24, 2022 at 9:08 PM David Blaikie wrote:
>
> Ping on this thread - would love to hear what ideas folks have for
> addressing the naming of anonymous types (enums, structs/classes, and
> lambdas) - especially if it'd make it easier to go b
Here's the posted issue: https://dwarfstd.org/ShowIssue.php?issue=220724.1
On Sun, Jul 24, 2022 at 10:56 PM David Blaikie wrote:
>
> Posted an issue to the dwarfstd.org to propose removing
> .debug_aranges, will follow up with a link here once it's
> accepted/posted public
h for LLDB. No one seems to consistently emit .debug_aranges these days
> so we definitely don't rely on it.
>
> Greg
>
> > On Jun 14, 2022, at 1:10 PM, David Blaikie via Dwarf-Discuss
> > wrote:
> >
> > Given the discussion previously in this thread -
DIEs describing the same parameter type.
On Tue, Jun 14, 2022 at 1:02 PM David Blaikie wrote:
>
> Looks like https://reviews.llvm.org/D122766 (-ffile-reproducible) might solve
> my immediate issues in clang, but I think we should still consider moving to
> a more canonical namin
On Sun, Jun 26, 2022 at 2:24 PM Vsevolod Alekseyev via Dwarf-Discuss
wrote:
>
> Makes sense, thank you. It's enough for me to go with as far as parsing is
> concerned.
>
> That said, why bother with the bitness indicator in the ...lists sections at
> all? I can't imagine parsing them from top to
Jan 24, 2022 at 5:51 PM David Blaikie wrote:
> On Mon, Jan 24, 2022 at 5:37 PM Adrian Prantl wrote:
>
>>
>>
>> On Jan 23, 2022, at 2:53 PM, David Blaikie wrote:
>>
>> A rather common "quality of implementation" issue seems to be lambda
>> nam
than "t" (& so then you'll get "t" entries for "t"
and "t", etc... and have to disambiguate them)
But that's, I think, a different topic from the one this thread is
about - how to identify which types are CU-local and which types are
not. M
Given the discussion previously in this thread - does anyone have
particular objections to removing .debug_aranges? (in favor of/perhaps
with specific wording that /requires/ CU level ranges to be specified
(ie: it's not acceptable to have a subprogram with non-empty range in
a CU which doesn't cov
On Wed, May 18, 2022 at 9:53 AM David Blaikie wrote:
>
> On Wed, May 18, 2022 at 4:16 AM Robinson, Paul wrote:
> >
> > > Looks like gdb and lldb both have issues with C++ local types (either
> > > types defined in anonymous namespaces, or otherwise localized - eg: a
On Wed, May 18, 2022 at 4:16 AM Robinson, Paul wrote:
>
> > 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).
> > ...
>
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). GDB correctly associates directly referenced types (eg:
the type of a variable does
On Fri, May 6, 2022 at 10:08 AM Robinson, Paul via Dwarf-Discuss
wrote:
>
> > 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
On Mon, Feb 28, 2022 at 2:58 PM Michael Eager wrote:
> On 2/28/22 13:11, David Blaikie via Dwarf-Discuss wrote:
> > On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss
> > You could choose to not show this, but I find it is often easier to
> > show thi
On Mon, Feb 28, 2022 at 12:55 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
>
>
> On Feb 28, 2022, at 5:49 AM, Ron Louzon via Dwarf-Discuss <
> dwarf-discuss@lists.dwarfstd.org> wrote:
>
> I have an application which uses DwarfLib to extract type information from
> d
reason, the sections relating
> to accelerated access are not useful for us as we’ll be visiting & indexing
> all CU DIEs ourselves.
>
Thanks for the details!
>
>
> Tom
>
>
>
> *From:* David Blaikie
> *Sent:* 24 February 2022 22:39
> *To:* Russell, Tom
>
ength entries), hence the issue.
>
>
>
> I’ll have to think about what a “modern” .debug_aranges might want to look
> like.
>
> Thanks,
>
> --paulr
>
>
>
> *From:* David Blaikie
> *Sent:* Thursday, March 11, 2021 3:48 PM
> *To:* Robinson, Paul
>
But yeah, curious to hear more
if/when you happen to have more to share.
- Dave
>
> On Thu, Feb 24, 2022 at 3:44 PM David Blaikie wrote:
>
>> Hey Samy - curious if you ever happened to end up getting further details
>> here.
>>
>> On Fri, Apr 9, 2021 at 1:05 PM
Hey Samy - curious if you ever happened to end up getting further details
here.
On Fri, Apr 9, 2021 at 1:05 PM Samy Al Bahra wrote:
> Thanks for the detailed response David.
>
> On Fri, Apr 9, 2021 at 2:52 PM David Blaikie wrote:
>
>> I'm not suggesting scanning all of
(might be easier to pick up from the thread where this came up or at least
CC/to the folks you're referring to (though perhaps you did and that got
stripped by the mailing list or something, not sure) - at least for me, I
have highlights for emails addressed to me that helps prioritizing/knowing
if
On Tue, Feb 1, 2022 at 3:45 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> I am in the process if writing a tool that can add .debug_names to a file
> that contains DWARF but doesn’t have an accelerator table that is adequate
> for debuggers to use. I was trying to
On Mon, Jan 24, 2022 at 5:37 PM Adrian Prantl wrote:
>
>
> On Jan 23, 2022, at 2:53 PM, David Blaikie wrote:
>
> A rather common "quality of implementation" issue seems to be lambda
> naming.
>
> I came across this due to non-canonicalization of lambda names
A rather common "quality of implementation" issue seems to be lambda naming.
I came across this due to non-canonicalization of lambda names in template
parameters depending on how a source file is named in Clang, and GCC's seem
to be very ambiguous:
$ cat tmp/lambda.h
template
void f1(T) { }
s
On Sun, Nov 7, 2021 at 12:36 PM Todd Allen wrote:
>
> Just spitballing an idea here, but would there be value in a new DW_FORM (or
> two) that referenced the names from .strtab or .dynstr, instead of .debug_str?
Yeah, something along those lines have crossed my mind too - I haven't
looked into it
On Mon, Nov 1, 2021 at 7:14 PM Greg Clayton via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> LLDB also uses mangled names. The clang compiler is our expression parser
> and it always tries to resolve symbols during compilation/JIT and it
> supplies mangled names when looking for func
On Mon, Nov 1, 2021 at 5:35 PM Cary Coutant wrote:
> >> I can't be sure about this exponential growth. I don't have the data
> to back it
> >> up. But I will say, when we created DWARF64, I was skeptical that it
> would be
> >> needed during my career. And yet here we are...
> >
> > Yep, still
al name as it would if it'd been given only
the simple name ("t1") and compare it to the one from clang. Then I can run
this over large programs and check everything round-trips correctly & in
clang, classify any names we can't roundtrip so they get emitted in full
ra
Hey Todd,
Just some details regarding the string reduction strategies I'm pursuing to
address DWARF32 overflowing .debug_str.dwo/.debug_str_offsets.dwo sections
in some large binaries at Google.
So the extreme cases I'm dealing with are predominantly C++ Expression
templates (in TensorFlow and Ei
unctor is mutable or
not. (so "std::any_invocable" is only callable when the object is
non-const, but "std::any_invocable" is callable even on if
it's a const object)
> --paulr
>
>
>
> *From:* Dwarf-Discuss *On
> Behalf Of *David Blaikie via Dwarf-D
C++ member functions can be qualified in a number of ways - classic CV
(const and volatile) qualifiers, and since C++11, lvalue (&) and rvalue
(&&) reference qualifiers. Details here:
https://en.cppreference.com/w/cpp/language/member_functions
A note on 5.10, page 127 says:
"C++ const-volatile qu
On Wed, Jun 30, 2021 at 5:37 AM Mark Wielaard via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Hi,
>
> We discussed 170427.3 Extending loclists with common sublists in the
> last meeting. http://dwarfstd.org/ShowIssue.php?issue=170427.3
>
> This issue was original part of a group of
Ah, in the sense that you want to be able to derive new types based on
the DWARF?
Fair enough.
Raphael's suggestion seems reasonable to me.
On Mon, Jun 7, 2021 at 11:20 AM Jan Kratochvil
wrote:
>
> On Mon, 07 Jun 2021 20:11:16 +0200, David Blaikie via Dwarf-Discuss wrote:
> &
, I took a look at the DWARF standard and I think that is actually
> something we should already emit in the form of a
> "DW_AT_byte_size 0" attribute at the field? Quote:
> If the size of a data member is not the same as the size of the type
> given for
On Sat, Jun 5, 2021 at 5:59 AM Joost van der Sluis via Dwarf-Discuss
wrote:
>
> Op 03-06-2021 om 00:50 schreef David Blaikie via Dwarf-Discuss:
> > On Fri, May 28, 2021 at 8:29 AM Joost van der Sluis via Dwarf-Discuss
> > wrote:
> >> Now in Pascal there are 'p
On Fri, May 28, 2021 at 8:29 AM Joost van der Sluis via Dwarf-Discuss
wrote:
>
> Hi all,
>
> I am one of the Free Pascal developers and also work on a debugger,
> aimed towards Free Pascal.
>
> Now in Pascal there are 'properties'. Maybe you know these from c# which
> has something alike. Basicall
On Fri, Apr 9, 2021 at 11:13 AM Samy Al Bahra wrote:
>
> Responses inline.
>
> On Fri, Mar 19, 2021 at 9:59 PM David Blaikie wrote:
>>
>> On Fri, Mar 19, 2021 at 9:34 AM Samy Al Bahra wrote:
>
>
> [...]
>
>>>
>>> This is quite old (e
es unnecessary
> complexity. Now I am considering going as far as adding a multi-threaded
> indexer for cases where a persistent cache / build system modifications
> aren't an option (work to begin in the next week or two).
>
> .debug_aranges would provide a lot of value to our users
can link today, for instance), you'd
probably /really/ want it to be linked in a content-aware manner, because
probing separate lookup tables (even if they're more designed for that)
per-CU doesn't probably gain you a lot).
- Dave
>
>
> Thanks,
> --paulr
>
> *From
e to think about what a “modern” .debug_aranges might want to look
> like.
>
> Thanks,
>
> --paulr
>
>
>
> *From:* David Blaikie
> *Sent:* Thursday, March 11, 2021 3:48 PM
> *To:* Robinson, Paul
> *Cc:* Cary Coutant ; DWARF Discuss <
> dwarf-discuss@lists.dwarfstd
On Thu, Mar 11, 2021 at 12:07 PM Mark Wielaard wrote:
> Hi David,
>
> On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote:
> > > > (I went to look a bit further and GCC's .debug_loclists.dwo but it
> seems
> > > > there's something abou
On Thu, Mar 11, 2021 at 5:48 AM wrote:
> Hopefully not to side-track things too much... maybe wants its own
> thread, if there's more to debate here.
>
Yeah, how about we spin it off into another thread (done here)
> >> For the case you suggested where it would be useful to keep the range
> >>
On Thu, Mar 11, 2021 at 11:44 AM Jakub Jelinek wrote:
> On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote:
> > Thanks! - is this proposed as a DWARF extension? I thought I remembered
> it
>
> 170427.1 I think. Note, what is emitted is different from what is bei
On Thu, Mar 11, 2021 at 2:55 AM Mark Wielaard wrote:
> Hi David,
>
> On Thu, Mar 11, 2021 at 01:01:05AM -0800, David Blaikie wrote:
> > +Mark in case he's got further context/perspective to share in the
> context
> > of this thread
>
> I haven't yet cau
On Thu, Mar 11, 2021 at 1:39 AM Jakub Jelinek wrote:
> On Thu, Mar 11, 2021 at 01:05:06AM -0800, David Blaikie wrote:
> > What's your take on:
> >
> > 1) Fixing GDB to handle GCC's current output.
>
> I don't know what GDB will do, it is up to the
On Thu, Mar 11, 2021 at 12:32 AM Jakub Jelinek wrote:
> On Wed, Mar 10, 2021 at 10:07:27PM -0800, David Blaikie wrote:
> > On Wed, Mar 10, 2021 at 9:38 PM Jakub Jelinek wrote:
> >
> > > On Wed, Mar 10, 2021 at 04:12:57PM -0800, David Blaikie via
> Dwarf-Discuss
>
1 - 100 of 182 matches
Mail list logo
