[parisc-linux] It's finally sunk in: bye bye elf32

[parisc-linux] It's finally sunk in: bye bye elf32

[Alex deVries]

Over the last week I've really spent a lot of time trying to get the
kernel to build and boot when crosss compiled from i386. This meant
using the existing broken elf32 implementation.

This was only to be a temporary solution until at some point we got a
proper ELF64 implementation from Cygnus, which we'd then fold back into
ELF32.  That's a long way off though, and it's important to move forward
on this port.

It's quite possible that we could have fixed up the broken elf32
implementation enough to build our kernel and bootloader, but the worry
is that there's a risk that it's going to be a huge pain.

So, I'm going to do an about face and change my mind completely about
the som/elf32 situation.  So far, Matt Wilcox, Alan Cox, Jef Law and
Chris Beard all seem to agree.  I'm just a bit slow in jumping on board.

There's two reasons I'm changing my mind somewhat suddenly:

- I had really bad nightmares last night about having to fix the broken
elf32 implementation, which I really don't understand, which would be
dumped later down the road, and for which there's a supported
implementation on HPUX.

- I spent the entire day building a deck in the sun; it made me come to
my senses and realize that I'd been arguing some of this because it's
the assumption I'd done my existing work on. It's sometimes difficult to
tear yourself away from the details of the problem and look at the
bigger picture.

So, I'm going to spend some time making the kernel build on HPUX.  I
know there's quite a few changes to make.  But I'll keep the elf
specific work, it'll help later on.

- Alex




- Alex

Re: [parisc-linux] It's finally sunk in: bye bye elf32

[John David Anglin]

> So, I'm going to spend some time making the kernel build on HPUX.  I
> know there's quite a few changes to make.  But I'll keep the elf
> specific work, it'll help later on.

The discussion about the merits/limitations of SOM and ELF over the
last couple of days has been extremely useful.  As Alex says, there is
a lot of work to be done on the kernel before it is usable.  However,
in the long run, the port must be a complete self contained system.
That is, it must support a linker capable of generating executables
and the kernel.

The concensis is that writing a SOM linker is a major project.  Another
option might be to approach HP and see if they would consider putting
the source code for their SOM linker into the public domain, or possibly
supplying a static binary version of the linker that could be distributed.
I would suggest that Alex discuss the matter with his contact at HP.

If this does not work out, then we must fall back to ELF32 and devote
enough effort to get elf32-hppa working at an acceptable level.  Jeff
Law is the world expert on the hp version of these tools.  However, Jeff
is very busy with gcc.  Any volunteers?  Obviously, this needs to be
coordinated with the maintainers of binutils and Cygnus.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] It's finally sunk in: bye bye elf32

[Jeffrey A Law]

  In message <199906131702.NAA28988@hiauly1.hia.nrc.ca>you write:
  > The concensis is that writing a SOM linker is a major project.  Another
  > option might be to approach HP and see if they would consider putting
  > the source code for their SOM linker into the public domain, or possibly
  > supplying a static binary version of the linker that could be distributed.
  > I would suggest that Alex discuss the matter with his contact at HP.
It's an option.  Probably not a bad one.  Though the HP linker's idea of
portability is marginal at best, so getting it running on another system is
no trivial effort.  But if HP is willing to do it and give y'all binaries,
then go for it.


  > If this does not work out, then we must fall back to ELF32 and devote
  > enough effort to get elf32-hppa working at an acceptable level.  Jeff
  > Law is the world expert on the hp version of these tools.  However, Jeff
  > is very busy with gcc.  Any volunteers?  Obviously, this needs to be
  > coordinated with the maintainers of binutils and Cygnus.
I would strongly recommend against any serious work at trying to make the
existing elf32-hppa.c work -- start over from scratch with the spec at your
side.  There is almost no salvageable code in elf32-hppa.c.

If someone has an interest in working on a rewrite I would strongly encourage
them to contact me so that we can work closely together and avoid useless
duplication of work since I'm working on elf64-hppa.c right now (which should
be able to share a bunch of code with elf32-hppa.c)

jeff

Re: [parisc-linux] It's finally sunk in: bye bye elf32

[Matthew Wilcox]

On Sun, Jun 13, 1999 at 01:02:58PM -0400, John David Anglin wrote:
> > So, I'm going to spend some time making the kernel build on HPUX.  I
> > know there's quite a few changes to make.  But I'll keep the elf
> > specific work, it'll help later on.
> 
> The discussion about the merits/limitations of SOM and ELF over the
> last couple of days has been extremely useful.  As Alex says, there is
> a lot of work to be done on the kernel before it is usable.  However,
> in the long run, the port must be a complete self contained system.
> That is, it must support a linker capable of generating executables
> and the kernel.

[...]

> If this does not work out, then we must fall back to ELF32 and devote
> enough effort to get elf32-hppa working at an acceptable level.

The long term goal is to support:

 * HP-UX binaries
 * parisc/elf32 Linux binaries
 * parisc/elf64 Linux binaries (on parisc 2.0 hardware)

The binfmt_som kernel support is necessary in both the short term (to
get a working shell for free) and long term which is why I decided to
do it first.  Once the kernel is built, we can then run the HPUX linker
on it, but we have a `small' bootstrap problem.  As Jeff says though,
it's worth throwing away the whole of parisc/elf32 and starting again
from scratch.  We were just hoping to not have to do that for a while..

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson