From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb@sources.redhat.com
Subject: Re: problem debugging assembler functions
Date: Tue, 14 Jun 2005 14:58:00 -0000 [thread overview]
Message-ID: <20050614145808.GA4100@nevyn.them.org> (raw)
In-Reply-To: <200506141854.04712.ghost@cs.msu.su>
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.
> > 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. It does seem plausible, but it would
need wider testing.
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-06-14 14:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-14 9:23 Vladimir Prus
2005-06-14 14:37 ` Daniel Jacobowitz
2005-06-14 14:54 ` Vladimir Prus
2005-06-14 14:58 ` Daniel Jacobowitz [this message]
2005-06-14 15:19 ` Vladimir Prus
2005-06-14 15:27 ` Daniel Jacobowitz
2005-07-14 8:54 ` Vladimir Prus
2005-07-14 14:11 ` Daniel Jacobowitz
2005-07-14 14:08 ` Vladimir Prus
2005-07-14 14:11 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050614145808.GA4100@nevyn.them.org \
--to=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox