On  Thu, 6 Nov 1997 08:27:31 -0800 (PST),
   "Eduardo E. Horvath" <eeh@one-o.com> writes:

[elf32 vs 3elf64]

>At the moment I'm just interested in 32-bit ABI compliant programs in the
>elf64 object file format.  GCC is not capable of generating SPARC v9
>executables without a major overhaul.

I still can't follow this. If you want 32-bit API compliant programs,
you neither need nor have use for elf64.  Trust me. I looked at this
for mips, where gcc and the toolchain *CAN* generate 64-bit mips3
elf64 binaries.  I can't do anything useful with elf64 binaries on a
mips3 CPU until the kernel (the mips pmap) supports 64-bit virtual
addressing.

Trying to fudge 64-bit registers and 32-bit pointers runs into all
sorts of hairy problems: compilers don't properly support it. You run
into sign-extension problems with offsets and immeidate integers.  The
intial stack addresses can end up sign-extended so the high-order 32
bits are all 1s.  And so on.

I think if you want 32-bit ABI compliant programs that can be exec'ed
by the existing NetBSD kernel support for ELF, then with current
compilers, you want elf32.  Period.  (I'll assume elf32 for now,
rather than correcting it each time.  But if you *do* have a 64-bit
Sparc pmap, then go with elf64.  Kernels are another story again.)

>I have EXEC_ELF32 and EXEC_ELF64 in the kernel already (I think).  To a 
>certain extent it's the standard cross-compilation problem, but with a
>funny twist.  The quiestions I have are:
>
>        How does an a.out32 userland live with an elf64 userland?

elf32 vs elf64 doesn't matter here. Either way, the answer is, ``It
Just Works'', __as long as you keep all the shared libraries
distinct__.

You could link all ELF binaries as statically linked (no elf .so files
to confuse ld.so) or you allocate different major version numbers,
even for a.out and odd for elf, or play LD_LIBRARY_PATH games, or some
such.

>        Is there a need for an `/emul/NetBSD-elf64' or such tree?

You do not *need* it.  These are native NetBSD ELF binaries. a native
Netbsd filesystem namespace and syscall vector is fine. (64-bit
binaries might want their own syscall vector, but that's
format-neutral: a 64-bit syscall table and traphanlder would work for
both 64-bit a.out binaries aned 64-bit ELF binaries.  The pmax has a
single syscall table for 32-bit a.out and 32-bit elf.  The libc
assembly-code glue hides all this from the object format.

You might *choose* to use an /emul/NetBSD-elf32, if that's the best
way to keep your elf32 and a,out libraries distinct.

If you do this, though, you need to add an emul package to exec
`native' ELF binaries and do the correct path prefixing.  At some
point presumably you'd want to switch over to having ELF native, and
a.out in an `emul' directory.  Using /emul to keep shared-libs
separate *is* a nice idea, though-- wish I'd thought of it.


>        If there is one toolchain for a.out32 and another for elf64, and
>        build process generates executables to generate source files to
>        generate object files, how do you run the correct toolchain for
>        the appropriate phase of the build?

Sorry? This is a standard compiler-bootstrapping problem.  Call what
we ship, a.out binaries producing a.out, stage0.  You use that to
build stage1, a.out-format cc1/as/ld/nm/ranlib binaries that produce
elf32 code.  call that stage1.  you install stage1 and you can compile
a full elf userland -- including an elf-producing toolchain in elf.
call that stage2. If you're really cautious, compile again to get
stage3, and check stage2 and stage3 are bit-for-bit identical.

Are you asking how to configure a toolchain to *do* that?

With GNU binutils, it's relatively easy: run `ocnfigure' in a binutils
source tree.  Our gcc is a *lot* harder; talk to the people who
`integrated' it without keeping the machinery to build
cross-compilers.  Perhaps the simplest thing is to copy all the
locally-changed source files from our gcc source (common, cc1) over
their equivalents in a 2.7.2.2 tree, and do a GNU configure there.

Then again, maybe you don't need any of the changes in our tree for
sparc.

>        What needs to be re-written?  There's libkvm, gdb, as, and ld that
>        need to be done to get off the ground.  ldd, gcc, and nm can come
>        later, I think.  What else?

Sorry, I don't understand.  Rewrite *what*?  Binutils already comes
with support for sparc elf32, doesn't it?.

Are you talking about the years-out-of-date, orphaned, binutils
derived toolchain source code in the NetBSD tree?  If you are, I'd
suggest ignoring it (and throwing it away if/when all ports use elf).
It's still copylefted, and why try and reverse-engineer a copylefted
version five years of development that's *already* in the current
binutils?

>Oh, yeah, and my favorite:

>        Can libkvm be built to handle both a.out and elf formats?
>        Especially since by convention a.out prepends underscores in front
>        of labels and elf doesn't?

Yes, and yes.  Thanks to CGD, the underscore issue is a solved
problem. It's already been used to support both ecoff and elf on
alphas.  And I think pmaxes use all three of elf, a.out, and ecoff.

The a.out to elf transition is hairy But the Alpha has already done
ECOFF to elf, and the pmax has done non-shared a.out to elf.  Those
problems are largely solved.

I'd guess there's a lot *more* problems in a 32-bit to 64-bit
transition, and supporting both 32-bit mode and 64-bit mode processes
in a single ekrnel.  But that's really independent of what object-file
format is being used.  I'd be very pleasantly surprised if we have VM
and pmap code ready to handle that.  Do we?  (if so, I'd like to use
it on mips boxes!)