<div dir="ltr"><div>Jayvee,</div><div><br></div><div>If you are dealing with a linear 32- or 64-bit address space then there are no segments to worry about, so the question is moot. If you are dealing with a segmented address space, then the problems you describe are exactly those that debuggers on segmented machine dealt with all the time. Guess why linear address space "won" as the most common, preferred addressing method!</div><div><br></div><div>As for the scoping problem, you are quite right. My impression is most DWARF debuggers (the most common kind of consumer) do some kind of simple initial pass over the DWARF info during startup to build some kind of auxiliary data structure of its own to help speed dealing with such issues.</div><div><br></div><div>Ron<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 4:29 AM Jayvee Neumann via Dwarf-Discuss <<a href="mailto:dwarf-discuss@lists.dwarfstd.org">dwarf-discuss@lists.dwarfstd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail_default" style="font-family:monospace,monospace">Thank you Michael and Ron,<br><br>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).<br>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.<br><br>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?<br><br>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.<br><br>Kind regards,<br>Jayvee</span><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 26. Sept. 2019 um 23:12 Uhr schrieb Michael Eager <<a href="mailto:eager@eagerm.com" target="_blank">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/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 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 description <br>
> that evaluates to an Address are used.<br>
> It can contain a location expression itself. So it can depend not 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 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 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><br>
1960 Park Blvd., Palo Alto, CA 94306<br>
</blockquote></div></div>
_______________________________________________<br>
Dwarf-Discuss mailing list<br>
<a href="mailto:Dwarf-Discuss@lists.dwarfstd.org" target="_blank">Dwarf-Discuss@lists.dwarfstd.org</a><br>
<a href="http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org" rel="noreferrer" target="_blank">http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org</a><br>
</blockquote></div>