On Mon, Mar 05, 2007 at 11:58:00AM -0800, Nishanth Aravamudan wrote:
> 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]
> > 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?
Yeah, started working on it yesterday, will keep going today.
> > > > 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?
Heh, can I remember them. I never thought about them all that hard,
since I don't know much about ia64 and don't have easy access to one.
Um... one was to make a small kernel tweak, that when presented with
ELF segments in the hugepage region, will silently ignore them,
instead of failing the exec(). The ia64 linker script could then
place most of the segments into the hugepage region, with the
exception of some dynamic linker vital things like the PLT which
would go in their own segment in normal pages. libhugetlbfs would
have special code for ia64 that loaded the main program segments into
hugepages from scratch, instead of from existing mappings.
> > > > > 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
>
--
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
