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.
> 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.
> 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 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.
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().
> 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.
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().
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.
> 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
> +endif
>
>
> LIBDIR32 = $(PREFIX)/$(LIB32)
>
--
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
