Quote: Write a small command line tool whch creates a list, adds a node, removes the node, then chacks the value of ln_Succ in the node. If debug kernel is running this will be munged to 0xFFFFFFFF, if not it will be unchanged. Freeup resources and return WARN (5) for debug 0 for standard.
Yep, something like this, I tried it, it might work..
But I got stuck on reading the DAR value from the cpu special register :/
Not sure why you want to read the DAR to achieve the above?
Quote:
I tried reading it from C via asm but it turned out that this value is only readable in super-visor mode :S (if I understood it correctly, and the code did not work)
A way to read the DAR value in user-mode, or some other way, would help...
But given that you want to read the DAR for some other reason, check out IDebug->ReadTaskStatus()
(in exec autodoc as "debug" is an alternate interface in exec.library ).
caveat: i've not messed with this api much, so that may not be the function you need. I just scanned the autodocs.
When I was following this thread, it made me think of a little tool I have been using for years to tell me which Kickstart config I have booted.
Problem was, it was only released inside the OS4 beta tester group, so I couldn't recommend it here as a solution.
So I contacted the author, Alex Carmona, and he allowed me to release it publically for him, while suggesting I rewrote his original doc file.
I have done so, and it is now sitting in the upload queue of OS4Depot.
The archive name is GetKickConf.lha, and it should end up in utility/shell shortly.
There are detailed instructions in the readme inside the archive, but basically, it allows you to set an environment variable with a name that you give to each of your Kickstart configs, so that you can e.g. display it in the WB title bar. Or you could use it to control a script to start your test tools when booting your debug config, etc. etc.
I've been able to read the DAR register some days ago now, with IDebug->ReadTaskContext()
However when making something "illegal" (like described in AmigaOS wiki "Debug Kernel") the Grim Reaper pops up before I can track the DAR value from my code, so that way didn't work...
But maybe GetKickConf will help here, gonna check :P...
I've been able to read the DAR register some days ago now, with IDebug->ReadTaskContext()
However when making something "illegal" (like described in AmigaOS wiki "Debug Kernel") the Grim Reaper pops up before I can track the DAR value from my code, so that way didn't work...
Your not supposed to dereference the illegal pointer just check it's value!.
pseudo code:
Create List Create Node Add Node to list check and save ln_succ ans ln_pred values Remove node from list (using IExec->Remove()) check and compare ln_Succ and ln_Pred with saved values.
Your not supposed to dereference the illegal pointer just check it's value!.
pseudo code:
Create List Create Node Add Node to list check and save ln_succ ans ln_pred values Remove node from list (using IExec->Remove()) check and compare ln_Succ and ln_Pred with saved values.
I got it just how I like it (the behavior) now in my User-Startup script:
GetKickConf BootConfigName
If "$BootConfigName" Matches "OS4 debug kernel"
Run Sashimi
EndIf
Yep, looks good. Minor detail: I'd probably just use "EQ" instead of "Matches", since you compare the variable to a literal string, not an AmigaDOS wildcard pattern.