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
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
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
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
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
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
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
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
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
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
11 matches
Mail list logo
