Draft
Conversation
Signed-off-by: Ben Woodard <woodard@redhat.com>
This is a novel approach to fixing the refined type problem. Basically rather than changing the behavior of location lists, or adding a secondarly location list which specifies which provides the type for a location, this addresses at least the most critical problems by removing a restriction on DW_OP_reinterpret. Signed-off-by: Ben Woodard <woodard@redhat.com>
Locations on the stack didn't address what DW_OP_reinterpret does when the top of the stack is a location. This further modifies the description of the operator to clarify how it handles a location on the stack. It also fixes a couple of typos. Signed-off-by: Ben Woodard <woodard@redhat.com>
* Add a couple more use cases from Baris's original proposal.
* Remove the restriction on DW_OP_reinterpret that it can only be used
on base types. This was alwasys the intent but I accidently left
that verbiage in the proposal.
* Add an example
Signed-off-by: Ben Woodard <woodard@redhat.com>
ghost
reviewed
Jan 27, 2026
Comment on lines
+13
to
+14
| number. However, if due to optimization that variable is moved into a | ||
| 80b extended precision register for a block of PCs. If a consumer |
There was a problem hiding this comment.
The sentence sounds broken. How about this:
"However, due to optimization, the variable may be moved into an 80b extended precision register for a range of PCs."
| manually. A programmer may not know to do this or know how to do | ||
| this. It also is a very cumbersome work around. | ||
|
|
||
| A better option is to address this situation is to have the producer |
Comment on lines
+79
to
+80
| having the actual known type which is known by the producer makes this | ||
| simpler. |
There was a problem hiding this comment.
Also, vtable may not always exist (e.g. for POD classes).
| ### Derived types | ||
|
|
||
| One example could be when a compiler knows the type more precisely | ||
| than the variable's type natively idicates. For eample: `BaseV *bv2 = |
| simpler. | ||
|
|
||
| It also allows a consumer handle situations which are currently not | ||
| handled such as `(gdb) p func( *bv2)` when `int func(Derived arg);` |
| ### void pointers with known types | ||
|
|
||
| Another potential use is to give the objects pointed to by void | ||
| pointers their type. For example given `int x;void *generic=&x` the |
| moved from system memory to GPU memory by an optimization, the | ||
| consumer will need to know that the size of the pointer has changed | ||
| from 8 bytes to 4 bytes when accessing it. | ||
|
|
There was a problem hiding this comment.
Another interesting example is the function type change described here:
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2026-January/002789.html
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.