cheesestraws
Well-known member
There is an infuriating but not totally useless tool to probe the early boot sequence of A/UX provided by the launcher. If you pass the -b option, followed by a virtual address within the kernel, the instruction at that address will be rewritten to be a reset. Thus, if the computer resets, control reached this point - if it does not, it didn't. So, for example, if you wanted to see whether control ever reached 0x58934 (the beginning of initcpu in my kernel here), you'd do
The help for this option is, as you'd imagine, extremely terse, and there's a couple of points that might bear elucidating.
Code:
launch -b 0x58934
The help for this option is, as you'd imagine, extremely terse, and there's a couple of points that might bear elucidating.
- By far the easiest way to get the virtual address you want to use is using a disassembler. You can load the kernel you're using as a COFF file and find the address of the instruction you want to catch that way. Don't forget that loading modules and stuff relinks the kernel: so don't be me and do make sure that you have disassembled the kernel you are actually running not a completely different one that happened to be in the same directory. That will not work.
- In early boot, down around 0x50000ish, the section dump printed by launch -d will tell you that those are physical addresses. They are, but don't let that put you off - you can still set a reset point using launch -b at those addresses.