From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31323 invoked by alias); 1 Nov 2011 11:58:10 -0000 Received: (qmail 31312 invoked by uid 22791); 1 Nov 2011 11:58:09 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-pz0-f49.google.com (HELO mail-pz0-f49.google.com) (209.85.210.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Nov 2011 11:57:54 +0000 Received: by pzk32 with SMTP id 32so21114158pzk.8 for ; Tue, 01 Nov 2011 04:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.41 with SMTP id d9mr57466pbk.103.1320148673489; Tue, 01 Nov 2011 04:57:53 -0700 (PDT) Received: by 10.68.43.137 with HTTP; Tue, 1 Nov 2011 04:57:53 -0700 (PDT) In-Reply-To: References: <201110311743.03721.pedro@codesourcery.com> <201110311946.50273.pedro@codesourcery.com> Date: Tue, 01 Nov 2011 11:58:00 -0000 Message-ID: Subject: Re: How "can't compute CFA for this frame" and "no enough registers or memory available to further unwind" happen? From: zhihua che To: gdb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00001.txt.bz2 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 : > ---------- Forwarded message ---------- > From: zhihua che > 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 > > > 2011/11/1 Pedro Alves : >> On Monday 31 October 2011 18:45:09, zhihua che wrote: >>> 2011/11/1 Pedro Alves : >>> > On Monday 31 October 2011 17:25:46, zhihua che wrote: >>> >> Hi, everyone >>> >> >>> >> =A0 =A0 =A0 =A0I'm not sure this is right place for the help. I'm wr= iting 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. =A0Check what is it that gdb is finding >>> > unavailable. =A0Put a breakpoint at `throw_error' and then do that >>> > "print XXX". =A0You should hit a call like `throw_error (NOT_AVAILABL= E_ERROR...'. >>> > Get a backtrace. =A0Do "continue" on the top gdb, and see if further >>> > hits appear. =A0GDB 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: >>> =A0 =A0 =A0 if (! frame_unwinder_is(this_frame, &dwarf2_frame_unwinder)) >>> =A0 =A0 =A0 =A0 =A0 =A0error(_("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. =A0You should try mainline gdb, or a >> recent cvs snapshop. =A0What'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 th= at > 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 unw= ind. > > Yes, No matter how deepI issue backtrace, it only outputs the > innermost stack frame. > >> -- >> Pedro Alves >> >