On 06.03.2007 [11:54:04 +1100], David Gibson wrote: > 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.
Great, thanks. > > > > > 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. Yep, I'm hoping to get access to an ia64 box with a lot of memory soon. > 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. Interesting, sounds like something to build on. 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
