Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: "Hans-Peter Nilsson" <hans-peter.nilsson@axis.com>
Cc: joel.sherrill@oarcorp.com, gdb-patches@sourceware.org
Subject: Re: Recent simulator patches broke many sims
Date: Tue, 26 Mar 2013 19:49:00 -0000	[thread overview]
Message-ID: <201303261415.19076.vapier@gentoo.org> (raw)
In-Reply-To: <201303261712.r2QHCcvp013983@ignucius.se.axis.com>

[-- Attachment #1: Type: Text/Plain, Size: 2890 bytes --]

On Tuesday 26 March 2013 13:12:38 Hans-Peter Nilsson wrote:
> From: Mike Frysinger <vapier@gentoo.org>
> On Sunday 24 March 2013 19:23:28 Hans-Peter Nilsson wrote:
> > You need a board (make check RUNTESTFLAGS=--target_board=$board
> > with e.g. board=cris-sim).  All boards are in "recent"
> > dejagnu-1.5 IIRC and most in ancient dejagnu-1.4.4.  You need
> > installed binutils (e.g. in some temp location added to PATH for
> > the duration of the test-run) for each sim configuration as
> > mentioned.  I don't run with target gcc; not needed for the
> > level of smoke test I'm after and I guess not for this change
> > either.
> > 
> > that's not entirely true.  many (all but cris?)
> 
> I don't think it's different but I don't plan to test without...
> 
> > sims run &
> > pass just fine without needing to explicitly pass magic flags.
> 
> It is entirely true that when a board is specified, all work.
> 
> Now that you mention it, someone *did* do some changes to allow
> simulator tests to run without specifying a board - IIRC in some
> situations, assuming no special linker flags or such needed and
> no compiler toolchain (or no flags or libraries using simulator
> hooks).  Reading ChangeLogs it seems it was you, on 2010-04-26.

yes, that was the commit date, but i'd been using it longer than that :)

> > i know the Blackfin and frv sims can build & run pretty much
> > all their tests w/out requiring board flags.
> > 
> > imo, requiring manual board selection like this is archaic for
> > no good reason.
> 
> One good reason IMO is that when specifying a board, all
> toolchain parts test alike, rather than sim (after 2010-04-26)
> being a special case (and binutils, mostly for not needing to
> run things to avoid FAILs or hanging tests).

i see it the other way.  doing `make check` for all these packages work w/out 
the user having to dig into esoteric tools (that often times lack 
documentation, or any real semblance of an entry point).

for binutils/gcc/etc..., there are plenty of compile/link/etc... tests that 
can be done without needing to know about a board.  the sim is special in that 
testing it requires running code, so it's entirely reasonable for the default 
`make check` to setup a state where the tests actually work.

if the default `make check` for cris doesn't, then that should be fixed to 
provide a reasonable default.  if you're telling everyone "in order to test 
the cris sim, you have to use RUNTESTFLAGS=--target_board=cris-sim", then make 
that the default board already.  there's absolutely no reason to force this 
upon people who are trying to hack on the core sim and/or other sims, and want 
to verify they didn't break other sims.

for many sims, it's hard enough as it is just to try and guess the magic tuple 
that'll pass all the deprecated/enable checks.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-03-26 18:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24  0:22 Hans-Peter Nilsson
2013-03-24  0:38 ` Joel Sherrill
2013-03-24  5:39   ` Hans-Peter Nilsson
2013-03-24  5:39     ` Joel Sherrill
2013-03-24 11:04       ` Hans-Peter Nilsson
2013-03-24  2:12 ` Joel Sherrill
2013-03-24  2:35 ` Joel Sherrill
2013-03-24  2:53   ` Hans-Peter Nilsson
2013-03-24  5:22     ` Hans-Peter Nilsson
2013-03-24  5:36     ` Hans-Peter Nilsson
2013-03-24  4:51   ` Hans-Peter Nilsson
2013-03-24 11:33   ` Mike Frysinger
2013-03-25  3:30     ` Joel Sherrill
2013-03-25  3:50       ` Hans-Peter Nilsson
2013-03-25  7:39         ` Joel Sherrill
2013-03-26 17:49         ` Mike Frysinger
2013-03-26 18:41           ` Hans-Peter Nilsson
2013-03-26 18:43             ` Joel Sherrill
2013-03-26 19:49             ` Mike Frysinger [this message]
2013-03-26 20:50               ` Hans-Peter Nilsson
2013-03-26 21:24                 ` Mike Frysinger
2013-03-27  1:39                   ` Hans-Peter Nilsson
2013-03-27  9:13                     ` Mike Frysinger
2013-03-26 18:56     ` Mike Frysinger
2013-03-27  8:47       ` Joel Brobecker
2013-03-27  8:50         ` Hans-Peter Nilsson
2013-03-27 18:38           ` Joel Sherrill
2013-03-27 19:01             ` Joel Brobecker
2013-03-27 19:43             ` Joel Brobecker

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=201303261415.19076.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=gdb-patches@sourceware.org \
    --cc=hans-peter.nilsson@axis.com \
    --cc=joel.sherrill@oarcorp.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