On 08.03.2007 [16:43:03 +1100], David Gibson wrote:
> On Wed, Mar 07, 2007 at 08:29:08PM -0800, Nishanth Aravamudan wrote:
> > On 07.03.2007 [16:29:58 +1100], David Gibson wrote:
> > > Here's a revised version of my patch adding per-target syscall stubs
> > > to the library. This is now tested on x86_64.
> > >
> > > This patch adds a per-target module to the library, which can be used
> > > to hold any arch or target dependent code. It uses this module to
> > > provide a per-arch re-implementation of syscall(), which is used to
> > > (finally) provide reliable error messages from elflink.c if they occur
> > > while the program segments are unmapped.
> >
> > This does break the sparc64 and ia64 builds, btw, and I need the
>
> Um, yeah, I was kind of planning to fix that before we merged for
> real, but I'll need access to a suitable boxes.
Ok.
> > following on top. Another reason why I do prefer my original method of
> > having those variables to say we don't support something, since you're
> > now overloading the use of ELF{32,64}. Oh well.
>
> Well, yeah. After consideration, though, I thought what we're really
> doing here is per-target, rather than per-arch as such, so it seemed
> silly to invent new per-target names.
Yep.
> > I made a dummy elf64_sparc.S and am building the tests now (box is
> > slow).
>
> There should be no deep problem is getting the whole kaboodle working
> on sparc, so we should just do it: look at their default linker
> script, and whip up xB and xBDT versions. Likewise a sparc syscall
> stub, we can just copy out of libc (I wrote the stubs included already
> just by doing objdump -d on libc.a and libc.so and copying out the
> assembly for the syscall() function, leaving out the bit for frobbing
> errno.
I can probably work on this a bit. Although, I'm having trouble just
getting `make func` to run on the one sparc64 box I have access too. Not
sure if I'm killing the box, or if we're panic()'ing or what. Nothing is
showing up on the serial console, unfortunately.
> > I should also be able to try and test on ia64 tomorrow, I hope.
>
> ia64 is harder, since we can't do a linker script for it. Or, I
> suppose we could define ELF64 to point to a linker script that doesn't
> actually put anything in hugepages. Probably not a good idea, though.
Right, I meant just the functional part of the lib, excluding relinking.
> We should probably exclude elflink.o from the library on ia64 as well
> as not including any arch stub, thereby fixing the link error with
> direct_syscall().
Yep, I can make that change.
> > Note, that the the current versioning scheme resulted in an infinite
> > build loop, so I had to comment out those bits as well. Will look into
> > it more tomorrow.
>
> Hmm, odd. Whatever it was, I didn't notice it.
Sorry for the confusion, I am seeing an infinite loop on sparc period.
Not related to your patch.
> I can't actually see how the patch below would fix things - it should
> just change it from a make syntax error, to a link error trying to
> find direct_syscall().
Yep.
> I had thought about letting each arch's make stanza optionally define
> a LIBOBJS_TARGET32 and LIBOBJS_TARGET64, which would be folded into
> LIBOBJS32 and LIBOBJS64. They would default to the $(ELF32).o and
> $(ELF64).o if not explicitly given.
Hrm, yes, that may be a bit better, but I don't envision us adding more
archs than sparc and ia64 any time soon.
> > diff --git a/Makefile b/Makefile
> > index d3150ea..5103f48 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -71,8 +71,14 @@ ifdef CC64
> > OBJDIRS += obj64
> > endif
> >
> > -LIBOBJS32 = $(LIBOBJS:%=obj32/%) obj32/$(ELF32).o
> > -LIBOBJS64 = $(LIBOBJS:%=obj64/%) obj64/$(ELF64).o
> > +LIBOBJS32 = $(LIBOBJS:%=obj32/%)
> > +ifdef ELF32
> > +LIBOBJS32 += obj32/$(ELF32).o
> > +endif
> > +LIBOBJS64 = $(LIBOBJS:%=obj64/%)
> > +ifdef ELF64
> > +LIBOBJS64 += $(LIBOBJS:%=obj64/%)
>
> ^^^ This line is certainly wrong, too
Yep, this was diff'd locally, not on the sparc box itself.
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
