Adrian et al,
Re 1: OK, not bad. I would tweak a bit farther:
. replace "they are implemented" with "access is implemented"
. replace "both" with "programmed constraints, including".
So the results reads:
[Non-normative] *Object-oriented languages like Pascal and Objective-C have
properties, w
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
It seems to me that the problem here is not so much in the DWARF standard,
as in the DWARF that is produced.
The DWARF representation generally serves to capture all the semantic
information needed to properly represent
the source program. In the example discussed here it appears that GCC does
tha
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.
Jayvee,
Your question seems quite clear. I hope this response is equally so.
First off, the segment attribute names a register, whose contents is added
to the address value computed by the other address expression. So in a real
sense, a pair of attributes like DW_AT_segment and DW_AT_pc forms "ju
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_point with my
>
20 matches
Mail list logo
