From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31105 invoked by alias); 14 Jun 2005 15:19:43 -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 31001 invoked by uid 22791); 14 Jun 2005 15:19:29 -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 15:19:29 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1DiDCI-0006pU-9U for gdb@sources.redhat.com; Tue, 14 Jun 2005 19:19:26 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1DiDCF-0006oU-7Z; Tue, 14 Jun 2005 19:19:23 +0400 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: problem debugging assembler functions Date: Tue, 14 Jun 2005 15:19:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <200506141854.04712.ghost@cs.msu.su> <20050614145808.GA4100@nevyn.them.org> In-Reply-To: <20050614145808.GA4100@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506141919.22749.ghost@cs.msu.su> X-SW-Source: 2005-06/txt/msg00135.txt.bz2 On Tuesday 14 June 2005 18:58, Daniel Jacobowitz wrote: > On Tue, Jun 14, 2005 at 06:54:03PM +0400, Vladimir Prus wrote: > > > > 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. > > Not having dynamic symbols, sure, that's perfectly reasonable. Those > go into target memory. But this is far from the only thing in GDB that > is not going to work without a static symbol table! For instance, you > can't use prologue analysis. You'll never find the start of any > function. Do you mean prologue analysis for assembler modules? For C++ modules DWARF2 info contains everything. Well, I don't need to analyse prologue for assembler modules at all, because if I understand correctly it's only needed to proper unwind stack, and I have a much better way for stack unwinding. My target is actually a simulator, so I just store register values on each call instruction and can fetch them via extended version of "get registers" remote protocol command. > > > 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? > > I'm not thrilled with adding another lookup here; this code executes > quite a few times when stepping. The current code looks like: if (step_over_calls == STEP_OVER_UNDEBUGGABLE && ecs->stop_func_name == NULL { } if (step_range_end == 1) { /* It is stepi or nexti. ... return; } ecs->sal = find_pc_line(stop_pc, 0) So, moving 'find_pc_line' above will reasult in extra lookup only if - the command is stepi/nexti, or - the first condition evaluates to true (which means we've entered undebuggable code) I have no idea is that's bad or not performance-wise, just clarifying what's going on. > It does seem plausible, but it would > need wider testing. Ok. - Volodya