t. On
> the other hand, getting the address of the "A" member would not be
> sufficient: in more complex cases, the offset of the "A" member can
> depend on discriminants!
>
> I tried to look at the implementation of DW_OP_push_object_address in
> GDB, but it looks like it'
dress space
>instance can be accessed when given a flat address that maps to the group
>or private segments. It appears both gdb and lldb provide this.
>
FWIW, the use of DW_AT_address_class on pointer & reference times also is how
Nvidia's CUDA compiler desc
aced DW_AT_encoding attributes directly on
DW_TAG_enumeration_type to indicate the underlying signedness. Ada never was
truly supported, so we just viewed it as part of the Ada support we'd defined.
--
Todd Allen
Concurrent Computer Corporation
_
directory table starts with 1; 0 meant
"go use DW_AT_comp_dir".
For DWARF 5, the directory table starts with 0. And presumably the 0th index
is essentially the same as DW_AT_comp_dir.
FILES:
The case for the file table being base 1 seems strong.
--
Todd Allen
Concurrent Real-Ti
o the DWARF expression
category.
It think it feels a little blurry only because locdescs came first, and then we
co-opted them for DWARF expressions, and restricted the use of certain operators
in that case. And then it eventually changed into what we have now. But a lot
of us remember the histor
illing to write up whatever needs writing up, either as a
> proposal or as a wiki entry.
>
> Thanks,
> --paulr
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
dress-space. This sounds pretty close. I'm a bit
>thrown off by the example, though.
>
>
>
>Thanks,
>
>Markus.
>
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
_AT_address_class : ptxLocalStorage
I don't know your architecture, but I'd expect something similar to work for any
GPU with heterogeneous memories.
--
Todd Allen
Concurrent Real-Time
On Mon, Jul 20, 2020 at 08:31:53AM +, Dwarf Discussion wrote:
> Hello Michael,
>
> > &
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
>Dwarf-Discuss mailing list
>[5]Dwarf-Discuss@lists.dwarfstd.org
>[6]http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
> ___
> Dwarf-Discuss mailing list
> [7
umber of bits for each field, and
a mention of any major peculiarities (e.g. skewed bias, inf/nan unsupported,
etc.).
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
does impact the ABI, I'm wondering if that impact is indirect: that is,
the presence of this 0-width bit field changes an attribute of the next field,
and that attribute is responsible for difference in the behavior. If so, is
there any way other than a 0-width bit field to cause the same
mp; attributes in the ABI itself. We already expect
ABI documents to provide things like register values, CFI initial values, and
some more esoteric stuff (augmentations, non-standard endianity & isa). An ABI
that required descriptions in ABI-specific situations like these two seems
reasonable to me. And it places no burden on compilers for other ABI's.
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
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
r++, or disallowing casts, or certain flavors of casts? (Those were
the differences I spotted in that table.) This doesn't seem terribly
compelling. But if others think it is, maybe this should be broken up into
distinct features instead of a lumpy enum?
--
Todd Allen
Concurrent Real-Time
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
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
WARF 1 spec, some tag & attribute
values from DWARF 1 were reserved in DWARF 2 just to avoid confusion (e.g. tags
0x06, 0x07, 0x09, 0x0c, 0x0e). So that was a choice made even for the
spec-defined values. This is a bit apples & oranges, but I think it's
interesting that the thinking b
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
30 matches
Mail list logo
