This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Fwd: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen?
- From: zhihua che <zhihua dot che at gmail dot com>
- To: gdb <gdb at sourceware dot org>
- Date: Tue, 1 Nov 2011 05:35:45 +0800
- Subject: Fwd: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen?
- References: <CABexPfGFMUgzjRZ22nsB=A2RoQk2oYORHA+E2cX2y6=bU+Hgjw@mail.gmail.com> <201110311743.03721.pedro@codesourcery.com> <CABexPfH0HLsP1mR2oxR1HfSxOUkULL6pErB2QiVfR0es+G=qqw@mail.gmail.com> <201110311946.50273.pedro@codesourcery.com> <CABexPfFbrt6hv5fBvXMYXxVCaD_x7KFvUq-DV1X8EvWQaVsonQ@mail.gmail.com>
---------- Forwarded message ----------
From: zhihua che <zhihua.che@gmail.com>
Date: 2011/11/1
Subject: Re: How "can't compute CFA for this frame" and "no enough
registers or memory available to further unwind" happen?
To: Pedro Alves <pedro@codesourcery.com>
2011/11/1 Pedro Alves <pedro@codesourcery.com>:
> On Monday 31 October 2011 18:45:09, zhihua che wrote:
>> 2011/11/1 Pedro Alves <pedro@codesourcery.com>:
>> > On Monday 31 October 2011 17:25:46, zhihua che wrote:
>> >> Hi, everyone
>> >>
>> >> ? ? ? ?I'm not sure this is right place for the help. I'm writing a
>> >> toy os and coding with mixed assembly and C language, debugging with
>> >> GDB. But I'm trapped with an annoying problem. This is my situation:
>> >> During the os booting time, after the os control transfers from real
>> >> mode assembly codes to real mode C codes, I wish I can exam the stack
>> >> frames and local variable as I do in regular application program, but
>> >> I always get "can't compute CFA for this frame" or "No enough
>> >> registers or memory available to further unwind" if I issue "print
>> >> xxx" or "backtrace" command respectivelly.
>> >
>> > You'll need to debug gdb. ?Check what is it that gdb is finding
>> > unavailable. ?Put a breakpoint at `throw_error' and then do that
>> > "print XXX". ?You should hit a call like `throw_error (NOT_AVAILABLE_ERROR...'.
>> > Get a backtrace. ?Do "continue" on the top gdb, and see if further
>> > hits appear. ?GDB has an exception handling mechanism, and that
>> > exception may be thrown more than once during a command run.
>>
>> I've tried debugging the GDB under "print xxx" circumstance, and I
>> find it doesn't satisfy an comparison in dwarf2_frame_cfa() which is
>> like the below:
>> ? ? ? if (! frame_unwinder_is(this_frame, &dwarf2_frame_unwinder))
>> ? ? ? ? ? ?error(_("can't compute CFA for this frame"))
>> the frame_unwinder_is() tests if this_frame->unwind is equal with
>> &dwarf2_frame_unwind. And I further find out this_frame->unwind is
>> equal with &sentinel_frame_unwind instead in this situation
>
> This code changed recently. ?You should try mainline gdb, or a
> recent cvs snapshop. ?What's the gdb version you're using BTW?
>
> And what's the gdb backtrace at that point?
>
I use GDB-7.3.1
I issue "backtrace" at the second C funcation. The calling sequence is that
the assembly codes call C function of prepare_for_pm() and in turn
call detect_memory_e820 where I issue "backtrace".
The output is:
#0 detect_memory_e820() at memory.c 10
Backtrace stopped: No enough available registers or memory to further unwind.
Yes, No matter how deepI issue backtrace, it only outputs the
innermost stack frame.
> --
> Pedro Alves
>