[Dwarf-Discuss] .debug_frame and the base address

[Cary Coutant]

> 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