Re: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen?

[zhihua che <zhihua.che@gmail.com>]

Maybe I'm closer to the truth. I had discarded .eh_frame section when
linking the os in the first time, and gotten the problem mentioned
above. Right before I took a try to keep the .eh_frame section in the
final ELF file and didn't get the error messages. But unfortunately,
this didn't correct this problem totally. Although I can issue the
"print xxx"command and get the normal reply, the value returned by GDB
is not correct, just like garbage values.  Luckily, I can get the
correct address of the local variable by "print &xxx" command, and get
the correct value by command like "x /1wx address".

As for "backtrace", I also can get normal reply, but only the
innermost frame was printed (and another one I can't figure out which
one it is because only one address was printed instead of its function
name) no matter how deep I issue the command.

2011/11/1 zhihua che <zhihua.che@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
>>
>