On Sat, Mar 03, 2007 at 01:38:52PM -0800, Nishanth Aravamudan wrote:
> On 03.03.2007 [17:44:48 +1100], David Gibson wrote:
> > On Fri, Mar 02, 2007 at 05:14:14PM -0800, Nishanth Aravamudan wrote:
> > [snip]
> > > Independent of this patch, I'm starting to feel like we could maybe do a
> > > better job of abstracting out the arch-specific bits of the library
> >
> > Perhaps. We could add a per-arch .o file which could override weak
> > default versions of functions easily enough. Although, in the library
> > proper, as I recall, the granularity/slice stuff is basically the only
> > arch dependency and it's not that bad.
>
> Well, the 32-bit apps running out of address space would be i386/ppc
> specific,
32 or 64 bit specific is a different question from arch specific. We
already have some things to restrict 64-bit only tests.
> as well as the i386 _syscall rewrites. And if we add ia64 and
> sparc64 support, maybe others.
Yeah, the syscall stuff is an issue. We might need an arch specific
thing there - except in that case I don't think we can put it in a
separate .o, since it needs to be local to elflink.o for the linking
to work properly while we're in the twilight zone.
I'm still kind of bummed that the link-to-syscall()-statically idea
didn't quite work. If only the distros included a libc_pic.a :-(.
> I'm also looking into a general cleanup/reorg of elflink.c, as it has
> grown quite a bit lately (and will be larger in 1.2) and probably could
> be better organized from a logic perspective.
>
> > > (including some tests which only really have meaning (or even run!)
> > > on power, for instance). Would people be opposed to perhaps a little
> > > bit of a reorg, where we have arch-specific hooks for some things,
> > > which maybe default defined to no-ops. And then a bit of a reoorg of
> > > run_tests.sh to have a base set of tests run on all archs, and then
> > > add to those, the arch-specific tests?
> >
> > On the tests I strongly disagree. Some of the tests were designed to
> > pick up arch specific bugs, but they're all written so that they
> > should pass (perhaps trivially) on any arch.
>
> See below, that's not the case currently.
Ok. That's a bug then, and should be fixed.
> > Most of the tests are pretty quick to run, so I don't see that there's
> > any case where more tests aren't better, even if some are fairly
> > unlikely to pick anything up except on a particular arch.
>
> Well, icache-hygience 32-bit results in:
>
> icache-hygeine (32): ./run_tests.sh: line 34: 3905 Segmentation fault
> PATH="obj$BITS:$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../obj$BITS" $ENV
> "$@"
>
> on x86_64, which is plain ugly to see in an otherwise successful run.
Ouch, yes, we need to fix that. Hmm.. that test is supposed to work
on i386. So is the problem that a) it really doesn't work on i386
either, b) we're not building the 32-bit version correctly on x86_64,
or c) we're hitting some subtle incompatibility between real i386 and
x86_64 32-bit mode.
> And slbpacaflush and icache-hygiene have no utility on coherent icache &
> dcache machines. Then a handful of tests only have meaning on 32-bit or
> 64-bit archs.
Again, they can't pick up the thing they were specifically designed
for on other systems, but they're a few more contortions which have a
chance of picking up something.
> I am ok with pushing some of this stuff into the tests
> themselves (and I think the 32-bit specific ones do checks), however, I
> guess.
>
> More importantly, adding sparc64 and ia64 support, we want a way to skip
> the tests which we don't support yet, in run_tests.sh. This grouping
> provides a nice way to do that.
Hrm. In some ways I'd prefer to leave the tests we don't support yet
in, as a reminder that we have functionality still to implement. ia64
is a special case there, of course, since it's hard to see how to
implement the elflink stuff at all.
> Regardless, I can modify my patch to only conditionalize this last part.
> That is, only run relink & morecore tests for supported archs for now.
> Would that be ok by you?
>
> > Even if it's genuinely impossible to hit the specific bugs on other
> > archs, the greater the variety of peculiar things we do in the
> > testsuite, the better our chances are of picking up some new bug for
> > which we don't have a specific testcase.
>
> Oh, I'm not trying to argue against this. But it seems like if a test is
> trivially going to succed, why clutter the run-time logs with (arguably
> false) successes? They succeeded, yes, but only because they did
> nothing. So just don't run it.
Well, no, mostly they don't do nothing. They do something, there's
just no reason to suspect it might fail on anything except a
particular arch.
In any case, passing cases are kind of noise by defintion. The
testsuite is going to grow, whatever we do, so there will always be a
bunch of this noise. I don't see there's much point pruning out a
handful of them per-arch. It would also make using diff trickier to
compare how we were doing on one arch versus another.
> This would only apply to arch-specific bugs, of course. We run the basic
> functional tests regardless.
>
> Thanks,
> Nish
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
