It's finally sunk in: bye bye elf32
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
Quoted 3 lines
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
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
In message <[email protected]>you write:
Quoted 5 lines
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.
Quoted 5 lines
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
Quoted 10 lines · John David Anglin
Quoted 3 lines
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.
[...]
Quoted 2 lines
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..
Signature · 4 lines
Matthew Wilcox <[email protected]> "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