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.
> > > 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.
> > 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
[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.
> 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.
> > > 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.
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.
--
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
