Segmented addresses have been in the DWARF specification since Version 2
and AFAIK have not been changed since that time. DWARF V5 did not add
any functionality to segmented addresses that was not present in DWARF
V2/3. At least, there was no intention to do so. Segmented addresses
are described in Section 2.12.
A segmented address maps into a linear address in a processor-specific
fashion. AFAIK, only the Intel 8086 and descendants have this
functionality. (It's a many to one mapping in the 8086 implementation,
but that's a problem for a bygone era.) There's a reference to i386
memory models in Table 2.7.
DWARF assumes a linear address space. A segmented address maps to a
specific address in this linear address space. The entries in
DW_AT_ranges for subprograms with different segment addresses would
usually be referenced by their address in the linear address space. If
DW_AT_ranges has a DW_AT_segment, this is an indication that the
debugger is to perform the processor-specific computation to translate
the segment-address pair to the linear address.
There is no need to do anything with segments in the line table, since
the line table contains addresses in the linear address space.
There is some (perhaps considerable) confusion in terminology in the x86
world, because the x86 has multiple segment registers which on other
processors would be called base registers. The values in these
registers reference memory segments and are added to whatever offset is
contained in the program to generate an address. These segment
registers, and the memory segments which they point to, are NOT the
segments represented by DW_AT_segment.
Re "reading the segment selector" and "addrx encoding": The addresses
in DWARF DIEs are static, not dynamic. There is no register+offset
encoding, and processor registers are not read to determine where a
subprogram is in memory.
On 7/15/20 4:31 PM, David Blaikie via Dwarf-Discuss wrote:
Looking at how segment selectors work:
DW_AT_segment: Applies to a DIE subtree, including any ranges, high/low
pc, locations, labels, etc
debug_range/loc (v4 and below): Doesn't seem to allow specifying segment
variation - inherits from the segment given on the nearest parent DIE
that refers to the entry
debug_rnglist/loclist (v5): includes segment selector size in the
header, but doesn't seem to use it - segment selection via addresses in
the address pool (RLE/LLE_*x encodings) would allow fine-grained segment
selection, but direct address forms don't seem to allow segment
selection ("This operand is the
19 same size as used in DW_FORM_addr.")
debug_addr: segment_size in header, then list of {segment selector, address}
debug_aranges: segment_size in header says, then the list contains
triples of {segment selector, start address, length}
debug_line: v5 encodes the address and segment selector size in the
header, but I'm not sure if/how it's used. The DW_LNE_set_address
operation says:
"The DW_LNE_set_address opcode takes a single relocatable address as an
operand. The size of the operand is the size of an address on the target
machine. It sets the address register to the value given by the
relocatable address and sets the op_index register to 0." - doesn't
sound like it's reading the segment selector there.
So... I don't think DWARFv5 made anything worse - if anything it did
enable /a/ way to use fine grained segment selectors in range lists and
location lists that doesn't appear, to me, to have been provided before.
(it could be needed if you had some functions in some segment and some
functions in another segment (which could be represented at the
subprogram DIE level - DW_AT_segment 1 on one DW_TAG_subprogram,
DW_AT_segment 2 on another DW_TAG_subprogram - but how would you
represent the DW_AT_ranges for this CU (in DWARFv4, or in DWARFv5
without using addrx encodings)? I don't know how, because I think
debug_ranges could describe one range list entry as being from one
segment, and another range list entry as being in another segment - they
would all be in whatever segment was in DW_AT_segment on the CU)
does that make sense? Have I missed something about how you could use
segment selectors in a debug_loc, debug_ranges, or loclist/rnglist that
isn't using an addrx encoding?
On Wed, Jul 15, 2020 at 6:37 AM Robinson, Paul via Dwarf-Discuss
<dwarf-discuss@lists.dwarfstd.org
<mailto:dwarf-discuss@lists.dwarfstd.org>> wrote:
> -----Original Message-----
> From: Dwarf-Discuss <dwarf-discuss-boun...@lists.dwarfstd.org
<mailto:dwarf-discuss-boun...@lists.dwarfstd.org>> On Behalf
> Of Xing GUO via Dwarf-Discuss
> Sent: Tuesday, July 14, 2020 10:39 PM
> To: dwarf-discuss@lists.dwarfstd.org
<mailto:dwarf-discuss@lists.dwarfstd.org>
> Subject: [Dwarf-Discuss] Segment selectors for the range list table.
>
> Hi there,
>
> The DWARFv5 spec mentioned that there might be segment selectors in
> the range list entries and when the segment_selector_size is 0, the
> segment selectors are omitted from the range list entries.
However, it
> didn't mention how the segment selector should be encoded when the
> segment_selector_size isn't 0. Can anyone help me figure it out?
> Thanks a lot!
Hi Xing,
The segment selectors in the range list would be encoded the same way
as they would be in the main .debug_info section. Range lists and
location lists are essentially extensions to .debug_info, for cases
where the range or location cannot be represented by simple DW_AT_*
attribute values.
The specifics of encoding the segment selector would be whatever is
appropriate to the target. DWARF does not specify these details.
Best Regards,
--paulr
>
> 7.28 (page 243)
> The segment size is given by the segment_selector_size field of the
> header, and the address size is given by the address_size field
of the
> header. If the segment_selector_size field in the header is zero, the
> segment selector is omitted from the range list entries.
>
> --
> Cheers,
> Xing
--
Michael Eager
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
