I had this idea too, but unfortunately objcopy doesn't seem to work on
relocatable objects, only on fully-linked objects:

3 sparc1:~> objcopy -I a.out-sparc-netbsd -O elf32-sparc uvm_anon.o.aout uvm_anon.o.elf
BFD: uvm_anon.o.elf: unsupported relocation type HI22
objcopy: uvm_anon.o.elf: Bad value


if someone makes objcopy work for relocatable objects then we can
continue down this path, otherwise it's a dead end.


as for section alignment and such, here's what the two kernels look like:

36 sparc1:~> objdump -h netbsd.elfconv 

netbsd.elfconv:     file format elf32-sparc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00180000  f0004000  f0004000  00000054  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00015670  f0184000  f0184000  00180054  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          0003f084  f0199670  f0199670  001956c4  2**2
                  ALLOC
37 sparc1:~> objdump -h netbsd.elfnative 

netbsd.elfnative:     file format elf32-sparc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0015c894  f0004000  f0004000  00000074  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00021f8a  f0160898  f0160898  0015c90c  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         000151ac  f0192828  f0192828  0017e898  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0003fb40  f01a7a00  f01a7a00  00193a70  2**8
                  ALLOC
  4 .comment      00005280  00000000  00000000  00193a70  2**0
                  CONTENTS, READONLY


I don't know why the .bss section would need to be 256-byte-aligned,
that seems kinda wrong to me.  I don't know what to make of all this, tho.

-Chuck



On Tue, Feb 01, 2000 at 11:47:02AM -0500, der Mouse wrote:
> > I had noticed a while back that the problem only happens when the
> > kernel is ELF, a.out kernels work fine.  as a goofy experiment, I
> > tried converting an a.out kernel to ELF with objcopy, and I was
> > completely amazed to find that this produced a working kernel [...]
> > anyone have ideas on how to proceed from here?
> 
> Well, here's how I'd approach it.
> 
> - objcopy all the .o files from your a.out kernel, then try linking
>    with the ELF ld.  If it fails, it's ld; if not, it's elsewhere.
> 
> - If it's ld, I'm not sure where to go from there.
> 
> - If it's elsewhere, then start recompiling, one file at a time.  (Or
>    if you're ambitious, save all the objcopied a.out .o files and do
>    binary search on the set of .o files.)  Once you find the file that
>    breaks, try a kernel that's ELF all the way except for that .o file.
> 
> - If you can narrow it down to a single .o file, then start using cc -S
>    and diff and the like, or possibly diff the disassembled .o files.
> 
> - If not...I'm not sure where to take it from there.
> 
> This is largely built on the hope that it's a codegen bug, somehow, as
> you can probably tell from which branches are "I'm not sure what to do".
> 
> 					der Mouse
> 
> 			       mouse@rodents.montreal.qc.ca
> 		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B