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 parse the values in order to determine where the next DIE
start
John Reagan tells me his message didn't go to the list,
but Jakub quotes it in his reply. My comments below.
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, January 25, 2022 7:10 AM
> To: John Reagan
> Cc: Robinson, Paul ; ja...@redhat.com; dwarf-
> disc...@lists.dwarfstd.or
+ John Reagan who can (I hope) speak to the choice of using different
ATE codes for distinguishing VAX/IEEE floats in OpenVMS.
--paulor
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Jakub Jelinek via Dwarf-Discuss
> Sent: Monday, January 24, 2022 5:17 PM
> To: Jason Merrill
>
According to https://en.cppreference.com/w/cpp/language/function the
cv-qualifier is allowed only on non-static member functions, which are exactly
the ones that have an implicit this-pointer parameter.
cv
-
const/volatile qualification, only allowed in non-static member function
declarations
Ar
In the interest of alerting others who maintain lists of
vendor-defined tags, attributes, etc.:
LLVM recently added DW_TAG_LLVM_annotation (0x6000).
This is a generic way to add an arbitrary name/value pair to
any existing DIE; its use within LLVM is to propagate certain
source attributes into th
> it sounds like the general consensus is that:
>
> * In DWARF 5, file name entries are zero-indexed.
> * DW_AT_decl_file of 0 means the first file name entry (index 0, which
> happens to be the same as DW_AT_name of the unit). It does NOT mean an
> unspecified file; that was an oversight in t
Tom Russell asked me about this, and I think it's a bug in the
v5 specification.
In v5, the line-table header's directory table added an entry for
directory 0. Previous versions had directory 0 mean the current
compilation directory, i.e. DW_AT_comp_dir from the compile unit DIE.
The file table
Yeah, we talked some last year about formalizing this more into the -1
tombstone - I thought maybe Paul had proposed that for standardization, though
at a glance I don't see the proposal. It's probably somewhere there.
200609.1 Reserve an address value for “not present”
--paulr
Tom Russell could perhaps speak to this better, but my understanding is that
our debugger guys like having .debug_aranges, because parsing the CU DIE does
take that extra effort. I am unfamiliar with their code so I have to take
their word on it. But I can certainly imagine that probing hundre
Hopefully not to side-track things too much... maybe wants its own
thread, if there's more to debate here.
>> For the case you suggested where it would be useful to keep the range
>> list for the CU in the .o file, I think .debug_aranges is what you're
>> looking for.
>
> aranges has been off by d
(re-sending because outlook omitted the group address)
> -Original Message-
> From: Dwarf-Discuss On Behalf
> Of Jakub Jelinek via Dwarf-Discuss
> Sent: Tuesday, March 9, 2021 10:16 AM
> To: Andrew Cagney
> Cc: DWARF Discussion
> Subject: Re: [Dwarf-Discuss] compilers generating ABI non
Happy New Year, everybody!
A colleague just had a question for me about DW_OP_implicit_value
which led me to wonder why we have both that and DW_OP_stack_value.
Looking at http://dwarfstd.org/ShowIssue.php?issue=071227.1 which
introduced the latter, it says in part:
(This operator is similar to
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, October 24, 2018 6:16 AM
> To: Rafik Zurob
> Cc: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Alternate entry points
>
> On Wed, Oct 24, 2018 at 01:00:26AM -0400, R
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Paul Robinson via Dwarf-Discuss
> Sent: Tuesday, October 23, 2018 5:40 PM
> To: dwarf-discuss@lists.dwarfstd.org
> Subject: [Dwarf-Discuss] Alternate entry poi
On one of the LLVM lists, a question came up about representing alternate
entry points. Fortran and PL/I and probably other languages can do this.
I see DWARF has DW_TAG_entry_point, however the spec is completely silent
on how this entry relates to other entries for the same subprogram.
Should th
Recently somebody was poking around looking at compressed DWARF sections,
and observed that some tools (dwarfdump, objdump, readelf) were dumping
them just fine, but without any indication that the original section was
compressed (citing ELF flag SHF_COMPRESSED). If anybody on this list
happens to
Filed as bug #23310 at sourceware.org/bugzilla.
--paulr
> -Original Message-
> From: Dwarf-Discuss [mailto:dwarf-discuss-boun...@lists.dwarfstd.org] On
> Behalf Of Paul Robinson via Dwarf-Discuss
> Sent: Monday, June 18, 2018 1:06 PM
> To: ni...@redhat.com
> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Monday, June 18, 2018 10:01 AM
> To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Cc: binut...@sourceware.org
> Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
>
> Hi Paul,
>
> >>> I p
cc binutils
> -Original Message-
> From: Nick Clifton [mailto:ni...@redhat.com]
> Sent: Friday, June 15, 2018 6:18 AM
> To: Robinson, Paul; dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] Asm syntax for DWARF 5 line table info
>
> Hi Paul,
>
> > I have been working on add
I have been working on adding DWARF 5 support to LLVM, and some of
that support requires some assembler syntax tweaks. It has been
suggested that I publicize those tweaks outside of the LLVM world,
and this list seems like the most likely place to find the people
who would be most interested in
> -Original Message-
> From: David Anderson [mailto:dave...@linuxmail.org]
> Sent: Thursday, April 26, 2018 4:48 PM
> To: Robinson, Paul
> Subject: Re: [Dwarf-Discuss] Line table "no-op" sequence, leb length
>
> On 04/26/2018 10:04 AM, Paul Robinson via D
> >> One technique you haven't mentioned is to stretch out LEB128 numbers
> >> with extra 0x80's.
> >
> > Yeah, I kind of don't like abusing the LEB format like that. Maybe
> > for one or two bytes, but not arbitrarily long strings (as you note,
> > some consumers will decide it's corrupted data).
> One technique you haven't mentioned is to stretch out LEB128 numbers
> with extra 0x80's.
Yeah, I kind of don't like abusing the LEB format like that. Maybe
for one or two bytes, but not arbitrarily long strings (as you note,
some consumers will decide it's corrupted data).
> When doing an in
Recently I had a chat with one of the linker developers on my team.
He was trying to work out how to insert what would effectively be a
no-op sequence into the line table.
One reason to do this is if a producer wanted to pad the line table
for a compilation unit, either for alignment purposes or t
+wolfgang who did the string-offsets implementation.
--paulr
> -Original Message-
> From: David Anderson [mailto:dave...@linuxmail.org]
> Sent: Monday, April 16, 2018 5:56 PM
> To: David Blaikie; Robinson, Paul; Pavel Labath
> Cc: dwarf-discuss@lists.dwarfstd.org
> Subject: Re: [Dwarf-Disc
The intent of the index is given pretty plainly in the non-normative text at
the bottom of p.137; you should be able to look up any unqualified name in the
index. If the normative text doesn't accomplish that, we have an opportunity
to improve the spec. ☺
FWIW here's my take:
Enumerations are
26 matches
Mail list logo
