From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2922 invoked by alias); 1 Mar 2004 23:52:40 -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 2912 invoked from network); 1 Mar 2004 23:52:38 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 1 Mar 2004 23:52:38 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 7EF1547D62; Mon, 1 Mar 2004 15:52:39 -0800 (PST) Date: Mon, 01 Mar 2004 23:52:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] use frame IDs to detect function calls while stepping Message-ID: <20040301235239.GP1051@gnat.com> References: <20040205044119.GC18961@gnat.com> <20040205171324.GF18961@gnat.com> <16418.37058.65446.669052@localhost.redhat.com> <20040207040049.GH18961@gnat.com> <403F60F1.7020902@gnu.org> <20040301194801.GK1051@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040301194801.GK1051@gnat.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-03.o/txt/msg00016.txt Message-ID: <20040301235200.pJPl980pvpcPNXMPZnFU8ib88qzhSM42GEJ_LIg8orA@z> Ok, I'm dark red with shame. > Yes, there is a regression (regression #2 in my previous message) if > we leave that test out. It's been a while since I posted that patch, > so I don't remember the details anymore :-/. I'll dig again later today. It looks like my initial analysis of the cause of regression #2 was wrong. I will simply say that I was mislead by the fact that GDB reported that we stopped in "_PROCEDURE_LINKAGE_TABLE_" while we were actually inside function "exit", and let it go at that. Here is a description of the regression which appears if we don't include the following test: + if (IN_SOLIB_CALL_TRAMPOLINE (stop_pc, ecs->stop_func_name)) + { + /* We landed in a shared library call trampoline, so it + is a subroutine call. */ + handle_step_into_function (ecs); + return; + } The problem occurs with ending-run: % gdb ending-run (gdb) b ending-run.c:33 Breakpoint 1 at 0x10828: file gdb.base/ending-run.c, line 33. (gdb) run Starting program: /[...]/gdb.base/ending-run -1 2 7 14 23 34 47 62 79 Goodbye! Breakpoint 1, main () at gdb.base/ending-run.c:33 33 } (gdb) n 0x000105ec in _start () (gdb) n Single stepping until exit from function _start, which has no line number information. 0x00020950 in _PROCEDURE_LINKAGE_TABLE_ () The expected behavior for the last "next" command is for GDB to run until the inferior exits: (gdb) n Single stepping until exit from function _start, which has no line number information. Program exited normally. Unfortunately, here is what happens. At 0x000105ec, before we do our second "next" command, we are about to execute the following code: 0x000105ec <_start+100>: call 0x20950 0x000105f0 <_start+104>: nop After two iterations (one for the call insn, and one for the delay slot), GDB lands at the begining of function "exit" at 0x00020950, which is: 0x00020950 : sethi %hi(0xf000), %g1 0x00020954 : b,a 0x20914 <_PROCEDURE_LINKAGE_TABLE_> 0x00020958 : nop So at this point, the registers window has not been rotated. I don't know if this is the cause for this problem, but at this point GDB is unable to unwind the call stack: (gdb) bt #0 0x00020950 in _PROCEDURE_LINKAGE_TABLE_ () (And gets the wrong procedure name as well, but that's a separate issue - although "x /i" does report what I believe is the correct name, strange!). I am looking into the sparc unwinder code right now, to try to understand a bit better the source of the problem. -- Joel