Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: Andreas Schwab <schwab@suse.de>, gdb-patches@sources.redhat.com
Subject: Re: ColdFire/fido support
Date: Tue, 12 Jun 2007 13:38:00 -0000	[thread overview]
Message-ID: <20070612133846.GA7815@caradoc.them.org> (raw)
In-Reply-To: <200706081458.36645.vladimir@codesourcery.com>

On Fri, Jun 08, 2007 at 02:58:36PM +0400, Vladimir Prus wrote:
> > This sets flavour partly based on the target, and partly based on the
> > object file.  That's a bit confusing - we can determine float return
> > behavior strictly from the object file, and it's only the object
> > file's behavior that matters.
> 
> Not necessary. You can connect to a stub without having a file at all,
> and you'd still want to have some coldfire-specific behaviour, for example
> this:
> 
> 	 if (flavour == m68k_coldfire_flavour || flavour == m68k_fido_flavour)
> 	    set_gdbarch_decr_pc_after_break (gdbarch, 2);
> 
> if you determine flavour based solely on file, then if you connect to a stub
> without having any file at all, no flavour will be detected, and breakpoints won't
> work correctly.
> 
> I suppose I can add file-based detection for fido, just like it's done for coldfire,
> but I don't think removing XML-based detection is right. What do you think?

Right, sorry - I know what I meant to say, but I didn't say it.

Float return behavior is not a property of the target at all; it's a
property of the compiler options used.  decr_pc_after_break is a
target property, though, so we should trust the target.  This isn't
important, though, so feel free to commit without changing this.  If
it causes any problems we can clean it up later.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2007-06-12 13:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-05  9:37 Vladimir Prus
2007-05-05 11:02 ` Andreas Schwab
2007-05-06 11:52   ` Vladimir Prus
2007-05-28 11:43     ` Vladimir Prus
2007-06-05 15:19       ` Daniel Jacobowitz
2007-06-08 10:58         ` Vladimir Prus
2007-06-12 13:38           ` Daniel Jacobowitz [this message]
2007-06-15 10:17             ` Vladimir Prus
2007-06-15 14:47               ` Daniel Jacobowitz
2007-06-15 19:05                 ` Vladimir Prus
2007-06-16 10:21                   ` Eli Zaretskii
2007-06-19 16:39                     ` Vladimir Prus
2007-06-19 16:53                       ` Eli Zaretskii
2007-06-19 17:10                         ` Daniel Jacobowitz
2007-06-19 18:00                           ` Eli Zaretskii
2007-06-20  9:14                             ` Vladimir Prus
2007-06-20 18:15                               ` Eli Zaretskii
2007-06-30 15:47       ` Andreas Schwab
2007-06-30 16:00         ` 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=20070612133846.GA7815@caradoc.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=schwab@suse.de \
    --cc=vladimir@codesourcery.com \
    /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