Re: [Dwarf-discuss] Wiki list of vendor extensions.
Hi, On Sat, Mar 25, 2023 at 11:24:41AM +0100, Mark Wielaard via Dwarf-discuss wrote: > Hi, > > On Fri, Mar 24, 2023 at 05:21:20PM -0700, David Anderson via Dwarf-discuss > wrote: > > On 3/24/23 13:56, Ben Woodard via Dwarf-discuss wrote: > > >Tangential to Scott's request, one of the requests from the tool > > >developer community that I work with is to add a new wiki article > > >which lists all the vendor extensions for the various compilers. > > >Obviously this would include but not be limited to the Vendor > > >specific DWARF expression operations. > > > > The LLVM folks and myself have tried to make vendor extensions known. > > At least the names. > > > > https://www.prevanders.net/dwarf.h > > > > is my attempt (flawed, no doubt). > > It's not quite clear what you might mean to have in a wiki > > article about each name. > > elfutils has a list of vendor extensions recognized (but not always > handled): https://sourceware.org/elfutils/DwarfExtensions > > Maybe we can combine that information into a new wiki.dwarfstd.org > article? That would seem to be a good way forward in my opinion. However, I find there might still be a discoverability issue; i.e. How someone who does not know about the wiki article or pages you listed above finds out it exists? Could the standard include a (non normative) mention that vendors are encouraged to communicate their use of an opcode on the wiki (or other form of registry)? Any vendor is still free to use any user opcode to its liking, but vendors who want to achieve interoperability and broad tools support can 1) make sure they to not accidentally use opcodes already used by others and 2) make their use of an opcode recognized in the community. The intend is not to have the standard dictate how user opcodes should be used (that would defeat the point of having them), but merely leverage the fact the DWARF standard the natural common entry point. Best, Lancelot. > > Cheers, > > Mark > -- > Dwarf-discuss mailing list > Dwarf-discuss@lists.dwarfstd.org > https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] Enhancement: Expression Operation Vendor Extensibility Opcode
I'm sorry Scott, I did not intend to hijack your proposal. In essence, I
was saying that I support a the registry part of your proposal below.
That has been one of the long time requests from the tool developers
that I work with.
On 3/24/23 13:21, Linder, Scott via Dwarf-discuss wrote:
[AMD Official Use Only - General]
Background
==
The vendor extension encoding space for DWARF expression operations
accommodates only 32 unique operations. In practice, the lack of a central
registry and a desire for backwards compatibility means vendor extensions are
never retired, even when standard versions are accepted into DWARF proper. This
has produced a situation where the effective encoding space available for new
vendor extensions is miniscule today.
I understand the desire for each particular vendor opcode to have a
semantic meaning that is fixed throughout time. This simplifies some
areas of the DWARF parsers because they do not have to disambiguate the
semantic meaning of a particular constant based upon the version of the
DWARF that is being processed. This is particularly helpful when you are
handling a an object that may be linked together containing CUs that
were produced with different versions of the standard. This is not only
true for DWARF Vendor expression operations, it is true of the broader
DWARF standard.
In essence up to this point a DWARF5 enabled parser, has been be capable
of handing DWARF{4,3} and possibly even DWARF2 without modification. I'm
not really aware of any breakages where interpreting an older version of
DWARF requires being aware of the DWARF version number.
Does this continue to be an goal for DWARF6? Whether or not this is
true, we should make this explicit.
If not, it would provide an opportunity for tool developers to begin
building the DWARF version sensitive parsers necessary to handle that in
the cases where within an object CUs can have different versions of
DWARF. An explicit statement of intent would also give the vendor
compiler developers and opportunity make the decision, that with DWARF6
they could begin to reuse or recycle vendor extensions which are no
longer needed for whatever reason.
I personally feel like DWARF has been around for about 30 years, it is
kind of due a flag day allowing accumulated cruft to be purged. The
producers and consumers just need to all move together and DWARF6 may be
a good time to do this.
To expand this encoding space we propose defining one DWARF operation in the
official encoding space which acts as a "prefix" for vendor extensions. It is
followed by a ULEB128 encoded vendor extension opcode, which is then followed
by the operands of the corresponding vendor extension operation.
This scheme opens up an infinite encoding space for arbitrary vendor
extensions, and in practical terms is no less compact than if a fixed-size
encoding were chosen, as was done for DW_LNS_extended_op. That is to say, when
compared with an alternative scheme which encodes the opcode with a single
unsigned byte: for the first 127 opcodes our approach is indistinguishable from
the alternative scheme; for the next 128 opcodes it requires one more byte than
that alternative scheme; and after 255 opcodes the alternative scheme is
exhausted.
Since vendor extension operations can have arbitrary semantics, the consumer
must understand them to be able to continue evaluating the expression. The only
use for a size operand would be for a consumer that only needs to print the
expression. Omitting a size operand makes the operation encoding more compact,
and this was deemed more important than the limited printing use case.
Therefore no ULEB128 size operand is present to provide the number of bytes of
following operands, unlike DW_LNS_extended_op.
A centralized registry of vendor extension opcodes which are in use, maintained
on the dwarfstd.org website or another suitable location, could also be
implemented as a part of this proposal. This would remove the need for vendors
to coordinate allocation themselves, and make it simpler to use more than one
vendor extension at a time. As there is support for an infinite number of
opcodes, the registration process could involve very limited review, and would
therefore pose a minimal burden to the maintainer of such a registry.
My only concern with this proposal is really, I believe that vendor
specific extensions should be kept to a bare minimum. It makes the job
of consumers much more difficult, especially when tools need to support
multiple producers.
I would say from a consumer perspective, I would prefer keeping the
range of vendor extensions smaller, possibly forcing a flag day to
facilitate reuse of old disused encodings, and making the process of
standardizing needed new behaviors easier and more frequent. I believe
that there will always need to be encoding space to prototype features.
However, I believe that the community is best served by having new
feature
Re: [Dwarf-discuss] Enhancement: Expression Operation Vendor Extensibility Opcode
Hi - > I understand the desire for each particular vendor opcode to have a > semantic meaning that is fixed throughout time. [...] Does this > continue to be an goal for DWARF6? Whether or not this is true, we > should make this explicit. If not, it would provide an opportunity > for tool developers to begin building the DWARF version sensitive > parsers necessary [...] I'm not aware of any DWARF standard assertion about the persistence of the semantics of vendor opcodes across time or versions. If so, there is nothing stopping a vendor from reusing any extension code toward different ends in DWARF6. That would not even take flag-day coordination with other vendors. - FChE -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
Re: [Dwarf-discuss] ISSUE: CPU vector types.
> Vector registers > > It has been the long standing existing practice to treat hardware > vector registers as arrays of a fundamental base type. To deliniate > these hardware register arrays from arrays in the language source they > have been given the DW_AT_GNU_vector attribute. This proposal simply > standardizes the existing behavior. > > In Section 2.2 Attribute Types, DW_AT_vector and > DW_AT_variable_vector_width shall be added to Table 2.2 > > > DW_AT_vector| A hardware vector register > DW_AT_variable_vector_width | Array bound for hardware > | implementation defined vector register > | width > I don't understand what tags this DW_AT_vector attribute would apply to. Vector registers aren't *types*, they're *locations*, so it doesn't really make sense to me to put this attribute on a DW_TAG_array_type. We don't have DW_TAGs that describe registers; the ABI defines the registers and DWARF producers and consumers should understand and agree on the sizes and shapes of the various registers. In Tony's proposal, the new attribute modifies a base type, thus introducing a vector type, which might get placed in a vector register. But there, I don't see how the vector base type is fundamentally different from an array type. It seems it's just a dodge to make it a base type so that we can put whole vectors on the stack. Maybe what we're looking for is a DW_TAG_vector_type, whose DW_AT_type attribute gives the base type for each element of the vector. This seems to be more DWARF-like, and if we decide there's a reason to allow stack entries with vector types, we can do that. -cary -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
