booting problems

In message <[email protected]>you write:

[ ... ]

OK. This is actually enough to identify the problem.

This is one of those stupid problems that will go away when we revamp the tools to do ELF in a more traditional fashion -- in particular dumping all the dumb HP names for spaces/subspaces and sticking with standard names.

The problem is in the assembler's handling of .nsubspa. It is not honoring the $CODE$ -> .text translation for that case.

in gas/tc-hppa.c::pa_subspace there should be code like this:

     /* If this is an existing subspace, then we want to use the
         segment already associated with the subspace.

         FIXME NOW!  ELF BFD doesn't appear to be ready to deal with
         lots of sections.  It might be a problem in the PA ELF
         code, I do not know yet.  For now avoid creating anything
         but the "standard" sections for ELF.  */
      if (create_new)
        section = subseg_force_new (ss_name, 0);
      else if (ssd)
        section = ssd->ssd_seg;
      else if (alias)
        section = subseg_new (alias, 0);
      else if (!alias && USE_ALIASES)
        {
          as_warn (_("Ignoring subspace decl due to ELF BFD bugs."));
          demand_empty_rest_of_line ();
          return;
        }
      else
        section = subseg_new (ss_name, 0);

You'll note the FIXME NOW!. It's about 5 years old :( Though it will be zapped as we drop the $CODE$ nonsense.

Anyway I think you may be able to fix this bug by changing the subseg_force_new call to look something like:

  subseg_force_new (alias ? alias : ss_name, 0);

Though I'm a little confused. I thought y'all were dropping the existing ELF stuff -- I would strongly recommend it. We're not even planning to keep the existing elf32-hppa stuff building in gas/binutils as we work on the rewrite. You're working with a totally dead and unsupported toolchain at this point.

jeff

<snip>

Okay, I can make that change, unless someone beats me to it.

Let me clear this up.

Yes, we are absolutely dropping any use of the current broken instantiation of elf32-hppa.

However, there's this time gap between now and when we actually have the new toolchain from Cygnus. During this time, the only thing that we expect to work on is the kernel and bootloader. Having just those two components building with the current gcc and linker are important.

When Cygnus delivers a new toolchain, we'll go for that.

If we don't do it this way, the only toolchain we'll have is hosted on HPUX, which I want to avoid if I possibly can. The fix-build-boot-restart cycle is muuuuch faster if you can cross compile and netboot, particularly for those people who only have one HPUX machine and slow connectivity to the HPUX box that HP has online for us.

Does that make sense?

- Alex

As I see it, it is a question of priorities. The existing elf32-hppa tools are the only ones which currently allow cross development due to the lack of gnu linker supporting SOM. If a SOM linker were available, cross development could be done using the more developed and tested SOM tools. However, according to the comments in binutils/bfd, the bfd architecture is incapable of performing all types of SOM relocations. A SOM linker also needs to be stream based. Thus, it appears difficult (impossible?) to build a SOM linker using the bfd architecture. On the other hand, the elf32-hppa tools have serious deficiencies and are about to be completely rewritten. Might it not be better to develop a SOM linker rather than rewrite the elf stuff?

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Writing a linker, especialyl for something complex like SOM is not trivial in the slightest.

Alan

In message <[email protected]>you write:

One hell of an understatement. Time is better spent _rewriting_ the ELF tools to work in a reasoanble manner.

I'm not talking about tweaking the ELF tools, I'm talking about starting from scratch. The elf32-hppa code was the first elf backend that tried to deal with linker generated code.

We've learned a lot since that code was written -- both about the generic issues behind linker generated code and PA specific issues. Enough to realize that what we tried to do in elf32-hppa.c was horribly bad and needs to be scrapped and replaced.

jeff

Yes, if you really want to support SOM properly and follow the spec. It probably isn't if you want to just deal with what actually exists in the world. If you look at page 6-125 of the 32-bit PA-RISC Run-Time Architecture Document 11.0 Version 1.0', it says that all conforming executable SOM files must have the exec auxiliary header (also known as the HP-UX header with Hewlett-Packard)'.

So in the binfmt_som loader I take this opportunity to ignore the wonderfully flexible and expressive structure that is contained in the SOM file format and just map the text, data and bss segments from the file. I imagine that a SOM linker which did just enough to get a kernel up and running would not be too hard to write. On the other hand, I can think of a dozen more interesting and productive things to do.

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

In message <[email protected]>you write:

The headers are the easy part. Really. It's the relocations that are such a bear.

If you look at the SOM exec aux header, it effectively gives you the old
traditional text, data, bss. That's its purpose in life -- to glom together
all the readonly loadable things into ".text", read-write initialized into
".data" and everything else into .bss. The ELF folks in the crowd will
recognize this as the program vs object viewpoints of an ELF file.

While "just a kernel linker" does simplify things (no need for shared libraries and the shitloads of stubs they involve), you've still got a large, nontrivial project on your hands. It would *still* be easier to sit down and rewrite the elf32 tools than to do a kernel-only SOM linker.

If you're really sadistic, look at the way calls relocs are handled.

jeff

In message <[email protected]>you write:

Let me know if it helps. That change is just an educated guess :-)

OK. But note Cygnus is _NOT_ currently scheduled or contracted to provide a 32bit ELF toolchain. Cygnus will be providing a 64bit ELF toolchain which folks can use to derive much of the 32bit toolchain.

I understand. I'm still skeptical that you're going to end up burning more time fighting those lame elf tools than you would by building with SOM tools.

Of course, if you had two HP machines, then this is a non-issue :-)

jeff

Just to through a little "gas" on the discussion, I installed Jeff's patch and rebuilt. The patch sucessfully merges $CODE$ into .text.

Here are the kernel headers:

vmlinux: file format elf32-hppa

Sections:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000759b0  00008000  00008000  00001000  2**4

CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 0000f260 0007d9b0 0007d9b0 000769b0 2**3
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0001ac6c 0008e000 0008e000 00086000 2**4
ALLOC
3 .PARISC.unwind 00006be0 000a8c6c 000a8c6c 00086000 2**0
CONTENTS
4 .PARISC.symext 00000000 000af84c 000af84c 0008cbe0 2**2
CONTENTS

Here are the headers for ipl linked with "-Ttext800 -N":

ipl: file format elf32-hppa

Sections:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000028a0  00000800  00000800  00000080  2**4

CONTENTS, ALLOC, LOAD, CODE
1 .data 000064a8 00004000 00004000 00003880 2**12
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0000115c 00010950 00010950 00009d28 2**3
ALLOC
3 .PARISC.unwind 000000c0 00011aac 00011aac 00009d28 2**0
CONTENTS
4 .PARISC.symext 00000000 00011b6c 00011b6c 00009de8 2**2
CONTENTS

I think that we are real close to being able to generate a bootable kernel with the existing elf32 tools.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Okay, I'll give this one more try with my current setup and see what happens...

In the meantime, I've started private talks with HP about the possibility of releasing an HPUX ld cross compiler hosted on i386-linux.

- alex