From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29889 invoked by alias); 14 Jun 2005 14:37:06 -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 29854 invoked by uid 22791); 14 Jun 2005 14:36:57 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 14 Jun 2005 14:36:57 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DiCX8-0000uq-1m; Tue, 14 Jun 2005 10:36:54 -0400 Date: Tue, 14 Jun 2005 14:37:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: problem debugging assembler functions Message-ID: <20050614143654.GB3288@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00131.txt.bz2 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. > 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. That's really bizarre. 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. -- Daniel Jacobowitz CodeSourcery, LLC