On Tue, Apr 19, 2011 at 12:15 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
On 18/04/11 17:00, Mark Cave-Ayland wrote:
A quick watchpoint later showed that this is in fact controlled by the presence of a zero-length attribute called "aligned-allocator" under /openprom. Since this property appears in the sample prtconf output, then it suggests that this code path is triggered by OBP. Rather bizarrely, if I add this property to OpenBIOS then kadb crashes further down the line - BUT if I simply use gdb to make kadb think the property is present by changing the relevant register within gdb then I am able to load kadb?!
I think I'm probably about 90% there when it comes to getting kadb up and running under OpenBIOS, but I still need to figure out why just adding the missing property isn't enough here.
Okay - so it looks like I win the prize for discovering a new romvec entry point :) When the /openprom/aligned-allocator property exists with zero length, kadb somehow manages to get ufsboot to jump to a different offset within the romvec parameter block. Tracing the offset through gdb shows that it is trying to jump to the function pointer at this location in openprom.h:
int filler[15];
Hmmm. Since this was set to NULL, it was causing kadb to trap when trying to allocate memory from OpenBIOS. Anyhow the parameters look pretty much like obp_dumb_memalloc() except with an extra parameter probably giving the alignment. So with a quick patch I can now fire up kadb like this:
Great Job!
Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Apr 18 2011 21:08 Type 'help' for detailed information
0 > boot cdrom:d kadb -kvd Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 bootpath: /iommu/sbus/espdma/esp/sd@2,0:d
Jumping to entry point 00004000 for type 00000005... switching to new context: Size: 119204+222573+28987 Bytes kadb: kadb: kernel/unix Size: 259040+54154+47486 Bytes /platform/SUNW,SPARCstation-5/kernel/unix loaded - 0x95000 bytes used kadb[0]: :c stopped at: scb: sethi %hi(0xf0041000), %l3 kadb[0]: :c SunOS Release 5.8 Version Generic_108528-09 32-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. \
Alas unfortunately I have no idea what this new mystery function is called, so if anyone can come up with a more suitable name please let me know.
Have you looked how the calling function is named? Maybe this could give a hint.