From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14034 invoked by alias); 16 Oct 2003 01:15:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13993 invoked from network); 16 Oct 2003 01:14:36 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 16 Oct 2003 01:14:36 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3AD192B89; Wed, 15 Oct 2003 21:14:29 -0400 (EDT) Message-ID: <3F8DF0F5.4090807@gnu.org> Date: Thu, 16 Oct 2003 01:15:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] frv-tdep.c: Stop backtraces in entry func, not entry file References: <1031014205135.ZM29586@localhost.localdomain> <3F8C70CE.5020504@gnu.org> <1031016000707.ZM23790@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00530.txt.bz2 > On Oct 14, 5:55pm, Andrew Cagney wrote: > > >> > An FR-V user reported being unable to see useful backtraces when >> > debugging functions inside the entry file. This patch fixes that >> > problem. I think there's a problem with inside_entry_func() itself, >> > but that's a separate issue. (If you are in the entry file, >> > backtraces don't stop at the entry func - they attempt to continue >> > beyond, but they do stop shortly thereafter.) > >> >> What happens if that test is removed? > > > At the moment, the behavior is the same whether the test is there or > not. That is, things work as expected so long as your're in main() > or above. If you go below main(), then things break down. The > inside_entry_func() test ought to stop backtraces from going too > far, but for FR-V at least, it seems to be broken. > > Here's an example of where things break down: > > 0x00010118 in _start () > 1: x/i $pc 0x10118 <_start+280>: call 0x11dc0 > (gdb) bt > #0 0x00010118 in _start () > #1 0x00018ed4 in _write_r (ptr=0x0, fd=0, buf=0x0, cnt=5) > at /ocotillo2/devo-frv/frv-elf/bld/../../devo/newlib/libc/reent/writer.c:58 > Previous frame inner to this frame (corrupt stack?) In that case, the test should be removed. It definitly doesn't belong there. Instead your ABI should specify a robust way of detecting a terminated stack. For instance, the PPC specifies that the stack chain is ended with a ZERO entry. Here's the relevant comments in "frame.c": /* If we're already inside the entry function for the main objfile, then it isn't valid. Don't apply this test to a dummy frame - dummy frame PC's typically land in the entry func. Don't apply this test to the sentinel frame. Sentinel frames should always be allowed to unwind. */ /* NOTE: cagney/2003-02-25: Don't enable until someone has found hard evidence that this is needed. */ /* NOTE: cagney/2003-07-07: Fixed a bug in inside_main_func - wasn't checking for "main" in the minimal symbols. With that fixed asm-source tests now stop in "main" instead of halting the backtrace in wierd and wonderful ways somewhere inside the entry file. Suspect that deprecated_inside_entry_file and inside_entry_func tests were added to work around that (now fixed) case. */ /* NOTE: cagney/2003-07-15: danielj (if I'm reading it right) suggested having the inside_entry_func test use the inside_main_func msymbol trick (along with entry_point_address I guess) to determine the address range of the start function. That should provide a far better stopper than the current heuristics. */ /* NOTE: cagney/2003-07-15: Need to add a "set backtrace beyond-entry-func" command so that this can be selectively disabled. */ I'd like to avoid re-introducing a dependency on inside_entry_func() as that places garish requirements on the object file readers :-( I also suspect that just removing the test fixes the bug. The other relevant comment is: /* If we're inside the entry file, it isn't valid. Don't apply this test to a dummy frame - dummy frame PC's typically land in the entry file. Don't apply this test to the sentinel frame. Sentinel frames should always be allowed to unwind. */ /* NOTE: drow/2002-12-25: should there be a way to disable this check? It assumes a single small entry file, and the way some debug readers (e.g. dbxread) figure out which object is the entry file is somewhat hokey. */ /* NOTE: cagney/2003-01-10: If there is a way of disabling this test then it should probably be moved to before the ->prev_p test, above. */ /* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call to deprecated_inside_entry_file destroys a meaningful backtrace under some conditions. E. g. the backtrace tests in the asm-source testcase are broken for some targets. In this test the functions are all implemented as part of one file and the testcase is not necessarily linked with a start file (depending on the target). What happens is, that the first frame is printed normaly and following frames are treated as being inside the enttry file then. This way, only the #0 frame is printed in the backtrace output. */ Corinna disabled this for just the reason you describe. Andrew