Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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