[Dwarf-Discuss] DW_AT_segment and relocation

[Jayvee Neumann]

Thank you Ron and thank you Michael,

this explanation helps me a lot.
I think I do not have to support 286 and 386 in 16bit mode. So, this
simplifies things a lot.

Kind regards
Jayvee

Am Sa., 28. Sept. 2019 um 00:04 Uhr schrieb Michael Eager <eager at eagerm.com
>:

> On 9/27/19 1:29 AM, Jayvee Neumann wrote:
> > Thank you Michael and Ron,
> >
> > what I am trying to do is write a consumer that is able to handle images
> > from several targets: i386, AMD64, and also ARM. The target images will
> > be loaded and running (and debugged during run-time).
> > I want to find a way to handle addresses in a simple way, abstracting
> > from the underlying architecture. So my first Idea was giving each
> > address a segment that can either be zero or an expression.
> >
> > That lead to the problem I mentioned in the first email. I think this is
> > best explained with an example. If the image (e.g. a DLL or a shared
> > library) has a preferred loading address of 0x1000, this address is used
> > in DWARF. But the image could be loaded at e.g. 0x2000 (or any other
> > address). The consumer has to adjust all the pc values in DWARF in that
> > case. A function whose DWARF information say is loaded from e.g. 0x10E8
> > to 0x1120 is actually loaded from 0x20E8 to 0x2120. An attribute
> > DW_AT_low_pc with the value 0x1500 would represent the address 0x2500
> > when the image is actually loaded. But an address like Segment:Offset
> > (e.g. CS:0x0123) would be valid during run-time without any adjustment,
> > since the segment is computed from registers during run-time and thus
> > necessarily adjusted to the load-time addresses and not build-time
> > addresses. So the rule of thumb would be: Do not adjust segmented
> > addresses in the consumer. Or have I misunderstood something about this
> > matter?
>
> When it reads the debug info, a debugger has to go through the same
> relocation process as happens when the executable or library is loaded.
> Every relocatable reference needs to be adjusted to account for the
> situation you describe, where the code is loaded at a different offset.
>
> DW_AT_segment really cannot be used to do this.  There is (in general)
> no register or other expression which will perform this relocation for
> you, since the computation depends on information (e. g., the load
> addresses for each piece of the executable) which may not be accessible
> to the program.
>
> Unless you are planning to support 286 or 386 in 16-bit mode in one of
> the segmented memory schemes used on these processors, you do not need
> support for DW_AT_segment.
>
> > What is kind of counter intuitive is the fact that the DWARF5 standard
> > says: if DW_AT_segment is specified at any parent DIE it is valid at its
> > subsequent child DIEs. Consumer libraries like libdwarf have no function
> > that allows for determining the parent DIE if only the child DIE is
> > known. It would be necessary to go through all DIEs and check which one
> > is an ancestor of the DIE in question. So this little sentence implies a
> > lot of difficulties for a consumer.
>
> I haven't looked at how debuggers like GDB handle segments in a very
> long time.  I believe that when the DWARF info is read and used to
> create an internal representation, a current segment value is maintained
> as the debug info is parsed recursively.  This is set as you descend the
> parse tree, pushing previous values, and popped when ascend the tree.
>
> Almost all architectures, and specifically the ARM and AMD64
> architectures you mention, use linear, not segmented, address spaces.
>
> >
> > Kind regards,
> > Jayvee
> >
> > Am Do., 26. Sept. 2019 um 23:12 Uhr schrieb Michael Eager
> > <eager at eagerm.com <mailto:eager at eagerm.com>>:
> >
> >     On 9/26/19 3:33 AM, Jayvee Neumann via Dwarf-Discuss wrote:
> >      > Dear DWARF experts,
> >      >
> >      > I have a question regarding the attribute DW_AT_segment. I do not
> >     quite
> >      > understand how to handle it, yet.
> >      > It can appear in a DIE (or its parent) whenever DW_AT_low_pc,
> >      > DW_AT_high_pc, DW_AT_ranges, DW_AT_entry_pc, or a location
> >     description
> >      > that evaluates to an Address are used.
> >      > It can contain a location expression itself. So it can depend not
> >     only
> >      > on compile-time information but also on run-time information.
> >      >
> >      > Assume, I have an attribute DW_AT_low_pc. If there is no
> >     DW_AT_segment,
> >      > this attribute is simply the low_pc as it was determined during
> >      > compile-time. While debugging, this value has to be relocated if
> the
> >      > image had been relocated. If there is a DW_AT_segment expression
> is
> >      > relocation still necessary? Evaluating the expression could also
> >      > incorporate the usage of run-time information and relocated
> >     addresses
> >      > (i.e. the DS/CS/SS registers).
> >      >
> >      > I hope I was able to articulate my question well, English is not
> my
> >      > native language.
> >      >
> >      > Kind Regards
> >      > Jayvee
> >
> >     Your question is quite clear, but we don't know the context.  What
> >     architecture are you working with and what ar you trying to do?
> >
> >     As Ron mentioned, AT_segment is intended to support architectures
> like
> >     the X86 where an address is composed of a [segment,offset] pair.
> Most
> >     architectures do not use segments.
> >
> >     --
> >     Michael Eager eager at eagerm.com <mailto:eager at eagerm.com>
> >     1960 Park Blvd., Palo Alto, CA 94306
> >
>
> --
> Michael Eager    eager at eagerm.com
> 1960 Park Blvd., Palo Alto, CA 94306
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20190930/aa9ccd10/attachment.html>