From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8617 invoked by alias); 14 Jun 2005 14:54:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8576 invoked by uid 22791); 14 Jun 2005 14:54:16 -0000 Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 14 Jun 2005 14:54:16 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1DiCnu-0000a6-2b for gdb@sources.redhat.com; Tue, 14 Jun 2005 18:54:14 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1DiCnm-0000Xu-0F; Tue, 14 Jun 2005 18:54:06 +0400 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: problem debugging assembler functions Date: Tue, 14 Jun 2005 14:54:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <20050614143654.GB3288@nevyn.them.org> In-Reply-To: <20050614143654.GB3288@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506141854.04712.ghost@cs.msu.su> X-SW-Source: 2005-06/txt/msg00132.txt.bz2 On Tuesday 14 June 2005 18:36, Daniel Jacobowitz wrote: > On Tue, Jun 14, 2005 at 01:21:53PM +0400, Vladimir Prus wrote: > > Line 2285: > > > > if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) > > { > > ...... > > } > > FYI, this bit... > > > Line 2428: > > > > if (step_over_calls == STEP_OVER_UNDEBUGGABLE > > && ecs->stop_func_name == NULL) > > { > > /* The inferior just stepped into, or returned to, an > > undebuggable function (where there is no symbol, not even a > > minimal symbol, corresponding to the address where the > > inferior stopped). > > */ > > > > ........ > > > > insert_step_resume_breakpoint_at_frame ( > > get_prev_frame (get_current_frame ())); > > } > > is somewhat newer than this bit. > > > The condition is the second code block is taken and breakpoint is indeed > > set. I have two questions: > > > > 1. Is "just stepped into ... function" comment accurate? I think that all > > cases of steppin into function are handled by the previous > > > > if (frame_id_eq (frame_unwind_id (get_current_frame ()), step_frame_id)) > > {} > > > > condition, and all code paths inside that condition end with return. So, > > the second code block is not executed when we've just stepped into a > > function. Is the code intended to handle only the case when we've > > *returned* to undebuggable function? > > It was intended to handle both. Nowadays, there's a good chance it has > handled only the latter. Ok. > > 2. In my case, no function names for assembler modules are present in > > debug info, but line information is there, so the function is debuggable. > > Is there a way to check of line info in condition, not for function name? > > You have line numbers, but not even minimal symbols? That is, ELF > symbols, not DWARF2 symbols. Exactly. ELF symbol table is absolutely empty. > That's really bizarre. Well, for a binary for embedded system with no dynamic linking this is not so unreasonable. Anyway, that's not something I can easily change. > We don't have a > good interface for handling functions with line numbers but no sym or > minsym, but perhaps we need one. I agree that the presence of line > number information seems more relevant right here. FWIW, I've just modified that code to be: ecs->sal = find_pc_line (stop_pc, 0); ....... if (step_over_calls == STEP_OVER_UNDEBUGGABLE && ecs->sal.line == 0) and it works as expected. Does the change seem reasonable? - Volodya