This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Interpretation of DWARF FDE->CIE_pointer field for .debug_frame
- From: Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, <dwarf-discuss at lists dot dwarfstd dot org>, Joern Rennecke <joern dot rennecke at embecosm dot com>, Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>, <gcc at gcc dot gnu dot org>
- Date: Tue, 25 Jun 2013 09:36:17 +0530
- Subject: Re: Interpretation of DWARF FDE->CIE_pointer field for .debug_frame
- References: <51C7E8EB dot 50509 at synopsys dot com> <20130624070335 dot GF2336 at tucnak dot redhat dot com> <51C7F18B dot 6020208 at synopsys dot com> <20130624072815 dot GG2336 at tucnak dot redhat dot com> <51C7F755 dot 7070800 at synopsys dot com> <51C89889 dot 2030405 at redhat dot com>
On 06/25/2013 12:35 AM, Richard Henderson wrote:
> On 06/24/2013 12:37 AM, Vineet Gupta wrote:
>> 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.
> It seems like it would be easier to change the kernel to use .eh_frame
> rather than adding relocation types and changing the tool chain...
Yes that is what we concluded as well. Although the current issue manifests only
as objdump/readelf splat with kernel binary - the unwinder itself in kernel works
OK. But .eh_frame is what others do so we might as well follow suite given that
ARC gcc 4.8 now has started generating one.
-Vineet