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