This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interpretation of DWARF FDE->CIE_pointer field for .debug_frame


On 06/24/2013 12:58 PM, Jakub Jelinek wrote:
> On most targets, .debug_* sections are placed at address 0, so absolute
> relocations are the same as relocations relative to the start of the
> section.
> [snipped]
>
> So, either .debug_* sections are placed at address 0 and then absolute
> relocations will do the trick, or you need some kind of section relative
> relocation (e.g. ia64 has it I think).  This isn't specific just to
> .debug_frame, e.g. DW_FORM_strp/DW_FORM_sec_offset encoded values in .debug_info
> or .debug_abbrev offsets in .debug_info CU header, DW_OP_call_ref arguments,
> .debug_aranges/.debug_pubtypes/.debug_pubnames offsets to .debug_info all
> have these requirements.
>
> 	Jakub

Aha, I see what's happening. For historical reasons, ARC Linux kernel stack
unwinder relies on .debug_frame (vs. .eh_frame) for stack unwinding. Being non
allocatable it would default to address zero hence the orig absolute relocations
would work for most ports. However in our case we force it allocatable in kernel
builds and thus it is relocated to 0x8abcdefg, thus the usage of absolute
relocations ends up generating the invalid reference.

Thus it seems we do need the special section relative reference.

Thanks a bunch for clarifying.

--Vineet


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]