I have been working on a project to create a Pure 64 bit distro of
linux, nothing 32 bit in the system. I can accomplish that with no
issues pretty much on all platforms, with the exception of the
bootloaders. It just seems odd, that all the bootloaders seem to have
gcc -m32 in their makefiles.
Silo on the Sparc has gcc -m32
Grub on the x86 platforms has gcc -m32
The only one that builds and works is Lilo, which most people are moving
away from.
So for my question, why does a bootloader have to be 32bit?
Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
Are there technical limitations that bootloaders can't be 64 bit?
If we can't have a pure64 environment, why does the Kernel support it?
Thank you all for taking you time to respond.
--
----
Jim Gifford
[email protected]
On Sat, Sep 10, 2005 at 12:42:06AM -0700, Jim Gifford wrote:
> I have been working on a project to create a Pure 64 bit distro of
> linux, nothing 32 bit in the system. I can accomplish that with no
> issues pretty much on all platforms, with the exception of the
> bootloaders. It just seems odd, that all the bootloaders seem to have
> gcc -m32 in their makefiles.
>
> Silo on the Sparc has gcc -m32
> Grub on the x86 platforms has gcc -m32
>
> The only one that builds and works is Lilo, which most people are moving
> away from.
>
> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
> Are there technical limitations that bootloaders can't be 64 bit?
> If we can't have a pure64 environment, why does the Kernel support it?
It depends on the mode the CPU is in, at boot time. Also, there are size
constraints, as 64-bit code is usually larger.
There's nothing stopping you from writing a bootloader that immediately
put the CPU into 64-bit mode, and then proceeds from there...
Jeff
From: Jim Gifford <[email protected]>
Date: Sat, 10 Sep 2005 00:42:06 -0700
> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
You can make SILO 64-bit, but it would just be a lot
of work and would just result in a SILO that, unlike
current SILO, would only work on UltraSPARC machines.
32-bit SILO, on the other hand, can work on any Sparc system.
There really is no advantage, and known disadvantages, to
making SILO 64-bit.
Jim Gifford <[email protected]> writes:
> I have been working on a project to create a Pure 64 bit distro of
> linux, nothing 32 bit in the system. I can accomplish that with no
Hopefully you're using /lib64 for that, otherwise your
packages will be incompatible to everybody else and not
FHS compliant. If you don't please don't submit any
patches to hardcode this to upstream packages.
> issues pretty much on all platforms, with the exception of the
> bootloaders. It just seems odd, that all the bootloaders seem to have
> gcc -m32 in their makefiles.
Not only the boot loaders, but the kernel needs a -m32
compilers/toolset to build the bzImage unpacker. There were some plans
to change that, but it hasn't happened so far.
>
> Silo on the Sparc has gcc -m32
> Grub on the x86 platforms has gcc -m32
> The only one that builds and works is Lilo, which most people are
> moving away from.
>
> So for my question, why does a bootloader have to be 32bit?
> Anyone got 64 bit bootloaders for Sparc or x86_64 machines?
kexec is essentially a 64bit boot loader, but you need
linux running before so it has a little bootstrap problem.
I believe the folks at http://www.codegen.com got one too, but
it's proprietary.
The problem is that there is currently no defined protocol
for passing data to the 64bit part of the kernel, so while
it would be possible to write a boot loader that starts
a 64bit kernel it would be very kernel version dependent.
-Andi
Andi Kleen wrote:
> Jim Gifford <[email protected]> writes:
>
>
>>I have been working on a project to create a Pure 64 bit distro of
>>linux, nothing 32 bit in the system. I can accomplish that with no
>
>
> Hopefully you're using /lib64 for that, otherwise your
> packages will be incompatible to everybody else and not
> FHS compliant. If you don't please don't submit any
> patches to hardcode this to upstream packages.
/lib64 is an awful scheme. I'd avoid it.
Consider what happens in the existing scenario where you have capability
to run both IA64 and x86-64 binaries on the same system.
> The problem is that there is currently no defined protocol
> for passing data to the 64bit part of the kernel, so while
> it would be possible to write a boot loader that starts
> a 64bit kernel it would be very kernel version dependent.
Good point.
Jeff
On Sat, Sep 10, 2005 at 04:39:00AM -0400, Jeff Garzik wrote:
> /lib64 is an awful scheme. I'd avoid it.
I'd like to see people move away from it before it gets too entrenched
too.
What does ppc64 and sparc64 use btw?
From: Chris Wedgwood <[email protected]>
Date: Sat, 10 Sep 2005 09:34:46 -0700
> On Sat, Sep 10, 2005 at 04:39:00AM -0400, Jeff Garzik wrote:
>
> > /lib64 is an awful scheme. I'd avoid it.
>
> I'd like to see people move away from it before it gets too entrenched
> too.
>
> What does ppc64 and sparc64 use btw?
The same.
Jeff Garzik wrote:
> Andi Kleen wrote:
>
>> Jim Gifford <[email protected]> writes:
>>
>>
>>> I have been working on a project to create a Pure 64 bit distro of
>>> linux, nothing 32 bit in the system. I can accomplish that with no
>>
>>
>>
>> Hopefully you're using /lib64 for that, otherwise your
>> packages will be incompatible to everybody else and not FHS compliant.
>> If you don't please don't submit any patches to hardcode this to
>> upstream packages.
>
>
> /lib64 is an awful scheme. I'd avoid it.
>
Indeed. It just helps to keep unclean 32bit applications
alive.
Maybe you would like to check Debian for amd64? The 32bit
stuff is purely optional (except for the boot loaders, AFAIK).
http://www.debian.org/ports/amd64/
Regards
Harri
* Andi Kleen ([email protected]) wrote:
> Jim Gifford <[email protected]> writes:
> > I have been working on a project to create a Pure 64 bit distro of
> > linux, nothing 32 bit in the system. I can accomplish that with no
>
> Hopefully you're using /lib64 for that, otherwise your
> packages will be incompatible to everybody else and not
> FHS compliant. If you don't please don't submit any
> patches to hardcode this to upstream packages.
/lib64 sucks, as mentioned, and I thought FHS only required that the
linker be in /lib64. Thus, the actual libraries could be pretty much
anywhere (as it should be, really). Debian-amd64 uses a symlink from
/lib64 to /lib and provides the 64bit libraries and linker in /lib (but
when actually compiling does link binaries through /lib64 for FHS
compliance).
Hopefully /lib64, et al, will die and multiarch will happen soon.
Thanks,
Stephen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
>>Jim Gifford <[email protected]> writes:
>>
>>>I have been working on a project to create a Pure 64 bit distro of
>>>linux, nothing 32 bit in the system. I can accomplish that with no
>>
>>Hopefully you're using /lib64 for that, otherwise your
>>packages will be incompatible to everybody else and not
>>FHS compliant. If you don't please don't submit any
>>patches to hardcode this to upstream packages.
>
>
> /lib64 sucks, as mentioned, and I thought FHS only required that the
> linker be in /lib64. Thus, the actual libraries could be pretty much
> anywhere (as it should be, really). Debian-amd64 uses a symlink from
> /lib64 to /lib and provides the 64bit libraries and linker in /lib (but
> when actually compiling does link binaries through /lib64 for FHS
> compliance).
>
> Hopefully /lib64, et al, will die and multiarch will happen soon.
How exactly would multiarch support work then?
// Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDJDvcBrn2kJu9P78RAk9/AJ9KkdDxnqQmRSonntRZBqONlMH2pgCfQpH/
FDhtQSwqDrBzrQUb6/5YeOs=
=fEv6
-----END PGP SIGNATURE-----
David S. Miller wrote:
>You can make SILO 64-bit, but it would just be a lot
>of work and would just result in a SILO that, unlike
>current SILO, would only work on UltraSPARC machines.
>
>There really is no advantage, and known disadvantages, to
>making SILO 64-bit.
>
>
If I have a system that is a Pure64 environment, I try to compile Silo,
it will not function. Since there is no support for 32 bit, how would I
be able to use it.
Isn't there a way to compile the programs necessary as 64bit but the
actual mbr or .b files depending on your architecture be 32 bit. I
In the case of Silo, it compiles, but when you run silo -f, when you
reboot, it Starts Silo, then gives, Program Terminiated in OBP. Which
now makes the computer useless, unless you have a 32 bit build of silo
standing around.
Also in the case of Silo, if you try to compile it on a modern tool
chain, the .b files it generates don't work, which I have reported
upstream. Modern toolchain = binutils 2.16.1, gcc 3.4.4, and glibc 2.3.5.
For the Sparc64 builds, I'm starting to look at using OBP to do the booting.
--
----
Jim Gifford
[email protected]
From: Jim Gifford <[email protected]>
Date: Sun, 11 Sep 2005 09:33:26 -0700
> David S. Miller wrote:
>
> >You can make SILO 64-bit, but it would just be a lot
> >of work and would just result in a SILO that, unlike
> >current SILO, would only work on UltraSPARC machines.
> >
> >There really is no advantage, and known disadvantages, to
> >making SILO 64-bit.
> >
>
> If I have a system that is a Pure64 environment, I try to compile Silo,
> it will not function. Since there is no support for 32 bit, how would I
> be able to use it.
You'll need some minimal 32-bit libraries sitting around in order
to build it, sorry.
For performance reasons alone I would _never_ condone a purely
64-bit userland. It's simply a total lose from a performance
perspective, unlike some other platforms such as amd64 which
eradicate most of the 64-bit performance loss due to the gain
in available cpu registers compared to 32-bit x86.
From: Jim Gifford <[email protected]>
Date: Sun, 11 Sep 2005 09:33:26 -0700
> For the Sparc64 builds, I'm starting to look at using OBP to do the booting.
OBP cannot boot because it doesn't understand the ext2
filesystem, and therefore cannot get at the image.
The only thing you can do is netboot kernel images converted
to a.out format using the elf2aout tool.
Stop fighting city hall and work on fixing SILO to support
a 64-bit build if you want, instead of all of these hacks.
:-)
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Harald Dunkel
> Sent: Saturday, September 10, 2005 1:31 PM
> To: Jim Gifford
> Cc: Jeff Garzik; Andi Kleen; [email protected]
> Subject: Re: Pure 64 bootloaders
>
> >
> >
> > /lib64 is an awful scheme. I'd avoid it.
> >
>
> Indeed. It just helps to keep unclean 32bit applications alive.
>
Reality is that it is difficulty to remove the older junk.
I guess I see 5 choices:
#1:
Use lib for whatever the standard os/arch size is.
Use lib32 for the non-standard size.
#2:
Continue the current mess.
#3:
Use both lib32 and lib64 and maybe put a link from lib to the
default one, probably lib64.
#4:
Use both lib32 and lib64 and don't put a link.
#5:
Designate the bit size in the name of the lib, ie libc.so64 or
libc.so32 or something similar and put them all in the same
directory and let the lib loading code take care of finding the
correct size.
#5 would seem to be the most robust and simplest to administer,
and the most obvious, and the easiest to modify if something like
this was to happen again.
Who came up with lib64? I thought I first saw it either on a
irix 6 machine or a early solaris 2.x machine.
Roger
> Maybe you would like to check Debian for amd64? The 32bit
> stuff is purely optional (except for the boot loaders, AFAIK).
>
> http://www.debian.org/ports/amd64/
>
>
> Regards
>
> Harri
>
Chris Wedgwood wrote:
>> /lib64 is an awful scheme. I'd avoid it.
> I'd like to see people move away from it before it gets too entrenched
> too.
agreed -- as far as i'm concerned the 32 bit libraries are there for
compatibility's sake and should be in /lib/compat/<subarch> instead of
/lib. the native libraries should be in /lib instead of /lib64. lib64
should just go away!
but then again, nobody asked for *my* input before this fhs spec came
out, so ...
-kelsey
From: Joe Bob Spamtest <[email protected]>
Date: Mon, 12 Sep 2005 14:32:05 -0700
> Chris Wedgwood wrote:
> >> /lib64 is an awful scheme. I'd avoid it.
> > I'd like to see people move away from it before it gets too entrenched
> > too.
>
> agreed -- as far as i'm concerned the 32 bit libraries are there for
> compatibility's sake and should be in /lib/compat/<subarch> instead of
> /lib. the native libraries should be in /lib instead of /lib64. lib64
> should just go away!
64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
32-bit is the default and most desirable userland binary format on
sparc64 for example. So 32-bit programs on sparc64 are as "native" as
64-bit ones might be considered.
David S. Miller wrote:
>>agreed -- as far as i'm concerned the 32 bit libraries are there for
>>compatibility's sake and should be in /lib/compat/<subarch> instead of
>>/lib. the native libraries should be in /lib instead of /lib64. lib64
>>should just go away!
>
> 64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
> 32-bit is the default and most desirable userland binary format on
> sparc64 for example. So 32-bit programs on sparc64 are as "native" as
> 64-bit ones might be considered.
that's true, i had forgotten about the sparc64 case. it really does slow
down tremendously when used in pure 64 bit mode
i would imagine this not to be the case for most architectures though.
possibly hppa is the same way. anyone with mips64 and ppc64 hardware out
there have any input?
From: Joe Bob Spamtest <[email protected]>
Date: Mon, 12 Sep 2005 15:02:03 -0700
> David S. Miller wrote:
> >>agreed -- as far as i'm concerned the 32 bit libraries are there for
> >>compatibility's sake and should be in /lib/compat/<subarch> instead of
> >>/lib. the native libraries should be in /lib instead of /lib64. lib64
> >>should just go away!
> >
> > 64-bit isn't any more "native" than 32-bit on some 64-bit platforms.
> > 32-bit is the default and most desirable userland binary format on
> > sparc64 for example. So 32-bit programs on sparc64 are as "native" as
> > 64-bit ones might be considered.
>
> that's true, i had forgotten about the sparc64 case. it really does slow
> down tremendously when used in pure 64 bit mode
PPC64 is the same, as well as a few others are likely to
be in this boat as well. The only known exception where
64-bit is a true win is x86_64.
> i would imagine this not to be the case for most architectures though.
> possibly hppa is the same way. anyone with mips64 and ppc64 hardware out
> there have any input?
See above.
David S. Miller wrote:
> PPC64 is the same, as well as a few others are likely to
> be in this boat as well. The only known exception where
> 64-bit is a true win is x86_64.
ia64 runs terrible in 32 bit mode. but i suppose that because
of the nature of ia64 it's really doing emulation anyways.
either way, ia64 was a big disappointment to just about everyone.
On Mon, Sep 12, 2005 at 04:09:01PM -0700, Joe Bob Spamtest wrote:
> ia64 runs terrible in 32 bit mode. but i suppose that because
> of the nature of ia64 it's really doing emulation anyways.
> either way, ia64 was a big disappointment to just about everyone.
ia64 also wasn't an extension on an existing 32bit design the way sparc,
ppc, mips and x86_64 have done.
Is the alpha also pure 64bit?
Of course mips is extra fun in having two 32bit formats and one 64bit
format.
Len Sorensen
Lennart Sorensen wrote:
> ia64 also wasn't an extension on an existing 32bit design the way sparc,
> ppc, mips and x86_64 have done.
yeah, the only differene here is that x86_64 performs a hell of a lot
better in 99% of cases where a 32 bit compile performs next to a 64 bit
compile. In the case of the other architectures the 64 bit modes are
extensions of sorts, used for scientific and/or large calculations which
benefit from 64-bit datatypes and transactions.
> Is the alpha also pure 64bit?
Alpha was designed 64-bit from the start. DEC did a lot of neat things
with the design of that processor -- it's a shame it went the way of the
dodo when ia64 was proposed.
> Of course mips is extra fun in having two 32bit formats and one 64bit
> format.
Fun stuff. Another good architecture that bit the ia64 bug and got
stung.
On Mon, Sep 12, 2005 at 09:50:20AM -0500, Roger Heflin wrote:
> I guess I see 5 choices:
6.
> #1:
> Use lib for whatever the standard os/arch size is.
>
> Use lib32 for the non-standard size.
And what happens for machines with more than one 32 and one 64bit ABI?
> #2:
> Continue the current mess.
>
> #3:
> Use both lib32 and lib64 and maybe put a link from lib to the
> default one, probably lib64.
>
> #4:
> Use both lib32 and lib64 and don't put a link.
>
> #5:
> Designate the bit size in the name of the lib, ie libc.so64 or
> libc.so32 or something similar and put them all in the same
> directory and let the lib loading code take care of finding the
> correct size.
#6:
Use /lib/$arch-$os or similar and forgot about /lib/*.so.
Bastian
--
Beam me up, Scotty! It ate my phaser!
On Tue, 13 Sep 2005, Lennart Sorensen wrote:
> Of course mips is extra fun in having two 32bit formats and one 64bit
> format.
The reverse -- two 64-bit formats and one 32-bit one. And don't forget
to multiply by two endiannesses. ;-)
Maciej
On Tue, Sep 13, 2005 at 06:21:23PM +0100, Maciej W. Rozycki wrote:
> On Tue, 13 Sep 2005, Lennart Sorensen wrote:
>
> > Of course mips is extra fun in having two 32bit formats and one 64bit
> > format.
>
> The reverse -- two 64-bit formats and one 32-bit one. And don't forget
> to multiply by two endiannesses. ;-)
I thought it was 32bit old, 32bit new (for using 32bit pointers on a 64bit
cpu) and 64bit. At least the names I have seen were 32o, 32n, 64.
Len Sorensen
On Sep 13, 2005, at 13:00:16, Joe Bob Spamtest wrote:
>> Is the alpha also pure 64bit?
>
> Alpha was designed 64-bit from the start. DEC did a lot of neat
> things with the design of that processor -- it's a shame it went
> the way of the dodo when ia64 was proposed.
PowerPC was designed 64-bit from the start too! It's just that the
architecture design group also realized that there would be a demand
for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32-
bit system whose entire instruction set would be forward-compatible
to 64-bit systems when they came out. That's why 32-bit PowerPC
machine code and 64-bit PowerPC machine code are completely identical
except that 64-bit CPUs also have a few opcodes to process 64-bit
data and a few extra kernel-mode registers.
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at people who weren't supposed to be in your machine room.
-- Anthony de Boer
On Tue, 13 Sep 2005, Lennart Sorensen wrote:
> > The reverse -- two 64-bit formats and one 32-bit one. And don't forget
> > to multiply by two endiannesses. ;-)
>
> I thought it was 32bit old, 32bit new (for using 32bit pointers on a 64bit
> cpu) and 64bit. At least the names I have seen were 32o, 32n, 64.
Well, n32 requires a 64-bit CPU and uses 64-bit registers. For C/C++
64-bit registers can be referred to with the "long long" types; I can't
comment ABIs for other languages. Pointers are indeed 32-bit. Therefore
for everything except ELF loaders the format can be considered 64-bit.
Maciej
On Tue, Sep 13, 2005 at 11:44:55PM -0400, Kyle Moffett wrote:
> PowerPC was designed 64-bit from the start too! It's just that the
> architecture design group also realized that there would be a demand
> for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32-
> bit system whose entire instruction set would be forward-compatible
> to 64-bit systems when they came out. That's why 32-bit PowerPC
> machine code and 64-bit PowerPC machine code are completely identical
> except that 64-bit CPUs also have a few opcodes to process 64-bit
> data and a few extra kernel-mode registers.
Hmm, so how does that fit with needing both 32 and 64bit libraries on a
ppc system? It seems apple forgot the 64bit part of a library recently
in a security fix, or is that something more to do with their os than
the cpu?
Len Sorensen
On Sep 14, 2005, at 09:20:45, Lennart Sorensen wrote:
> On Tue, Sep 13, 2005 at 11:44:55PM -0400, Kyle Moffett wrote:
>
>> PowerPC was designed 64-bit from the start too! It's just that the
>> architecture design group also realized that there would be a demand
>> for 32-bit CPUs, and so from the _64-bit_ system, they designed a 32-
>> bit system whose entire instruction set would be forward-compatible
>> to 64-bit systems when they came out. That's why 32-bit PowerPC
>> machine code and 64-bit PowerPC machine code are completely identical
>> except that 64-bit CPUs also have a few opcodes to process 64-bit
>> data and a few extra kernel-mode registers.
>
> Hmm, so how does that fit with needing both 32 and 64bit libraries
> on a
> ppc system? It seems apple forgot the 64bit part of a library
> recently
> in a security fix, or is that something more to do with their os than
> the cpu?
Well, if you want to pass 64-bit pointer values to a library, the
library needs to have functions that take 64-bit values and use 64-
bit operations on them, just like all the other archs :-D. It also
needs 32-bit compatibility functions for the old 32-bit-only
programs. On the other
hand, if you don't care about compatibility with 32-bit-pointer
programs, you can omit functions that deal with 32-bit pointers and
require everything to use 64-bit pointers. You still need stuff like
atoi that uses 32-bit values, though, and 64-bit-only does have a
performance penalty.
Cheers,
Kyle Moffett
--
There is no way to make Linux robust with unreliable memory
subsystems, sorry. It would be like trying to make a human more
robust with an unreliable O2 supply. Memory just has to work.
-- Andi Kleen
Roger Heflin wrote:
>
> I guess I see 5 choices:
>
> #1:
> Use lib for whatever the standard os/arch size is.
>
> Use lib32 for the non-standard size.
>
> #2:
> Continue the current mess.
>
> #3:
> Use both lib32 and lib64 and maybe put a link from lib to the
> default one, probably lib64.
>
> #4:
> Use both lib32 and lib64 and don't put a link.
>
> #5:
> Designate the bit size in the name of the lib, ie libc.so64 or
> libc.so32 or something similar and put them all in the same
> directory and let the lib loading code take care of finding the
> correct size.
>
I would say there is a sixth option, at least in theory: Add some
special symbols like 'LP64' or 'ILP32' to the symbol table, and add
a reference to one of these symbols to every *.o file. The linker
could distinguish between 32bit and 64bit implementation within the
same library. This would be similar to a symbol-versioned library.
But I am not sure whether this would be a reasonable option.
Regards
Harri