David,
DIRECTORIES:
The situation for directories seems pretty clear to me, and much the same as how
Philip saw it (I think). From 6.2.4, item 16 (page 157, lines 4-11):
The line number program assigns a number (index) to each of the directory
entries in order, beginning with 0.
Prior
I recall this being intentional as well. This is how I think of these items.
And this is just the gist of things. I didn't put on my ABI Lawyer hat for
this:
A DWARF expression is a stack machine that evaluates to a value.
A location description describes the "location" of an object. A "locati
Paul,
I haven't needed to contend with this issue. But as I was looking over the
standard, this was my initial gut reaction too: use the segment selectors. This
use actually does seem like it's a characteristic of the target architecture to
me. You started the discussion with "Harvard architect
Markus, Michael, David, Xing,
I always assumed that the segment support in DWARF was meant to be more general,
and support architectures where there was no single flat memory, and so the
segments were necessary for memory accesses. I personally have not dealt with
any architectures where DW_AT_se
Markus,
My experience with an architecture like this also is a GPU: the Nvidia CUDA
GPUs. I don't work on nvcc. I'm coming at this from the consumer side. But
what I've observed:
They use DW_AT_address_class with a CUDA-specific enum of address spaces, with
values for things like: global memor
Dave,
If I understand right: The space saving you're expecting is the near-elimination
of DW_AT_name strings. If they are only simple names like "T" and "int", they
can be placed into the string table once each, and it should be very small. But
you're expecting the DW_AT_linkage_name attributes
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?
It would only work if the symbols already were there, but I would expect that
for many/most/all(?) functions defined in the compilation unit.
>
> For ATE codes, the problem is with standardization if we wanted
> to standardize it in some way for DWARF6.
> The current DW_ATE_{,complex_}float is way too unspecific and historically
> can be about various formats.
> So, we'd need something like DW_ATE_{,complex_}ieee754_float
> (or ieee754_
>
> Dear all,
>
> During our work on debugging support of compute workloads on AMDGPU[1],
> we (at AMD) have been seeing two cases regarding description of
> bitfields in DWARF for which we do not find definitive answers in the
> DWARF documentation. For those cases, when experiencing with usual
On Mon, May 09, 2022 at 09:41:03PM +, Dwarf Discussion wrote:
> > 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 you
On Mon, May 09, 2022 at 04:09:59PM -0700, Michael Eager wrote:
> On 5/9/22 16:00, Todd Allen via Dwarf-Discuss wrote:
> > I suppose, if you didn't want to submit an issue, another solution would be
> > to
> > require the necessary tags & attributes in the ABI i
I've been playing catch-up on this discussion today. I was convinced of the
value early on just based on the need of this information to follow the ABI
parameter passing rules on certain architectures. And I was with you right
up until this V3 version. Comments below:
On Thu, Apr 13, 2023 at 11
On 4/21/23 16:31, Ben Woodard via Dwarf-discuss wrote:
>>
>>> Insert the following paragraph between the first paragraph of
>>> normative text describing DW_TAG_array_type and the second
>>> paragraph
>>> dealing with multidimensional ordering.
>>>
>>> -
On 4/24/23 13:27, Ben Woodard via Dwarf-discuss wrote:
>
>> As for NEON vs. SVE, is there a need to differentiate them? And can it
>> not be done by shape of the type?
>
> That one continues to be hard. ARM processors that support SVE also have
> NEON registers which like the Intel SSE MMX AVX kin
On 12/1/23 18:01, David Anderson via Dwarf-discuss wrote:
CAUTION! External Email. Do not click links or open attachments unless you
recognize the sender and are sure the content is safe.
If you think this is a phishing email, please report it by using the "Phish
Alert Report" button in Outlook.
Alexandre,
Since you mention that this for Ada, I'll mention this:
In our old Ada implementation, we make a decision not to use
DW_TAG_subrange_type as a general-purpose solution for Ada; we used it
only for array bounds, as described when it's introduced in section 5.5
Array Type Entries. (Well
On 9/30/24 11:30, Adrian Prantl via Dwarf-discuss wrote:
> ## Proposed Changes
>
> ### Table 2.1
> add `DW_TAG_property`.
>
> ### 5.7.6 add the following normative text
>
> `DW_TAG_property`
>
> Non-normative: Many object-oriented languages like Pascal and Objective-C
> have properties, which
ze the sender and are sure the content is safe.
> If you think this is a phishing email, please report it by using the "Phish
> Alert Report" button in Outlook.
>
>> On Oct 10, 2024, at 9:31 AM, Todd Allen via Dwarf-discuss
>> wrote:
>>
>> Adrian,
&
Perhaps you could use an attribute with the full "path" as a string.
I'm not sure it's high-value information, perhaps only useful for some
sort of "info type" command that wants to describe the type.
On 10/12/24 16:59, Adrian Prantl via Dwarf-discuss wrote:
> CAUTION! External Email. Do not click
Playing devil's advocate here: Can you mix these two types of
properties? That is, something like the following (please excuse any
wrong syntax):
type
TMyRecord = record
a,b: integer;
end;
TMyClass = class
function GetProp: TMyRecord;
procedure SetProp(AVal: TMyRecord);
propert
I'm a bit late to the party, but here goes...
Our Ada compiler has support for this, described in terms of arrays.
It's similar to the Pascal example that someone provided. If the only
way to get a type like this in PL/I is with a bit string, then the
producer could still describe this as an arra
Adrian,
I noticed a wording duplication in my read-through this morning in 5.19(?),
paragraph 5:
Some languages can automatically derive property derive accessors from ...
I think that 2nd "derived" needs to go.
Todd
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.
FWIW, when we at Concurrent were in the compiler business, our C++ compilers
generated two vendor-defined attributes, both hanging off the
DW_TAG_{structure,class}_type. Here are a couple with some sample locations:
DW_AT_vtable_location [DW_OP_plus_uconst 0; DW_OP_deref]
DW_AT_type_vtable_locat
Tom,
When I was adding DWARF support to my company's Ada compiler many years ago,
using reference, exprloc, loclist, etc. forms on attributes that normally
didn't allow them was a very common tactic. Ada is not a language that DWARF
claims to support fully (not even close), so I always assumed
ssuming a static location.
On 5/7/25 07:07, Pierre-Marie de Rodat wrote:
> Hello,
>
> On Wed, May 7, 2025 at 2:49 PM Todd Allen via Dwarf-discuss
> wrote:
>> In 250506.2, the use of a rnglist is throwing me. I would expect the
>> lifetime of a vtable to be the whole pr
BTW, I don't think you need to create the vtable on the fly in that
case. The Pkg.Print function will need a static link, but the vtable
doesn't need to encode that. I just checked our Ada compiler. We
stopped development on this compiler after Ada 95, but the only change I
had to make to your e
tribute, which appears to be
incorrectly implemented in compilers today.
-cary
On Fri, May 2, 2025 at 1:31 PM Todd Allen via Dwarf-discuss
mailto:dwarf-discuss@lists.dwarfstd.org>>
wrote:
FWIW, when we at Concurrent were in the compiler business, our C++ compilers
generated two vendor-de
27 matches
Mail list logo
