Re: Need help debugging silo
On 29/12/15 09:25, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Something with the version of silo I built from source on sparc64 is
> amiss:
>
> Version from sparc:
>
> (sparc64 host): genisoimage -G boot/isofs.b -B ... -r -o test.iso boot/
> (amd64 host): qemu-system-sparc64 -nographic -m 512 -cdrom test.iso -boot d
> OpenBIOS for Sparc64
> Configuration device id QEMU version 1 machine id 0
> kernel cmdline
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Sep 12 2015 17:10
> Type 'help' for detailed information
> Trying cdrom:f...
> Not a bootable ELF image
> Loading a.out image...
> Loaded 7680 bytes
> entry point is 0x4000
>
> Jumping to entry point 0000000000004000 for type 0000000000000005...
> switching to new context: entry point 0x4000 stack 0x00000000ffe8aa09
> SEXIT
> 0 >
>
> Version from sparc64 which I built from source:
>
> (sparc64 host): genisoimage -G boot/isofs.b -B ... -r -o test-new.iso boot/
> qemu-system-sparc64 -nographic -m 512 -cdrom test-new.iso -boot d
> OpenBIOS for Sparc64
> Configuration device id QEMU version 1 machine id 0
> kernel cmdline
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Sep 12 2015 17:10
> Type 'help' for detailed information
> Trying cdrom:f...
> Not a bootable ELF image
> Not a bootable a.out image
> Not a bootable FCode image
> No valid state has been set by load or init-program
>
> 0 >
>
> So whatever I built on sparc64 from source, it's broken.
>
> Any ideas?
I've just stepped through both the wheezy and your test ISO using a
debug build of OpenBIOS, and what's happening is that in your SILO
build, OpenBIOS doesn't detect the a.out magic and so fails to locate
the executable bootloader.
Digging a bit deeper using QEMU/OpenBIOS you can see the following in
include/arch/sparc64/a.out.h:
struct exec {
unsigned char a_dynamic:1; /* A __DYNAMIC is in this image */
unsigned char a_toolversion:7;
unsigned char a_machtype;
unsigned short a_info;
unsigned int a_text; /* length of text, in bytes */
unsigned int a_data; /* length of data, in bytes */
unsigned int a_bss; /* length of bss, in bytes */
unsigned int a_syms; /* length of symbol table, in bytes */
unsigned int a_entry; /* where program begins */
unsigned int a_trsize;
unsigned int a_drsize;
};
Using QEMU's gdbstub it's easy to see that sizeof(char) == 1 and
sizeof(short) == 2. Backing up through the interposed ih chain we can
see that the test ISO is being detected as a valid Sun partition table
and that the a.out executable is located at offset 0x200 within the ISO
image files. And now the issue is fairly easy to spot with hexdump:
wheezy ISO (works):
00000200 01 03 01 07 00 00 19 60 00 00 00 00 00 00 01 90
00000210 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00
00000220 40 00 00 02 a0 10 00 0f 33 00 00 16 b2 16 61 70
test ISO (fails)
00000200 00 00 00 00 01 03 01 07 00 00 00 00 00 00 18 40
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 b0
00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The a.out magic (0x107) is located at bytes 0x202-0x204 in the working
image but appears at bytes 0x206-0x207 in the broken image. It looks
like somehow your 64-bit SILO build is extending the a.out header fields
from 32-bits to 64-bits which is why the bootloader fails to be detected
by the PROM.
HTH,
Mark.
Reply to: