(2, 3, 5), but left the more substantive ones (1, 4) for
> Adrian to address.
>
> -cary
>
> On Tue, Mar 11, 2025 at 8:59 AM Ron Brender wrote:
>
>> Mmore suggested changes are attached...
>>
>> Ron
>>
>>
>> On Mon, Mar 10, 2025 at 12:46 PM Adrian P
Mmore suggested changes are attached...
Ron
On Mon, Mar 10, 2025 at 12:46 PM Adrian Prantl via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Here is the latest revision:
>
> - Removed Pascal-specific wording from text in 5.19 (field -> data member)
> - added updates for Appendix A
John and all,
Well, a directory is a file, right? Ergo...
OTOH, you have a point about applicability. How about making a concrete
proposal?
DWARF is permissive in any case...
Ron
On Tue, Jan 14, 2025 at 7:52 AM John DelSignore via Dwarf-discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> In
>The current DWARF 5 specification's statement in Section 2.17.3 (p. 53,
line 15) that "Bounded range entries in a range list may not >overlap" is
overly restrictive and doesn't reflect valid cases where identical code
sequences are merged. The specification needs to >differentiate between
valid id
>Consider a type that is a subrange of an integral base type, with an
>explicitly specified bit size smaller than the bit width of a storage
>unit.
>
>When used for a standalone variable, its byte size is the same as that
>of the base type, i.e., the type is padded to a whole unit.
The variable's
Cary,
>DW_LANG_HIP/DW_LNAME_HIP was assigned first, but for some reason, the list
was out of order, so when I assigned >DW_LNAME_Assembly, it looked like
0x001c was the last code assigned. I think it would be safer to reassign
>DW_LNAME_Assembly as 0x0029.
I think it would be safer to just leave
Cary,
Actually, it would help my process if you would announce at each meeting
what language names and their corresponding issue numbers were processed in
the prior period. The point is to get that information into the Minutes. No
discussion needed, just an announcement. Actually if that informati
It appears that DW_LNAME_HIP, proposed in 230120.4, never got incorporated
into the DWARF working document (so there is no duplication). Perhaps
because the Issue status is "Code Assigned" rather than Approved. That
status really only applies to the V5 code assignment actually.
Anyway, I'll fix i
Tim writes:
DWARF5 Section 2.17.3 explicitly states that *Bounded* ranges cannot
overlap, but there is no comment about contiguous ranges
(DW_AT_{low,high}_pc) or *Base address* range list entries. Is this a case
of "the exception that proves the rule"?
A "bounded range" is a contiguous range by
Various thoughts...
> Not sure if supporting dimensions in the way which is done
> for arrays is needed (I believe vector types are always one-dimensional
> indexed from 0).
"always"? There are many element by element operations on multidimensional
arrays that might benefit
from use of vector har
Ben,
I am puzzling over your vector types proposal as well as the Tye proposal
you cite. My impression is that they are hard to distinguish.
The Tye proposal turns CPU vector types into base types while your proposal
keeps them distinct, but then you add this additional class of types to the
base
FWIW, the "master" in the DWARF .git distro is an .eps file not .png--not
that that really matters. I don't know
where it came from other than Michael gave it to me to use. The .eps does
contain some Copyright lines, namely
% Copyright (c)1992-98 Corel Corporation
% All rights reserved. v8.0 r0
r/compiler would do it properly.
So my suggestion is to file a bug report with CLANG, requesting they
correct their DWARF output to reflect all details needed
by your language.
Ron Brender
On Mon, May 9, 2022 at 7:13 AM Lancelot SIX via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org&
For the sake of history, I don't recall much of the technical issues, but I
do recall working with Paul way back when (we were both with HP at the
time) to come up with a single common HP-wide list of base types and codes
for all the floating-point types in use across HP.
I support Paul's suggesti
Responding to Cary's question several exchanges back
>Do you remember why kept DW_AT_ranges in the skeleton CU even after we
>moved the range lists to the dwo? Was it the intent all along that the
>DW_AT_ranges attribute in the skeleton CU would reference the
>.debug_rnglists section, while DW_AT_
David,
I wouldn't be too puzzled. What you are seeing is clearly a cut and paste
error
on the part of your friendly document editor (that would be me). Clearly
there
should not be mention of default location entries in the context of address
ranges (in contrast with location lists). There are a la
Jayvee,
If you are dealing with a linear 32- or 64-bit address space then there are
no segments to worry about, so the question is moot. If you are dealing
with a segmented address space, then the problems you describe are exactly
those that debuggers on segmented machine dealt with all the time.
DW_AT_segment register would ever be anything other than a simple
unrelocated segment register name.
This is not because other expressions (whether affected by relocations or
not) could not be meaningful ever for any architecture but because they are
not useful on the x86 specifically.
Hope that help
Comments are inline...
On Thu, Dec 6, 2018 at 7:40 AM David Stenberg via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> Hi!
>
> When GDB and LLDB perform virtual unwinding, they subtract one byte
> from the return addresses of the outer frames. This is for example
> necessary when unw
OpenVMS Fortran on Alpha and Itanium uses DW_TAG_entry_point as well, just
as shown in the prior email.
Ron Brender
On Wed, Oct 24, 2018 at 1:00 AM Rafik Zurob via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> > I dug up gfortran 5.4, which does not emit DW_TAG_entry_p
DW_TAG_skeleton_unit -- yes. It will be the only DIE in the compilation.
DW_TAG_imported_unit -- no. Importing another separate unit to be a new
separate unit makes no sense,
Ron
On Mon, Oct 9, 2017 at 3:50 PM, Jonas Devlieghere
wrote:
> Hi everyone,
>
> For the verifier in llvm-dwarfdump I’m t
The original proposal extends DW_AT_location in a way that seems not really
in the spirit and intent of that attribute.
Two alternatives come to mind:
1) Invent a new pseudo-device to use in the name string of a standard
DW_AT_name attribute. For the name "inmemory:\\0x", the debugger
wou
Looking back through old email and DWARF drafts, I find:
The constant/variable null reference implies no default verbiage existed in
V2 (as others have noted). Al Grant (by way of David Anderson) first raised
the issue of why a reference to an otherwise unnecessary constant should be
needed to han
1. I am not enough of an C++ lawyer to comment on the meaning of lexical
blocks inside "std". But I don't recall that the formal definition of "std"
has any such blocks--if not, the presence here is either wrong or the
sloppy remains of some block nested in something else that did not get
properly
beyond the
discussion here.
In any case, my involvement and practice of Ada is decades old so I hope I
am not confusing matters. But I do suggest soliciting the advise of a
current Ada person for better insight.
Ron Brender
(former Ada Distinguished Reviewer and standards committee member)
On W
Your assumption is not justified. Use of any proposed, or even
"adopted", extension by an implementation is strictly *own risk*.
There is a well-defined implementation defined extension mechanism
that provides an alternative..
Note that the status of the DWARF issue you mention is "open" -- that
i
26 matches
Mail list logo
