FWIW, I really like this proposal and I can already imagine several ways
I could use it when doing static analysis of binaries.
-ben
On 4/7/25 5:31 PM, Cary Coutant via Dwarf-discuss wrote:
# Enhancement: Associating allocator call sites with type information
Thanks! This is Issue 25040
so other tools can implement it. If the idea gets abandoned then the
encodings only exist for that release of the DWARF version and the
encodings can be reused in the next DWARF cycle.
That is enough for now,
Ron
On Fri, Nov 10, 2023 at 4:52 PM Ben Woodard via Dwarf-discuss
wrote:
I’ve asked this question personally many times directly to members of the executive committee. The overall answer seems to be “when we are done”. The thing is, there are quite a few proposals sitting in the DWARF issue queue that have yet to be discussed AT ALL in the official DWARF committee meeti
DWARF Extension Registry
Background
The DWARF standard has always had the wisdom to acknowledge the need for
Vendor Extensibility. Section 1.3.13 describes this policy. For the
producers it explicitly reserves some of the valid values for encoding
various constructs and promises not to use
Can we please add a link to the current evolving DWARF6 standard working draft
somewhere on https://dwarfstd.org/index.html
I was wanting to show someone that we have the current working copy that we
produce and I was sure that you could navigate to it from the main page but I
was unable to fi
I was looking at 2 level location tables
https://dwarfstd.org/issues/140906.1.html and can see how it could
improve things there. One thing that I noticed about it was that it was
based on some prior art done in HP-UX.
A nut that I have been trying to crack for a few years but haven't
really
This is my long overdue revision my vector types proposal. The main
difference is Todd Allen and Markus Metzger together convinced me that
adding flavors to the tensor attributes were not needed. It should
replace the current proposal https://dwarfstd.org/issues/230413.1.html
Tensor types
Som
On 4/24/23 13:17, Todd Allen via Dwarf-discuss wrote:
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
On 4/24/23 09:50, Todd Allen via Dwarf-discuss wrote:
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/21/23 12:56, Todd Allen via Dwarf-discuss wrote:
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.
Really -- that is what I care about to
Here is V3 of what was my vector types proposal.
Changes since V2:
We discussed this extensively in the DWARF for GPUs meeting. Cary
originally wanted it to be a TAG rather than an attribute on an array
and quite frankly, I don't care and so my default position is "What Cary
wants, Cary gets"
I believe that all three points that you bring up here are correct and I
will fix them in V3 of my proposal.
On 4/6/23 03:44, Metzger, Markus T wrote:
Hello Ben,
This is version 2 of my vector types submission.
Differences from V1:
- Made the submission about vector types rather than vecto
On 4/6/23 03:47, Metzger, Markus T wrote:
Hello Jakub, Ben,
On Wed, Apr 05, 2023 at 07:16:35PM -0700, Ben Woodard via Dwarf-discuss wrote:
To distinguish these vector types from regular C arrays, GCC's DWARF
describes a vector type as an array with the DW_AT_GNU_vector
attribute. Clang
On 4/6/23 03:16, Jakub Jelinek wrote:
On Wed, Apr 05, 2023 at 07:16:35PM -0700, Ben Woodard via Dwarf-discuss wrote:
To distinguish these vector types from regular C arrays, GCC's DWARF
describes a vector type as an array with the DW_AT_GNU_vector
attribute. Clang also supports the GCC v
This is version 2 of my vector types submission.
Differences from V1:
- Made the submission about vector types rather than vector registers.
- Substituted Pedro's much better introduction for my own with minor edits.
- Removed the modifications to the DWARF Stack. The AMD people like
Pedro and T
Pedro Alves via Dwarf-discuss
>>>> >>> <mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
>>>
>>> Hi Ben,
>>>
>>>>On 2023-03-24 6:19 p.m., Ben Woodard via Dwarf-discuss wrote:
>>>
>>>> I will admit that in its current st
-ben
> On Mar 30, 2023, at 1:27 PM, Pedro Alves wrote:
>
> On 2023-03-29 8:55 p.m., Ben Woodard via Dwarf-discuss wrote:
>>
>> On 3/28/23 13:17, David Blaikie wrote:
> ...
>>> What DWARF should be used to describe the type of 'a'? And how do
On 3/28/23 13:17, David Blaikie wrote:
DW_AT[_GNU]_vector is best understood not as "a hardware vector register" but rather as a
marker that "this type is eligible to be passed in hardware vector registers at function
boundaries according to the platform ABI".
My 2c would not be to describe t
Thank you Kyle,
On 3/28/23 12:49, Kyle Huey wrote:
[1] Inferring the function return value location causes issues in
other contexts and I have a DWARF issue on that (221105.1)
Let me publicly state my support for your proposal for how to specify
the return value of a function.
I'm not sure
On 3/27/23 23:51, Cary Coutant wrote:
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_vecto
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 O
don’t think it makes sense here.Would it be helpful if I posted code fragments with the associated DWARF?As I say, I am just puzzling... RonOn Fri, Mar 24, 2023 at 2:20 PM Ben Woodard via Dwarf-discuss <dwarf-discuss@lists.dwarfstd.org> wrote:
I was working on this before the
That reminds me.
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
exp
I was working on this before the change of administration.
Vector types have been around for a very long time and compilers use
them but are not handled in the DWARF standard right on DWARF5. I think
that this was basically something that was overlooked and no one filed
an issue to get it addr
V2 now with tools:
http://ssh.bencoyote.net/~ben/DWARF_6_DRAFT_tools.png
It is kind of a menu. Pick your favorite dwarf body, your favorite
helmet, your favorite tool. Or suggest something different. Since it is
just a draft she just just did it over the DWARF6 mockup - we can
discuss font la
right hand, so would appear on the left of the image -
or swap version/tool around as folks see fit).
In general my personal font choice is more around example (4), but the
thick/sturdy-ness of (2) is probably more in keeping with the theme.
On Tue, Mar 21, 2023 at 2:44 PM Ben Woodard via Dwarf-di
It looks like https://wiki.dwarfstd.org/Dwarf_Version_Numbers.md hasn't
been brought up to date with DWARF5 yet. This table can be useful
because the versions of different sections do not necessarily follow the
major DWARF version.
For example, last year I had a question from a tool author whe
It has been kind of tense around here for a while; let's have some fun.
The DWARF logo is quite old. There are many problems with it as a logo.
1. It is a png and though there appears to be several versions of it at
different sizes it is a raster and so it doesn't scale well
2. The image itse
28 matches
Mail list logo
