Re: [Dwarf-Discuss] Segment selectors for the range list table.
> -Original Message- > From: Dwarf-Discuss On Behalf > Of Xing GUO via Dwarf-Discuss > Sent: Tuesday, July 14, 2020 10:39 PM > To: 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 > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf- > discuss-dwarfstd.org__;!!JmoZiZGBv3RvKRSx!v6qFHG- > c16QgrlK07KDC5v6Q8edq8S8mb3_4iif7SZxPna-t0k5tZRaMoXPgqvftiQ$ ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Segment selectors for the range list table.
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> wrote:
>
>
> > -Original Message-
> > From: Dwarf-Discuss On Behalf
> > Of Xing GUO via Dwarf-Discuss
> > Sent: Tuesday, July 14, 2020 10:39 PM
> > To: 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
> > ___
> > Dwarf-Discuss mailing list
> > Dwarf-Discuss@lists.dwarfstd.org
> >
> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
> > discuss-dwarfstd.org__;!!JmoZiZGBv3RvKRSx!v6qFHG-
> > c16QgrlK07KDC5v6Q8edq8S8mb3_4iif7SZxPna-t0k5tZRaMoXPgqvftiQ$
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] Segment selectors for the range list table.
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
> wrote:
> -Original Message-
> From: Dwarf-Discuss 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
> 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_siz
Re: [Dwarf-Discuss] Segment selectors for the range list table.
Hi David,
On 7/16/20, David Blaikie 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.")
Thanks for your explanation.
So, If we want to use segmented addresses in the debug_rnglist or
debug_loclist table, we should use encodings like: startx_endx,
startx_length, etc., to index the {segment/address} pairs in the
address table of the .debug_addr section rather than the direct
address forms like: start_end, start_length, etc., right?
Besides, the segment_selector_size is just an indicator that tells us
if the current debug_rnglist/debug_loclist table is using segmented
address and it should have no effects on parsing the encoding and
operands (e.g., {DW_RLE_startx_endx, operands0, operands1},
{DW_RLE_start_end, operands0, operands1}) in the entries.
> 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> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Dwarf-Discuss On
>> > Behalf
>> > Of Xing GUO via Dwarf-Discuss
>> > Sent: Tuesday, July 14, 2020 10:39 PM
>> > To: 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
>> > ___
>> > Dwarf-Discuss mailing list
>> > Dwarf-Discuss@lists.dwarfstd.org
>> >
>> https://urldefense.com/v3/__http://lists.dwarfstd.org/listinfo.cgi/dwarf-
>> > discuss-dwarfstd.org__;
Re: [Dwarf-Discuss] Segment selectors for the range list table.
On Wed, Jul 15, 2020 at 7:07 PM Michael Eager via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:
> 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.
That seems at odds with the non-normative text of 2.12 "In some systems,
addresses are specified as offsets within a given segment rather than as
locations within a single flat address space."
And also would be confusing to me - if there is a contiguous linear address
space, why would DWARF need to specify the use of a segment selector, and
why do some references to addresses allow the inclusion of a segment
selector and some don't? Why not just always use the non-segmented address
description for DWARF?
& I don't find any mention of this idea that some addresses are absolute
and some are segment-relative in 2.12 - it does say that "If none of the
entries in the chain of parents for this entry back to its containing
compilation unit entry have DW_AT_segment attributes, then the entry is
assumed to exist within a flat address space." - as though a flat (I assume
this is synonymous with "linear"?) address space is distinct from the
segmented address space being discussed otherwise?
> 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.
>
Sorry, I don't quite follow the connections between all those statements.
2.17 says that if a DIE has a DW_AT_high_pc and DW_AT_segment, then the
high_pc is relative to the specified segment. That's a bit redundant if
high_pc uses FORM_addrx, because the address in the address pool can
specify its own segment, but a producer could choose which way to go there.
(presumably if the AT_segment is there, you should interpret the addrx
high_pc relative to that segment - assuming debug_addr has no segment
selector in it - or perhaps it should go the other way and ignore the local
AT_segment and only rely on whatever segment is in debug_addr)
>
> 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 addre
Re: [Dwarf-Discuss] Segment selectors for the range list table.
On Wed, Jul 15, 2020 at 8:00 PM Xing GUO wrote:
> Hi David,
>
> On 7/16/20, David Blaikie 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.")
>
> Thanks for your explanation.
>
Note: there seems to be some disagreement with my understanding - and I
haven't been around these parts nearly as long as some other folk - so
there's a fair chance I'm wrong/misunderstanding/misreading things.
> So, If we want to use segmented addresses in the debug_rnglist or
> debug_loclist table, we should use encodings like: startx_endx,
> startx_length, etc., to index the {segment/address} pairs in the
> address table of the .debug_addr section rather than the direct
> address forms like: start_end, start_length, etc., right?
>
That's /my/ understanding. (side note: imho: it's good to use the addrx
forms anyway - since you can reduce relocations (& thus object size) that
way - try some experiments with Clang's DWARFv5 support to see how I
implemented it there/how I think it should be done (admittedly I have a
bias towards reducing object size especially, since that's a particular
issue for my customers))
> Besides, the segment_selector_size is just an indicator that tells us
> if the current debug_rnglist/debug_loclist table is using segmented
> address and it should have no effects on parsing the encoding and
> operands (e.g., {DW_RLE_startx_endx, operands0, operands1},
> {DW_RLE_start_end, operands0, operands1}) in the entries.
>
None that I can see - which seems suspicious to me. (similarly in
debug_line - there's a segment_selector_size in the header, but no use that
I know of in the actual parsing of the implementation... )
>
> > 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> wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Dwarf-Discuss On
> >> > Behalf
> >> > Of Xing GUO via Dwarf-Discuss
> >> > Sent: Tuesday, July 14, 2020 10:39 PM
> >> > To: 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
