On 04.03.2007 [10:23:00 +1100], David Gibson wrote: > 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.
Yes, fine. My point is that we want ways to define things in an arch-specific way. In any case, this was not about tests, this was about the library arch-specific (or bit-specific things). In this case, only i.86 and ppc would need define the check_memsz() function and the others could ignore it. > > 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. Ah, that stinks. Well, I was just thinking of things in any case. None of this is *going* to happen for sure or whatever. > 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 :-(. Yep. > > 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. I agree. > > > 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. I can try it on a pure i386 box later and let you know. > > 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. Ok. > > 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. Except then the logs will get cluttered with lots of "No such file or directory", right? Because we won't build the binary or whatever. I don't really feel like I need to be remined of remaining functionality in this case. I want to make it possible to run `make func` on ia64 and sparc64, is all. As far as ia64 elflink, from what Adam mentioned on LKML, it would depend on vhpt support. > > 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. Some tests check to see if the size of the native word is 32 or 64-bit. They do nothing if it's the one they don't care about. Why bother? Just don't run the test. I guess if you're going to run the tests by hand, it might make a difference. > 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. That's a good point. I don't really care anymore. I didn't expect this to be that big of a deal, but it clearly is, so I'll drop the idea. Thanks, Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center ------------------------------------------------------------------------- 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
