On 05.03.2007 [15:35:05 +1100], David Gibson wrote: > On Sat, Mar 03, 2007 at 09:44:31PM -0800, Nishanth Aravamudan wrote: > > 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. > > Right. I only just looked at the check_memsz() stuff properly. I > have some comments in a separate mail. In summary, there are some > problems with the current check_memsz() implementation, and fixing > them may make the wordsize-specificness issue moot.
True. > > > > 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. > > But... I've just thought some more. And I think we can work around > this problem with similar linker tricks to the ones I was using when I > had the syscall()-statically-linked-from-libc almost working. But now > that we'll be compiling the arch specific code in question with -fPIC > ourselves, the problems that arose there should be gone. Ok, are you going to spin up some patches then? > > > 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. > > Yes, I think it's time to bite the bullet and include our own per-arch > syscall() asm stub. We can link that in using the same method I was > trying to pull syscall() in from libc. Then we'd finally have > reliable error messages from the twilight zone, and we can use the > same place to put any other per-arch include any other per-arch code > we need Sounds good to me. > [snip] > > > 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. > > Ah, yes, I guess so. Which make me think of what might be an easier > way of skipping sets of tests. What if we make the run_test() shell > function check if the requested test binary is present, and if it's > not print a new status, say MISSING, instead of PASS or FAIL. Yeah, that sounds sane to me. I'll spin up a patch for this. > > 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. > > Er.. perhaps. Certainly to allow doing elflink as we currently do > would need vhpt support. I did have some thoughts for some hacks > which might allow us to get it more-or-less working even with the > current address space restriction. Ok, care to share? > > > > 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. > > As far as I can tell, the only tests that do such a check are > 'straddle_4GB', 'huge_at_4GB_normal_below' and > 'huge_below_4GB_normal_above'. These are *already* only built and run > on 64-bit systems, the run-time pointer checks are just paranoia (and, > I guess, internal documentation). In the latter two we should > probably get rid of the rather silly IRRELEVANT() macro and just use > TEST_BUG() as in straddle_4GB. Ok. > If we exported the slice_begin()/slice_end() functions (might want to > think harder about the names, before doing so), we could get rid 2 of > the 3 explicit arch dependencies in the tests, from brk_near_huge and > truncate_above_4GB. The slice helpers have been merged up (Adam hopefully will pull my local tree today or tomorrow) but are not exported. 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
