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