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
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.
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
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
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
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,
&
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
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 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.
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 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.
>>>
>>> -
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 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
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
>
> 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
>
> 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_
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.
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
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
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
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
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
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
23 matches
Mail list logo
