* How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? @ 2011-10-31 17:43 zhihua che 2011-10-31 20:54 ` Pedro Alves 0 siblings, 1 reply; 5+ messages in thread From: zhihua che @ 2011-10-31 17:43 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? 2011-10-31 17:43 How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? zhihua che @ 2011-10-31 20:54 ` Pedro Alves [not found] ` <CABexPfH0HLsP1mR2oxR1HfSxOUkULL6pErB2QiVfR0es+G=qqw@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Pedro Alves @ 2011-10-31 20:54 UTC (permalink / raw) To: gdb; +Cc: zhihua che 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CABexPfH0HLsP1mR2oxR1HfSxOUkULL6pErB2QiVfR0es+G=qqw@mail.gmail.com>]
* Fwd: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? [not found] ` <CABexPfH0HLsP1mR2oxR1HfSxOUkULL6pErB2QiVfR0es+G=qqw@mail.gmail.com> @ 2011-10-31 21:35 ` zhihua che [not found] ` <201110311946.50273.pedro@codesourcery.com> 1 sibling, 0 replies; 5+ messages in thread From: zhihua che @ 2011-10-31 21:35 UTC (permalink / raw) To: gdb ---------- 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)} } } ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <201110311946.50273.pedro@codesourcery.com>]
* Fwd: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? [not found] ` <201110311946.50273.pedro@codesourcery.com> @ 2011-10-31 21:36 ` zhihua che [not found] ` <CABexPfFbrt6hv5fBvXMYXxVCaD_x7KFvUq-DV1X8EvWQaVsonQ@mail.gmail.com> 1 sibling, 0 replies; 5+ messages in thread From: zhihua che @ 2011-10-31 21:36 UTC (permalink / raw) To: gdb ---------- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CABexPfFbrt6hv5fBvXMYXxVCaD_x7KFvUq-DV1X8EvWQaVsonQ@mail.gmail.com>]
[parent not found: <CABexPfEFdc10NEVtJREy6NoryHNXFWt55+kMHoKpqO_ggQKvOg@mail.gmail.com>]
* Re: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? [not found] ` <CABexPfEFdc10NEVtJREy6NoryHNXFWt55+kMHoKpqO_ggQKvOg@mail.gmail.com> @ 2011-11-01 11:58 ` zhihua che 0 siblings, 0 replies; 5+ messages in thread From: zhihua che @ 2011-11-01 11:58 UTC (permalink / raw) To: gdb 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 >> > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-11-01 11:58 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-31 17:43 How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? zhihua che 2011-10-31 20:54 ` Pedro Alves [not found] ` <CABexPfH0HLsP1mR2oxR1HfSxOUkULL6pErB2QiVfR0es+G=qqw@mail.gmail.com> 2011-10-31 21:35 ` Fwd: " zhihua che [not found] ` <201110311946.50273.pedro@codesourcery.com> 2011-10-31 21:36 ` zhihua che [not found] ` <CABexPfFbrt6hv5fBvXMYXxVCaD_x7KFvUq-DV1X8EvWQaVsonQ@mail.gmail.com> [not found] ` <CABexPfEFdc10NEVtJREy6NoryHNXFWt55+kMHoKpqO_ggQKvOg@mail.gmail.com> 2011-11-01 11:58 ` zhihua che
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).