Perhaps it's more like Paul was postulating - that the spec assumes code
is in a code segment/doesn't need to be clarified. (but that gets a bit
confused in debug_aranges - if it only is meant to contain code (not
data), why does it need a segment selector - and also in the DIEs - if
code is always in a known/assumable segment then why can you vary
segment for low_pc/high_pc/ranges?)
No, the spec says what it says. There are no restriction on where code
or data are located.
AFAIK, all addresses can be segmented addresses, except in the line
table where it isn't needed.
Perhaps we should have (long ago) required flat/linear addresses for
x86
instead of segmented addresses.
What's the line table's segment_selector_size (in the DWARFv5 header)
for? (this sort of agrees and disagrees with you - it's there, but it's
not used in any part of the debug_line format that I can see)
It may be there for consistency across all headers.
debug_addr supports segment selectors - in the debug_addr header it has
a field for "segment selector size" and the entries in the address list
are "segment/address pairs.".
So now there's two ways a segment selector for an address could be
specified - if you had a DW_TAG_subprogram with a DW_AT_low_pc using
addrx into a debug_addr with a non-zero segment selector and the
subprogram also had a DW_AT_segment, wonder which one's meant to win.
Again, FORM_addrx doesn't mean the same as DW_AT_segment.
They are orthogonal concepts. Compression techniques, like FORM_addrx,
should not be used to describe architectural features.
--
Michael Eager
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
