> 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 <clayb...@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 _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
