From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <kettenis@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] New GDB target iq2000
Date: Sat, 05 Mar 2005 16:44:00 -0000 [thread overview]
Message-ID: <20050305164451.GA8398@nevyn.them.org> (raw)
In-Reply-To: <200503051128.j25BSruw007318@elgar.sibelius.xs4all.nl>
On Sat, Mar 05, 2005 at 12:28:53PM +0100, Mark Kettenis wrote:
> Date: Fri, 4 Mar 2005 17:01:04 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> I left the other function alone. skip_prologue_using_sal is already a
> bit bogus, for the reasons identified by Kevin as well as for at least
> one other that I can see. find_last_line_symbol is even boguser.
> Basically, any code that compares the LINE member of two arbitrary SALs
> _must_ be wrong. They don't even need to be in the same source file.
>
> Another issue with skip_prologue_using_sal() is that it will happily
> skip the entire function if the function body is basically empty. I
> really think it should be deprecated, and shouldn't be used in any new
> code.
Hum... so it will. I rather think it should be fixed. I have a patch
to fix the most common occurance of that, when the line notes look
like:
line1:
line2:
ret
For a compiler which doesn't use the two line note convention, of
course, it's bogus - but so is lots of the rest of GDB.
Could you explain why you think it should be deprecated? Bear in mind
that it's _new_ - it was derived from various similar things in tdep
files, in an attempt to commonize.
> There's two things that GDB uses the guessed prologue line information
> for. One is to place an initial breakpoint, so that the arguments have
> been saved. This problem will hopefully eventually go away, with
> improved GCC -fvar-tracking - we should be able to print the arguments
> from anywhere. Someone needs to spend a little love on the compiler
> side of this.
>
> The important thing about placing the initial breakpoint, is that it
> shouldn't be placed too far into the function. In particular it
> should not end up after a branch instruction.
Yes. I mentioned to Kevin off-list that I've been thinking about an
ideal paradigm for implementing both this and prologue scanners. What
we need is a common simulator architecture which can "describe" the
effects of instructions - enough instructions to handle prologues, at
least. A huge project for someday :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
next prev parent reply other threads:[~2005-03-05 16:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-22 16:35 Corinna Vinschen
2005-03-01 22:13 ` Jim Blandy
2005-03-01 22:19 ` Daniel Jacobowitz
2005-03-02 9:08 ` Corinna Vinschen
2005-03-03 17:34 ` Daniel Jacobowitz
2005-03-03 17:46 ` Kevin Buettner
2005-03-03 17:51 ` Daniel Jacobowitz
2005-03-03 19:17 ` Kevin Buettner
2005-03-04 9:46 ` Corinna Vinschen
2005-03-04 14:14 ` Daniel Jacobowitz
2005-03-04 15:01 ` Corinna Vinschen
2005-03-04 15:06 ` Daniel Jacobowitz
2005-03-04 15:51 ` Corinna Vinschen
2005-03-04 16:01 ` Daniel Jacobowitz
2005-03-04 22:01 ` Daniel Jacobowitz
2005-03-05 11:29 ` Mark Kettenis
2005-03-05 16:44 ` Daniel Jacobowitz [this message]
2005-03-05 18:13 ` Mark Kettenis
2005-03-05 19:37 ` Daniel Jacobowitz
2005-03-05 20:18 ` Mark Kettenis
2005-03-05 20:20 ` Daniel Jacobowitz
2005-03-07 10:08 ` Corinna Vinschen
2005-03-07 14:05 ` Daniel Jacobowitz
2005-03-07 20:17 ` Corinna Vinschen
2005-03-07 20:37 ` Daniel Jacobowitz
2005-03-08 9:00 ` Corinna Vinschen
2005-03-08 13:32 ` Daniel Jacobowitz
2005-03-07 21:32 ` Daniel Jacobowitz
2005-03-07 21:35 ` Daniel Jacobowitz
2005-03-08 9:00 ` Corinna Vinschen
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=20050305164451.GA8398@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@gnu.org \
/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