[Dwarf-Discuss] Notification

Sat Sep 28 20:37:13 GMT 2019

Your email to the Global IT Service Desk has been received - if this is an issue requiring URGENT assistance, please CALL us using your in-country phone number. We will respond to your e-mail during our regular hours of operation between 7:00 AM to 6:00 PM local time. We provide limited support outside of the local business hours. 

You can also obtain support through our Service Desk Portal on the web at help.wsp.com 

Thank you

--

Votre courriel achemin? au Centre d?assistance TI global a bien ?t? re?u- si ce probl?me requiert une assistance IMM?DIATE SVP nous contacter par t?l?phone en utilisant votre num?ro local. Nous r?pondrons ? votre courriel durant les heures ouvrables soit entre 7 heures et 18 heures (heure locale). Le soutien technique en dehors des heures ouvrables est limit?.

Vous pouvez aussi obtenir de l?aide en visitant le portail de WSP au help.wsp.com

Merci 

----- Original Message -----
From: dwarf-discuss-request@lists.dwarfstd.org
To: dwarf-discuss at lists.dwarfstd.org
Sent: Saturday, September 28, 2019 1:35:22 PM GMT-07:00
Subject: Dwarf-Discuss Digest, Vol 119, Issue 5

>Send Dwarf-Discuss mailing list submissions to
>	dwarf-discuss at lists.dwarfstd.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>or, via email, send a message with subject or body 'help' to
>	dwarf-discuss-request at lists.dwarfstd.org
>
>You can reach the person managing the list at
>	dwarf-discuss-owner at lists.dwarfstd.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Dwarf-Discuss digest..."
>
>
>Today's Topics:
>
>   1. Notification (servicedesk at help.wsp.com)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sat, 28 Sep 2019 00:07:01 +0200
>From: <servicedesk at help.wsp.com>
>To: <dwarf-discuss at lists.dwarfstd.org>
>Subject: [Dwarf-Discuss] Notification
>Message-ID: <000M0aER1R6CQT1C at atos-services.net>
>Content-Type: text/plain; charset="utf-8"
>
>
>Your email to the Global IT Service Desk has been received - if this is an issue requiring URGENT assistance, please CALL us using your in-country phone number. We will respond to your e-mail during our regular hours of operation between 7:00 AM to 6:00 PM local time. We provide limited support outside of the local business hours. 
>
>You can also obtain support through our Service Desk Portal on the web at help.wsp.com 
>
>Thank you
>
>--
>
>Votre courriel achemin? au Centre d?assistance TI global a bien ?t? re?u- si ce probl?me requiert une assistance IMM?DIATE SVP nous contacter par t?l?phone en utilisant votre num?ro local. Nous r?pondrons ? votre courriel durant les heures ouvrables soit entre 7 heures et 18 heures (heure locale). Le soutien technique en dehors des heures ouvrables est limit?.
>
>Vous pouvez aussi obtenir de l?aide en visitant le portail de WSP au help.wsp.com
>
>Merci 
>
>----- Original Message -----
>From: dwarf-discuss-request at lists.dwarfstd.org
>To: dwarf-discuss at lists.dwarfstd.org
>Sent: Friday, September 27, 2019 3:04:29 PM GMT-07:00
>Subject: Dwarf-Discuss Digest, Vol 119, Issue 4
>
>>Send Dwarf-Discuss mailing list submissions to
>>	dwarf-discuss at lists.dwarfstd.org
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>>	http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>or, via email, send a message with subject or body 'help' to
>>	dwarf-discuss-request at lists.dwarfstd.org
>>
>>You can reach the person managing the list at
>>	dwarf-discuss-owner at lists.dwarfstd.org
>>
>>When replying, please edit your Subject line so it is more specific
>>than "Re: Contents of Dwarf-Discuss digest..."
>>
>>
>>Today's Topics:
>>
>>   1. Notification (servicedesk at help.wsp.com)
>>   2. Re: DW_AT_segment and relocation (Ron Brender)
>>   3. Re: DW_AT_segment and relocation (Michael Eager)
>>
>>
>>----------------------------------------------------------------------
>>
>>Message: 1
>>Date: Fri, 27 Sep 2019 22:40:57 +0200
>>From: <servicedesk at help.wsp.com>
>>To: <dwarf-discuss at lists.dwarfstd.org>
>>Subject: [Dwarf-Discuss] Notification
>>Message-ID: <000M0aER1R6CQP8Q at atos-services.net>
>>Content-Type: text/plain; charset="utf-8"
>>
>>
>>Your email to the Global IT Service Desk has been received - if this is an issue requiring URGENT assistance, please CALL us using your in-country phone number. We will respond to your e-mail during our regular hours of operation between 7:00 AM to 6:00 PM local time. We provide limited support outside of the local business hours. 
>>
>>You can also obtain support through our Service Desk Portal on the web at help.wsp.com 
>>
>>Thank you
>>
>>--
>>
>>Votre courriel achemin? au Centre d?assistance TI global a bien ?t? re?u- si ce probl?me requiert une assistance IMM?DIATE SVP nous contacter par t?l?phone en utilisant votre num?ro local. Nous r?pondrons ? votre courriel durant les heures ouvrables soit entre 7 heures et 18 heures (heure locale). Le soutien technique en dehors des heures ouvrables est limit?.
>>
>>Vous pouvez aussi obtenir de l?aide en visitant le portail de WSP au help.wsp.com
>>
>>Merci 
>>
>>----- Original Message -----
>>From: dwarf-discuss-request at lists.dwarfstd.org
>>To: dwarf-discuss at lists.dwarfstd.org
>>Sent: Friday, September 27, 2019 1:40:13 PM GMT-07:00
>>Subject: Dwarf-Discuss Digest, Vol 119, Issue 3
>>
>>>Send Dwarf-Discuss mailing list submissions to
>>>	dwarf-discuss at lists.dwarfstd.org
>>>
>>>To subscribe or unsubscribe via the World Wide Web, visit
>>>	http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>>or, via email, send a message with subject or body 'help' to
>>>	dwarf-discuss-request at lists.dwarfstd.org
>>>
>>>You can reach the person managing the list at
>>>	dwarf-discuss-owner at lists.dwarfstd.org
>>>
>>>When replying, please edit your Subject line so it is more specific
>>>than "Re: Contents of Dwarf-Discuss digest..."
>>>
>>>
>>>Today's Topics:
>>>
>>>   1. Notification (servicedesk at help.wsp.com)
>>>
>>>
>>>----------------------------------------------------------------------
>>>
>>>Message: 1
>>>Date: Fri, 27 Sep 2019 22:33:57 +0200
>>>From: <servicedesk at help.wsp.com>
>>>To: <dwarf-discuss at lists.dwarfstd.org>
>>>Subject: [Dwarf-Discuss] Notification
>>>Message-ID: <000M0aER1R6CQNSQ at atos-services.net>
>>>Content-Type: text/plain; charset="utf-8"
>>>
>>>
>>>Your email to the Global IT Service Desk has been received - if this is an issue requiring URGENT assistance, please CALL us using your in-country phone number. We will respond to your e-mail during our regular hours of operation between 7:00 AM to 6:00 PM local time. We provide limited support outside of the local business hours. 
>>>
>>>You can also obtain support through our Service Desk Portal on the web at help.wsp.com 
>>>
>>>Thank you
>>>
>>>--
>>>
>>>Votre courriel achemin? au Centre d?assistance TI global a bien ?t? re?u- si ce probl?me requiert une assistance IMM?DIATE SVP nous contacter par t?l?phone en utilisant votre num?ro local. Nous r?pondrons ? votre courriel durant les heures ouvrables soit entre 7 heures et 18 heures (heure locale). Le soutien technique en dehors des heures ouvrables est limit?.
>>>
>>>Vous pouvez aussi obtenir de l?aide en visitant le portail de WSP au help.wsp.com
>>>
>>>Merci 
>>>
>>>----- Original Message -----
>>>From: dwarf-discuss-request at lists.dwarfstd.org
>>>To: dwarf-discuss at lists.dwarfstd.org
>>>Sent: Friday, September 27, 2019 1:32:55 PM GMT-07:00
>>>Subject: Dwarf-Discuss Digest, Vol 119, Issue 2
>>>
>>>>Send Dwarf-Discuss mailing list submissions to
>>>>        dwarf-discuss at lists.dwarfstd.org
>>>>
>>>>To subscribe or unsubscribe via the World Wide Web, visit
>>>>        http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>>>or, via email, send a message with subject or body 'help' to
>>>>        dwarf-discuss-request at lists.dwarfstd.org
>>>>
>>>>You can reach the person managing the list at
>>>>        dwarf-discuss-owner at lists.dwarfstd.org
>>>>
>>>>When replying, please edit your Subject line so it is more specific
>>>>than "Re: Contents of Dwarf-Discuss digest..."
>>>>
>>>>
>>>>Today's Topics:
>>>>
>>>>   1. Re: DW_AT_segment and relocation (Michael Eager)
>>>>   2. Re: DW_AT_segment and relocation (Jayvee Neumann)
>>>>
>>>>
>>>>----------------------------------------------------------------------
>>>>
>>>>Message: 1
>>>>Date: Thu, 26 Sep 2019 14:11:52 -0700
>>>>From: Michael Eager <eager at eagerm.com>
>>>>To: Jayvee Neumann <jayvee.neumann at gmail.com>,
>>>>        dwarf-discuss at lists.dwarfstd.org
>>>>Subject: Re: [Dwarf-Discuss] DW_AT_segment and relocation
>>>>Message-ID: <0d19af28-3aa4-f199-3487-6578e339650a at eagerm.com>
>>>>Content-Type: text/plain; charset=utf-8; format=flowed
>>>>
>>>>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
>>>>1960 Park Blvd., Palo Alto, CA 94306
>>>>
>>>>
>>>>------------------------------
>>>>
>>>>Message: 2
>>>>Date: Fri, 27 Sep 2019 10:29:03 +0200
>>>>From: Jayvee Neumann <jayvee.neumann at gmail.com>
>>>>To: Michael Eager <eager at eagerm.com>, dwarf-discuss at lists.dwarfstd.org
>>>>Subject: Re: [Dwarf-Discuss] DW_AT_segment and relocation
>>>>Message-ID:
>>>>        <CALak_8ZmkjiEzA7X4+PK_Pzf+dSor5dgnnV7mG23Wk=32uMhzw at mail.gmail.com>
>>>>Content-Type: text/plain; charset="utf-8"
>>>>
>>>>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?
>>>>
>>>>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.
>>>>
>>>>Kind regards,
>>>>Jayvee
>>>>
>>>>Am Do., 26. Sept. 2019 um 23:12 Uhr schrieb Michael Eager <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
>>>>> 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/20190927/9c050397/attachment-0001.html>
>>>>
>>>>------------------------------
>>>>
>>>>Subject: Digest Footer
>>>>
>>>>_______________________________________________
>>>>Dwarf-Discuss mailing list
>>>>Dwarf-Discuss at lists.dwarfstd.org
>>>>http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>>>
>>>>
>>>>------------------------------
>>>>
>>>>End of Dwarf-Discuss Digest, Vol 119, Issue 2
>>>>*********************************************
>>>>
>>>>________________________________
>>>>
>>>>
>>>>NOTICE: This communication and any attachments ("this message") may contain information which is privileged, confidential, proprietary or otherwise subject to restricted disclosure under applicable law. This message is for the sole use of the intended recipient(s). Any unauthorized use, disclosure, viewing, copying, alteration, dissemination or distribution of, or reliance on, this message is strictly prohibited. If you have received this message in error, or you are not an authorized or intended recipient, please notify the sender immediately by replying to this message, delete this message and all copies from your e-mail system and destroy any printed copies.
>>>>
>>>>
>>>>
>>>>-LAEmHhHzdJzBlTWfa4Hgs7pbKl
>>>
>>>
>>>
>>>------------------------------
>>>
>>>Subject: Digest Footer
>>>
>>>_______________________________________________
>>>Dwarf-Discuss mailing list
>>>Dwarf-Discuss at lists.dwarfstd.org
>>>http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>>
>>>
>>>------------------------------
>>>
>>>End of Dwarf-Discuss Digest, Vol 119, Issue 3
>>>*********************************************
>>
>>
>>
>>------------------------------
>>
>>Message: 2
>>Date: Fri, 27 Sep 2019 17:12:19 -0400
>>From: Ron Brender <ron.brender at gmail.com>
>>To: Jayvee Neumann <jayvee.neumann at gmail.com>
>>Cc: Michael Eager <eager at eagerm.com>, DWARF-Discuss
>>	<dwarf-discuss at lists.dwarfstd.org>
>>Subject: Re: [Dwarf-Discuss] DW_AT_segment and relocation
>>Message-ID:
>>	<CANSbVTiGt-Gc6Wty2cuKAn1utTh2pHDc_txACf1KPzQac0=z=w at mail.gmail.com>
>>Content-Type: text/plain; charset="utf-8"
>>
>>Jayvee,
>>
>>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!
>>
>>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.
>>
>>Ron
>>
>>
>>
>>On Fri, Sep 27, 2019 at 4:29 AM Jayvee Neumann via Dwarf-Discuss <
>>dwarf-discuss at lists.dwarfstd.org> 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?
>>>
>>> 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.
>>>
>>> Kind regards,
>>> Jayvee
>>>
>>> Am Do., 26. Sept. 2019 um 23:12 Uhr schrieb Michael Eager <
>>> 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
>>>> 1960 Park Blvd., Palo Alto, CA 94306
>>>>
>>> _______________________________________________
>>> Dwarf-Discuss mailing list
>>> Dwarf-Discuss at lists.dwarfstd.org
>>> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>>
>>-------------- next part --------------
>>An HTML attachment was scrubbed...
>>URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20190927/3645523b/attachment-0001.html>
>>
>>------------------------------
>>
>>Message: 3
>>Date: Fri, 27 Sep 2019 15:04:19 -0700
>>From: Michael Eager <eager at eagerm.com>
>>To: Jayvee Neumann <jayvee.neumann at gmail.com>,
>>	dwarf-discuss at lists.dwarfstd.org
>>Subject: Re: [Dwarf-Discuss] DW_AT_segment and relocation
>>Message-ID: <7db5bc15-53e1-1fcb-7eb1-018c488a346f at eagerm.com>
>>Content-Type: text/plain; charset=utf-8; format=flowed
>>
>>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
>>
>>
>>------------------------------
>>
>>Subject: Digest Footer
>>
>>_______________________________________________
>>Dwarf-Discuss mailing list
>>Dwarf-Discuss at lists.dwarfstd.org
>>http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>
>>
>>------------------------------
>>
>>End of Dwarf-Discuss Digest, Vol 119, Issue 4
>>*********************************************
>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Dwarf-Discuss mailing list
>Dwarf-Discuss at lists.dwarfstd.org
>http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
>------------------------------
>
>End of Dwarf-Discuss Digest, Vol 119, Issue 5
>*********************************************