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: Jakub Jelinek <jakub at redhat dot com>
- Cc: <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: Mon, 24 Jun 2013 12:43:15 +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>
On 06/24/2013 12:33 PM, Jakub Jelinek wrote:
> On Mon, Jun 24, 2013 at 12:06:27PM +0530, Vineet Gupta wrote:
>> I had a question about interpretation of FDE's CIE_pointer field (for .debug_frame)
>>
>> The spec say (from dwarf4 version although it really doesn't matter):
>>
>> "2. CIE_pointer (4 or 8 bytes, see Section 7.4)
>> A constant offset into the .debug_frame section that denotes the CIE that is
>> associated with this FDE."
>>
>> Does "offset" above mean offset from current location (in FDE) to CIE or does it
>> mean offset from start of .debug_frame to the CIE. Per Ian Lance Taylor's blog,
>> and if I'm interpreting it correctly, (http://www.airs.com/blog/archives/460) it
>> seems to be latter.
> CIE_pointer in .debug_frame is relative to the start of the .debug_frame
> section. In .eh_frame section it is encoded based on the selected encoding,
> often relative to the start of the CIE_pointer.
>
>> ...
>> .LSFDE0:
>> .4byte @.LEFDE0-@.LASFDE0 --> FDE
>> .LASFDE0:
>> .4byte @.Lframe0 --> CIE pointer - direct reference to CI (not
>> offset from start of .debug_frame)
> This looks fine.
Pardon me if I sound dense (not really my area of expertise), wowever, the 2nd
word in FDE above (@.Lframe0) is a direct reference to start of .debbug_frame
shouldn't it be something like
@.Lframe0 - @.Lframe0
i.e. zero.
Or do you think asseblmer/linker need to "interpret it" like that.
>> ....
>>
>> This direct reference to start of CIE is causing objdump to reference invalid CIE
>> and hence print invalid CFI - although the CFI itself is valid since the
>> code_factor and such are seeded from a bogus CIE.
>>
>> 00000060 00000014 80e0c000 FDE cie=48b25ff8 pc=80a680d4..80a6810a
>> ... ^^^^^^
> The 48b25ff8 looks wrong though, it would really surprise me if .debug_frame
> section was more than 1GB big. So perhaps your assembler or linker don't
> handle it properly?
Exactly, although this is Linux kernel image which is linked at start of
untranslated address space i.e. 0x8000_0000 onwards. The point however is that cie
value above should read zero - not 0x8abcdefg since it is relative to start of
.debug_frame
-Vineet