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

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

[zhihua che]

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. The codes seem work, but I
can only exam registers or memory using "info reg" or "x" command,
it's way unfriendly and time-consuming. I have searched a lot but
don't figure out how these happen. I need your help. Thanks.

Harvey

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

[Pedro Alves]

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.

> The codes seem work, but I
> can only exam registers or memory using "info reg" or "x" command,
> it's way unfriendly and time-consuming. I have searched a lot but
> don't figure out how these happen. I need your help. Thanks.

What's the output of "info all-registers"?

-- 
Pedro Alves

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

[zhihua che]

---------- 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 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 But I
don't know what causes this. I'm really no familiar with GDB
internals.

>
>> The codes seem work, but I
>> can only exam registers or memory using "info reg" or "x" command,
>> it's way unfriendly and time-consuming. I have searched a lot but
>> don't figure out how these happen. I need your help. Thanks.
>
> What's the output of "info all-registers"?
>
> --
> Pedro Alves
>

The out of "info reg" seems Okay. This is the only way I can exam the
executing status of my program until so far.

Thanks for your suggestions. And if it would help, the following is
the compiling options I use.

gcc -g -Wall -mregparm=3 -march=i386 -m32 -mpreferred-stack-boundary=2
-fomit-frame-pointer -ffreestanding -fno-toplevel-reorder
-fno-strict-aliasing -fno-stack-protector -nostdinc -Ixxx

and the link script is like this,

SECTIONS {
   . = 0x0
   .text {*(.text)}
   .rodata{*(.rodata)}
   .data{*(.data)}
   /DISCARD/ : {*(.eh_frame)}
}

}

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

[zhihua che]

---------- Forwarded message ----------
From: Pedro Alves <pedro@codesourcery.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: zhihua che <zhihua.che@gmail.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?

--
Pedro Alves

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

[zhihua che]

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
>>
>