Re: Patch, sim: fix m68hc11 and iq2000 testsuites using dejagnu baseboard files

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On 07 Apr 2015 05:59, Hans-Peter Nilsson wrote:
> > From: Mike Frysinger <vapier@gentoo.org>
> > Date: Tue, 7 Apr 2015 04:58:22 +0200
> 
> > odd, it's working for me.  what is different about your environment ?  i'm just 
> > doing `make sim-check`.
> 
> This is old. :)  You never specify the dejagnu sim baseboards
> (defaulting to "unix.exp" the native one), while I do; see
> the subject.  I.e. you never pass
> RUNTESTFLAGS=--target_board=iq2000-sim etc.  Let's no argue
> about the validity of doing either: the simulator is at such a
> low level that its test-suite can be argued to know how to build
> simple programs for itself, but it should also not have to have
> a different baseboard required than the rest of a unified-tree
> (aka. uberbaum) setup.  (Not that iq2000-elf nor m68hc11 appear
> to have actively maintained toolchains...)

i'm not trying to say you're flow is wrong.  i'm merely asking how it differs 
from my own.

> > i really don't want the sim to get into the business of fighting dejagnu over 
> > what a sane environment looks like.
> 
> Too late.
> 
> >  but i also don't want to start sprinkling 
> > this logic over all targets.  so moving the existing mips logic to run_sim_test 
> > in lib/sim-defs.exp seems like the least worse option to me.
> 
> And that's what I referred to as the "too smart" alternative of
> moving it do run_sim_test (I did have a quick look).  Better
> keep it target-specific, as it's the specific target board file
> that's "broken" (besides the "-Wl,"-stripping).  If those
> targets change in level of activity, I expect the ldscript
> business to be fixed too.

the sim is not board specific, nor does the testsuite (generally) care about the 
C library.  it certainly is not a test ground for making sure newlib/libgloss 
itself is bug free (that's what testsuites in those projects are for).  that 
leads me to the opinion that board-specific linkage information does not make 
sense in the sim so we should simply clear it for all targets.  in fact, we want 
the sim to be board agnostic (ignoring the model support, and tests that 
exercise those models directly, but is still orthogonal to dejagnu setup).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]