From robert.m.harris@oracle.com  Mon Sep 24 14:15:40 2018
From: robert.m.harris@oracle.com (Robert Harris)
Date: Mon, 24 Sep 2018 15:15:40 +0100
Subject: [Dwarf-Discuss] .debug_frame and the base address
Message-ID: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>

I'd like some clarification regarding what precisely needs to be relocated relative to
the object load address when interpreting .debug_frame.  I'm interested in versions
2, 3 and 4.

I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:

	Abstractly, this mechanism describes a very large table...
	...
	The first column indicates an address for every location that contains
	code in a program. (In shared objects, this is an object-relative offset.)

Thus adjustments need to be made to only

	An FDE's initial_location field
	DW_CFA_set_loc's operand

Have I missed anything?  I see some ambiguity in the definition of
DW_CFA_def_cfa_expression and it's making me wonder if there are any
other occasions when a result would require relocation.

Robert Harris
	


From clayborg@gmail.com  Mon Sep 24 14:33:11 2018
From: clayborg@gmail.com (Greg Clayton)
Date: Mon, 24 Sep 2018 07:33:11 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
Message-ID: <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>



> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
> 
> I'd like some clarification regarding what precisely needs to be relocated relative to
> the object load address when interpreting .debug_frame.  I'm interested in versions
> 2, 3 and 4.
> 
> I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:
> 
> 	Abstractly, this mechanism describes a very large table...
> 	...
> 	The first column indicates an address for every location that contains
> 	code in a program. (In shared objects, this is an object-relative offset.)
> 
> Thus adjustments need to be made to only
> 
> 	An FDE's initial_location field
> 	DW_CFA_set_loc's operand
> 
> Have I missed anything?  I see some ambiguity in the definition of
> DW_CFA_def_cfa_expression and it's making me wonder if there are any
> other occasions when a result would require relocation.

Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated. 

> 
> Robert Harris
> 	
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org



From robert.m.harris@oracle.com  Mon Sep 24 15:44:28 2018
From: robert.m.harris@oracle.com (Robert Harris)
Date: Mon, 24 Sep 2018 16:44:28 +0100
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
Message-ID: <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>



> On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
> 
>> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
>> 
>> I'd like some clarification regarding what precisely needs to be relocated relative to
>> the object load address when interpreting .debug_frame.  I'm interested in versions
>> 2, 3 and 4.
>> 
>> I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:
>> 
>> 	Abstractly, this mechanism describes a very large table...
>> 	...
>> 	The first column indicates an address for every location that contains
>> 	code in a program. (In shared objects, this is an object-relative offset.)
>> 
>> Thus adjustments need to be made to only
>> 
>> 	An FDE's initial_location field
>> 	DW_CFA_set_loc's operand
>> 
>> Have I missed anything?  I see some ambiguity in the definition of
>> DW_CFA_def_cfa_expression and it's making me wonder if there are any
>> other occasions when a result would require relocation.
> 
> Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated.

Do you mean that DW_OP_addr's argument should be relocated in all instances
of a DWARF expression, i.e. in other .debug_ sections, or just in the context of
.debug_frame?



From clayborg@gmail.com  Mon Sep 24 15:59:57 2018
From: clayborg@gmail.com (Greg Clayton)
Date: Mon, 24 Sep 2018 08:59:57 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
Message-ID: <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>



> On Sep 24, 2018, at 8:44 AM, Robert Harris <robert.m.harris at oracle.com> wrote:
> 
> 
> 
>> On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
>>> 
>>> I'd like some clarification regarding what precisely needs to be relocated relative to
>>> the object load address when interpreting .debug_frame.  I'm interested in versions
>>> 2, 3 and 4.
>>> 
>>> I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:
>>> 
>>> 	Abstractly, this mechanism describes a very large table...
>>> 	...
>>> 	The first column indicates an address for every location that contains
>>> 	code in a program. (In shared objects, this is an object-relative offset.)
>>> 
>>> Thus adjustments need to be made to only
>>> 
>>> 	An FDE's initial_location field
>>> 	DW_CFA_set_loc's operand
>>> 
>>> Have I missed anything?  I see some ambiguity in the definition of
>>> DW_CFA_def_cfa_expression and it's making me wonder if there are any
>>> other occasions when a result would require relocation.
>> 
>> Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated.
> 
> Do you mean that DW_OP_addr's argument should be relocated in all instances
> of a DWARF expression, i.e. in other .debug_ sections, or just in the context of
> .debug_frame?

I was specifically talking about DWARF expressions in any .debug_frame info. But in general, yes, any DWARF expression that contains a DW_OP_addr might need a relocation for its address argument.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180924/2cbb8b4b/attachment.html>


From robert.m.harris@oracle.com  Mon Sep 24 16:19:04 2018
From: robert.m.harris@oracle.com (Robert Harris)
Date: Mon, 24 Sep 2018 17:19:04 +0100
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
Message-ID: <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>



> On 24 Sep 2018, at 16:59, Greg Clayton <clayborg at gmail.com> wrote:
> 
> 
> 
>> On Sep 24, 2018, at 8:44 AM, Robert Harris <robert.m.harris at oracle.com> wrote:
>> 
>> 
>> 
>>> On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
>>>> 
>>>> I'd like some clarification regarding what precisely needs to be relocated relative to
>>>> the object load address when interpreting .debug_frame.  I'm interested in versions
>>>> 2, 3 and 4.
>>>> 
>>>> I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:
>>>> 
>>>> 	Abstractly, this mechanism describes a very large table...
>>>> 	...
>>>> 	The first column indicates an address for every location that contains
>>>> 	code in a program. (In shared objects, this is an object-relative offset.)
>>>> 
>>>> Thus adjustments need to be made to only
>>>> 
>>>> 	An FDE's initial_location field
>>>> 	DW_CFA_set_loc's operand
>>>> 
>>>> Have I missed anything?  I see some ambiguity in the definition of
>>>> DW_CFA_def_cfa_expression and it's making me wonder if there are any
>>>> other occasions when a result would require relocation.
>>> 
>>> Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated.
>> 
>> Do you mean that DW_OP_addr's argument should be relocated in all instances
>> of a DWARF expression, i.e. in other .debug_ sections, or just in the context of
>> .debug_frame?
> 
> I was specifically talking about DWARF expressions in any .debug_frame info.

Well, that would preclude relocating the *result* of any DWARF expression in
.debug_frame.  For some expressions, e.g. DW_CFA_expression, the use
of the CFA to initialise the stack implies as much but this would be a useful
blanket constraint.


> But in general, yes, any DWARF expression that contains a DW_OP_addr might need a relocation for its address argument.

Are you aware of where in the standard this is documented?  It sounds reasonable
but I'm returning to this after a long time and I don't remember my way around as
well as I used to.



From echristo@gmail.com  Mon Sep 24 17:40:53 2018
From: echristo@gmail.com (Eric Christopher)
Date: Mon, 24 Sep 2018 10:40:53 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
Message-ID: <CALehDX6bke=NKj8mxQVN9ykbyVM7nHMw5EaKsGWLW+RkcpC96A@mail.gmail.com>

Dwarf 5, 7.3.1

"A DWARF expression may contain a DW_OP_addr (see Section 2.5.1.1 on 31
page 26) which contains a location within the virtual address space of the
32 program, and require relocation."

On Mon, Sep 24, 2018 at 10:35 AM Robert Harris via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

>
>
> > On 24 Sep 2018, at 16:59, Greg Clayton <clayborg at gmail.com> wrote:
> >
> >
> >
> >> On Sep 24, 2018, at 8:44 AM, Robert Harris <robert.m.harris at oracle.com>
> wrote:
> >>
> >>
> >>
> >>> On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On Sep 24, 2018, at 7:15 AM, Robert Harris via Dwarf-Discuss <
> dwarf-discuss at lists.dwarfstd.org> wrote:
> >>>>
> >>>> I'd like some clarification regarding what precisely needs to be
> relocated relative to
> >>>> the object load address when interpreting .debug_frame.  I'm
> interested in versions
> >>>> 2, 3 and 4.
> >>>>
> >>>> I think the only explicit mention of relocation in DWARF 4 is ? 6.4.1:
> >>>>
> >>>>    Abstractly, this mechanism describes a very large table...
> >>>>    ...
> >>>>    The first column indicates an address for every location that
> contains
> >>>>    code in a program. (In shared objects, this is an object-relative
> offset.)
> >>>>
> >>>> Thus adjustments need to be made to only
> >>>>
> >>>>    An FDE's initial_location field
> >>>>    DW_CFA_set_loc's operand
> >>>>
> >>>> Have I missed anything?  I see some ambiguity in the definition of
> >>>> DW_CFA_def_cfa_expression and it's making me wonder if there are any
> >>>> other occasions when a result would require relocation.
> >>>
> >>> Any DWARF expression can contain a DW_OP_addr, which has an address
> argument, and would need to be relocated.
> >>
> >> Do you mean that DW_OP_addr's argument should be relocated in all
> instances
> >> of a DWARF expression, i.e. in other .debug_ sections, or just in the
> context of
> >> .debug_frame?
> >
> > I was specifically talking about DWARF expressions in any .debug_frame
> info.
>
> Well, that would preclude relocating the *result* of any DWARF expression
> in
> .debug_frame.  For some expressions, e.g. DW_CFA_expression, the use
> of the CFA to initialise the stack implies as much but this would be a
> useful
> blanket constraint.
>
>
> > But in general, yes, any DWARF expression that contains a DW_OP_addr
> might need a relocation for its address argument.
>
> Are you aware of where in the standard this is documented?  It sounds
> reasonable
> but I'm returning to this after a long time and I don't remember my way
> around as
> well as I used to.
>
> _______________________________________________
> 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/20180924/2f5a6b6f/attachment.html>


From eager@eagercon.com  Mon Sep 24 17:46:25 2018
From: eager@eagercon.com (Michael Eager)
Date: Mon, 24 Sep 2018 10:46:25 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
Message-ID: <a1f4518a-47f8-2f7a-2e82-b3abc1e16d22@eagercon.com>

On 09/24/2018 09:19 AM, Robert Harris via Dwarf-Discuss wrote:
>> But in general, yes, any DWARF expression that contains a DW_OP_addr might need a relocation for its address argument.
 >
> Are you aware of where in the standard this is documented?  It sounds reasonable
> but I'm returning to this after a long time and I don't remember my way around as
> well as I used to.

DW_OP_addr is described in Section 2.5.1.1 of the DWARF 5 Standard:

   2. DW_OP_addr

      The DW_OP_addr operation has a single operand that encodes a
      machine address and whose size is the size of an address on the
      target machine.

The most common way in which the machine address is provided as the 
operand is by generating a relocatable value pointing to the target 
address.  This is not really a DWARF specification; it is how 
relocations work in assemblers and linkers.

-- 
Michael Eager    eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306


From echristo@gmail.com  Mon Sep 24 18:00:34 2018
From: echristo@gmail.com (Eric Christopher)
Date: Mon, 24 Sep 2018 11:00:34 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <a1f4518a-47f8-2f7a-2e82-b3abc1e16d22@eagercon.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
 <a1f4518a-47f8-2f7a-2e82-b3abc1e16d22@eagercon.com>
Message-ID: <CALehDX6mSF7qfH-bcRww1i7p+j40k622LVZ4RiNcrd97H8CKbQ@mail.gmail.com>

On Mon, Sep 24, 2018 at 10:55 AM Michael Eager via Dwarf-Discuss <
dwarf-discuss at lists.dwarfstd.org> wrote:

> On 09/24/2018 09:19 AM, Robert Harris via Dwarf-Discuss wrote:
> >> But in general, yes, any DWARF expression that contains a DW_OP_addr
> might need a relocation for its address argument.
>  >
> > Are you aware of where in the standard this is documented?  It sounds
> reasonable
> > but I'm returning to this after a long time and I don't remember my way
> around as
> > well as I used to.
>
> DW_OP_addr is described in Section 2.5.1.1 of the DWARF 5 Standard:
>
>    2. DW_OP_addr
>
>       The DW_OP_addr operation has a single operand that encodes a
>       machine address and whose size is the size of an address on the
>       target machine.
>
> The most common way in which the machine address is provided as the
> operand is by generating a relocatable value pointing to the target
> address.  This is not really a DWARF specification; it is how
> relocations work in assemblers and linkers.
>
>
Yes. This is where 7.3.1 comes in handy :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180924/3c27814e/attachment.html>


From robert.m.harris@oracle.com  Mon Sep 24 19:45:13 2018
From: robert.m.harris@oracle.com (Robert Harris)
Date: Mon, 24 Sep 2018 20:45:13 +0100
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <CALehDX6bke=NKj8mxQVN9ykbyVM7nHMw5EaKsGWLW+RkcpC96A@mail.gmail.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
 <CALehDX6bke=NKj8mxQVN9ykbyVM7nHMw5EaKsGWLW+RkcpC96A@mail.gmail.com>
Message-ID: <5BED5931-EC28-4928-8CAC-F4AE7DFD8233@oracle.com>


> On 24 Sep 2018, at 18:40, Eric Christopher <echristo at gmail.com> wrote:
> 
> Dwarf 5, 7.3.1
> 
> "A DWARF expression may contain a DW_OP_addr (see Section 2.5.1.1 on 31 page 26) which contains a location within the virtual address space of the 32 program, and require relocation."

I think I've confused the issue by using the word relocation instead
of the phrase "interpreted relative to the base address of the load
object".

I'm interested in the final state of an executable or shared object
and I don't expect to find any remaining ELF-style (e.g.
R_AMD64_64 and the like) run time (ld.so) relocations in non-loadable
.debug_* sections.

My question instead concerns things like initial_location in an FDE,
which is interpreted relative to the base address of the enclosing
load object.  I can see that DW_CFA_set_loc's operand would also
need to be interpreted as relative to the same base address.  However,
I'm trying to establish if there's anything else within .debug_frame that
would be expressed relative to the same base address.  For example,
DW_CFA_expression assumes that the CFA is already on the stack and it
would be perverse to expect the result to be anything other than an
absolute address.  But is the same true of DW_CFA_def_cfa_expressions?
What about instructions within the expressions themselves...

The DW_OP_addr case is confusing.  As it's an object address its
operand is highly likely to require an ELF-style (ld-style) relocation
to produce an appropriate address in the linked object.  However, I
can see that in a shared object it would be plausible that the final,
ELF-style relocated argument should additionally need to be interpreted
as relative to the load object's base address.  I assumed Greg was
asserting the latter with:

> On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
> 
> Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated. 

and, not remembering any mention to the contrary in DWARF 2/3/4
wondered if this was really the case --- it would certainly have
helped answer my actual concern about .debug_frame.  However, the
follow-up references to DWARF 5 7.3.1 and 2.5.1.1 are discussing
ELF-style relocations, and are, unfortunately, red herrings.

Robert 


From ccoutant@gmail.com  Tue Sep 25 00:44:02 2018
From: ccoutant@gmail.com (Cary Coutant)
Date: Mon, 24 Sep 2018 17:44:02 -0700
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <5BED5931-EC28-4928-8CAC-F4AE7DFD8233@oracle.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
 <CALehDX6bke=NKj8mxQVN9ykbyVM7nHMw5EaKsGWLW+RkcpC96A@mail.gmail.com>
 <5BED5931-EC28-4928-8CAC-F4AE7DFD8233@oracle.com>
Message-ID: <CAJimCsFSuKfGogek6aozob_2mM_giixki_VqT3NgV2m0B+mrwQ@mail.gmail.com>

> I'm interested in the final state of an executable or shared object
> and I don't expect to find any remaining ELF-style (e.g.
> R_AMD64_64 and the like) run time (ld.so) relocations in non-loadable
> .debug_* sections.

No, you're not going to see any dynamic relocations for non-loadable
sections. Linkers typically do not generate dynamic relocations for
these sections even in the presence of an R_*_64 relocation which
would result in either an R_*_64 or an R_*_RELATIVE dynamic relocation
for a loadable section. Instead, the consumer (e.g., debugger) is
expected to have enough context to know where it might find addresses
that will need runtime relocation.

> My question instead concerns things like initial_location in an FDE,
> which is interpreted relative to the base address of the enclosing
> load object.  I can see that DW_CFA_set_loc's operand would also
> need to be interpreted as relative to the same base address.

Yes, both the initial_location and the operand of DW_CFA_set_loc would
be link-time relocated to an address in the image, but would need
run-time relocation by the consumer if the load address does not match
the link-time address.

Things get more complicated with Gnu .eh_frame sections -- these carry
an augmentation string that says such addresses are actually
pc-relative offsets. If you look at the relocations in the object
file, you can see R_*_PC32 relocations (or equivalent). These are used
because the .eh_frame sections are part of the text segment and
absolute relocations would have resulted in dynamic relocations in
text.

> However,
> I'm trying to establish if there's anything else within .debug_frame that
> would be expressed relative to the same base address.  For example,
> DW_CFA_expression assumes that the CFA is already on the stack and it
> would be perverse to expect the result to be anything other than an
> absolute address.

Correct. Any addresses you get from registers at runtime will not need
further relocation.

> But is the same true of DW_CFA_def_cfa_expressions?
> What about instructions within the expressions themselves...
>
> The DW_OP_addr case is confusing.  As it's an object address its
> operand is highly likely to require an ELF-style (ld-style) relocation
> to produce an appropriate address in the linked object.  However, I
> can see that in a shared object it would be plausible that the final,
> ELF-style relocated argument should additionally need to be interpreted
> as relative to the load object's base address.  I assumed Greg was
> asserting the latter with:
>
> > On 24 Sep 2018, at 15:33, Greg Clayton <clayborg at gmail.com> wrote:
> >
> > Any DWARF expression can contain a DW_OP_addr, which has an address argument, and would need to be relocated.

Yes. DW_OP_addr is used to provide a symbolic address, which will need
relocation at both link time and load time.

> and, not remembering any mention to the contrary in DWARF 2/3/4
> wondered if this was really the case --- it would certainly have
> helped answer my actual concern about .debug_frame.  However, the
> follow-up references to DWARF 5 7.3.1 and 2.5.1.1 are discussing
> ELF-style relocations, and are, unfortunately, red herrings.

That's not a red herring. Relocations are relocations, whether they're
"ELF-style" or implicit by context, and both linker (static) and
dynamic relocations are "ELF style". Debug sections don't have dynamic
relocations simply because they're unloadable and we can leave it up
to the consumer to figure out where all the relocatable addresses are.
(Otherwise, debug info would be even more expensive than it already
is!)

The new material in Section 7.3.1 about what needs relocation is
clarifying material that was just as true for DWARF 2, 3, and 4. That
was an attempt to pre-emptively answer your questions above.

-cary


From robert.m.harris@oracle.com  Tue Sep 25 17:34:47 2018
From: robert.m.harris@oracle.com (Robert Harris)
Date: Tue, 25 Sep 2018 18:34:47 +0100
Subject: [Dwarf-Discuss] .debug_frame and the base address
In-Reply-To: <CAJimCsFSuKfGogek6aozob_2mM_giixki_VqT3NgV2m0B+mrwQ@mail.gmail.com>
References: <EDD95D06-499B-4B82-B2C7-1D51BEBCE989@oracle.com>
 <E69352C4-0317-4DFA-AE97-F00CCABC63DC@gmail.com>
 <16F0F6E0-4F26-44E3-9658-2C959CC232DA@oracle.com>
 <4FB9DCF4-11AF-434F-B599-1595AEDCEDA5@gmail.com>
 <4199AF09-45F6-4E23-9C59-91781C3704E2@oracle.com>
 <CALehDX6bke=NKj8mxQVN9ykbyVM7nHMw5EaKsGWLW+RkcpC96A@mail.gmail.com>
 <5BED5931-EC28-4928-8CAC-F4AE7DFD8233@oracle.com>
 <CAJimCsFSuKfGogek6aozob_2mM_giixki_VqT3NgV2m0B+mrwQ@mail.gmail.com>
Message-ID: <96773E1A-9F3B-47E2-9055-F60FF41E3E71@oracle.com>


> On 25 Sep 2018, at 01:44, Cary Coutant <ccoutant at gmail.com> wrote:
> 
> The new material in Section 7.3.1 about what needs relocation is
> clarifying material that was just as true for DWARF 2, 3, and 4. That
> was an attempt to pre-emptively answer your questions above.

OK.  Many thanks, all, for your clarifications and your patience.  I'll
digest them and the references.

Robert


