Re: Mopd which works with ELF and a.out in Linux and can netboot ULTRIX

[Boris Gjenero <boris.gjenero%gmail.com@localhost>]

Hi Maciej,

On 2020-11-03 7:58 a.m., Maciej W. Rozycki wrote:
>   My implementation of the ELF interpreter in `mopd' uses the LMA addresses
> of individual segments for loading purposes, as per the ELF gABI (so that
> you can have VMA != LMA, e.g. if real addresing is used for loading and
> then virtual addressing is switched on later on; this will be specific to
> the individual MOP client's processor and operating configuration).  Also
> it sends the client the entry point as it is from the ELF file header.

This seems correct.

>   Yes, I have noticed that VAX/NetBSD ELF MOP boot images have been broken
> since NetBSD 4:
>
> $ readelf -hl cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot
> ELF Header:-snip-> Program Headers:
>    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>    LOAD           0x000054 0x007f0000 0x007f0000 0x11050 0x13840 RWE 0x4
>
>   Section to Segment mapping:
>    Segment Sections...
>     00     .text .rodata .data .bss
> $ mopchk cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot
> ELF 32-bit LSB executable
> Size of seg #00:    00011050 (+ 000027f0 fill)
> Load Address:       007f0000
> Transfer Address:   00000000
> $

Yes, it definitely seems the image is broken.

> and figured out what the proper fix is by comparing them to the old a.out
> images (which got the addresses right).  It can be easily done with
> `objcopy', e.g.:
>
> $ objcopy --adjust-vma -0x7f0000 --set-start 0x7f0000 cdn.netbsd.org/pub/NetBSD/NetBSD-9.0/vax/installation/netboot/boot boot
> $ mopchk boot
> Checking: boot
> ELF 32-bit LSB executable
> Size of seg #00:    00011050 (+ 000027f0 fill)
> Load Address:       00000000
> Transfer Address:   00000000
> $
>
> (with `--adjust-vma' the entry point is relocated accordingly, so you need
> to cancel the adjustment with `--set-start').
>
>   I mentioned it to Ragge the other day; as a relative newcomer to NetBSD I
> have no idea where the problem comes from.  It looks to me like an odd
> build issue, likely one in the linker script used to make this image;
> perhaps something to do with LMA vs VMA, as noted above (i.e. the VMA is
> correct as per the interpretation of code executed and the symbol table,
> and it's only LMA that ought to be adjusted).

I think the linking is done improperly, and this could be fixed with a 
linker script. Currently, sys/arch/vax/boot/boot/Makefile uses "-Ttext 
${RELOC}", with "RELOC=0x7f0000" in sys/arch/vax/boot/Makefile.inc. This 
puts the .text section at 0x7f0000. Then it uses "-e nisse" to set the 
transfer address to 0, using the nisse symbol defined in 
sys/arch/vax/boot/common/srt0.S.

Adding the objcopy to sys/arch/vax/boot/boot/Makefile could fix it. 
Though I think a proper solution would be a linker script.

>   I don't know what any other `mopd' implementations do that makes the ELF
> image work with them. I have successfully used my `mopd' implementation
> to boot all kinds of DEC equipment and images: 32-bit ELF, 64-bit ELF (for
> R4k DECstations), and non-ELF, built by myself and by DEC (e.g. a console
> firmware update for VAXstation 4000), e.g.:

NetBSD mopd simply uses "dl->loadaddr = 0;" in GetElfFileInfo() in 
common/file.c. That's wrong, in terms of ignoring what the ELF file 
says, but it works with ELF files which are broken in this way. I'm sure 
there are other ELF files which wouldn't work if simply loaded at address 0.

Thank you for investigating this.

Boris