Chapter 8 - FAQ.

Debug bases:

Q: What is a hit?
A: If a program is accessing the zero-page (also called the low-page)  or  any
   non-available memory, it will create a hit. Basically, a hit is the  report
   of an illegal memory access.
   Hits are never harmless. They are program bugs and must be fixed.

Q: What are Enforcer, Cyberguard and all these MMU tools?
A: They are very hardware specific tools watching for illegal  memory  access.
   Do not use them! The same functionality is already built-in MorphOS and  is
   always active.

Q: What's SegTracker?
A: This tool tracks all code locations. When something is  loaded  in  memory,
   address is stored and put in a database. Then MorphOS uses it   to  display
   the name of a crashed module. It's possible to more easily  identify  where
   hits come from: libraries, devices, handlers, etc
   SegTracker functionnality is built-in MorphOS and is always active.

Q: MorphOS doesn't seem to detect read-access to address 0. Is it normal?
A: Yes, MorphOS doesn't read-protect zero  page;  yet.  It  write-protects  it

The memtracker:

Q: What is the memtracker?
A: It is a powerfull debug tool built-in MorphOS. It tracks memory allocations
   and reports wrong freeing sizes and mismatching pointers.

   Activate it by using the MorphOS' EDebugFlags boot argument.
     EDebugFlags="permmemtrack" permanently activates memtracker.
     EDebugFlags="permmemtrack memtrack" also activates memtracker's output.

   When memtracker is used (EDebugFlags="permmemtrack"),  it  is  possible  to
   disable/enable its output on the fly, using SystemSettings/Debug/MemTrack.

   When permmemtrack is not used, memtrack still toggles memtracker on/off but
   it won't notice invalid freeing of memory.

   Please note the memtracker fills  all  free  memory  using  the  0xABADCAFE
   pattern. It helps to catch uninitialised pointers, or  using  already  free

Q: Why does the system become slower when the memtracker is enabled?
A: The memtracker involves a lot of extra operations during memory  allocation
   and deallocation. It is a pure debug tool. Only use it  when  you  need  to
   track  a  problem  or  when  you  want  to  check  your  memory  management

Debug tools:

Q: Objdump is slow when processing big executable files.  Is  it  possible  to
   speed it up?
A: Yes. It can be restricted to dump only a certain address  range  around  an
   Just type "objdump" in a shell  and  read  its  argument-options.  You  are
   looking for the --start-address=addr and --stop-address=addr ones.

     objdump program -disassemble-all --start-address=10000 --stop-address=20000 >program.dump

Q: Objdump crashed, how is it possible to debug anyway?
A: It seems there is  a  problem  with  objdump.  You  can  workaround  it  by
   restricting the dump to a smaller range. See above.

Q: How do I use FindHit?
A: You can't. Please use objdump for now.

Q: I heard about addr2line. Can it be used like FindHit?
A: There is a problem with addr2line  and  it  isn't  reliable.  But  CISC  is
   working on it. :-)


Q: How can I output my own debug information? I used to use kprintf().
A: You can still use kprintf(). It is in libdebug.a

Q: How do I capture kprintf() output?
A: Use sushi/sashimi or use EDebugFlags="logkprintf" MorphOS boot argument.

     boot boot.img EDebugFlags="logkprintf"

Q: I heard about dprintf() but how can I use it?
A: You do not. There is no such a public function. Please use kprintf().

Weird error messages in the log:

Q: Why do I get "PPC Stack Ptr is not between PPCSPLower and PPCSPUpper"
A: It means the PPC stack pointer is out of bound.
   Perhaps the program used too much PPC stack and did a  stack  overflow.  Or
   the r1 register got trashed (r1 is the PPC stack pointer, as defined by the
   SystemV ABI).
   This can also happen if a program  uses  setjmp()  or  any  other  function
   playing with the stack.

Q: Why do I get "68k Stack Ptr is not between SPLower and SPUpper" messsage?
A: Perhaps the program used too much 68k stack and overflowed it.  Or  the  a7
   register got trashed (a7 is the 68k stack pointer).
   This can also happen if a program uses a non-standard way to swap the stack.
   AmigaE applications are known to do it. Then this is not a bug, of course.

Q: Why do I get "Error: TaskEmulHandle 0x00000000 is not a legal address"?
A: EmulHandle is the 68k emulation's entry-point and its address is stored  in
   r2. It must always be valid. If it is not; r2 register got trashed.

68k emulation:

Q: Why do I see offset referring to "Emulation" or "Module"?
A: If an offset is in "Emulation". It means the static  emulator  was  running
   some 68k code and you should look at the 68k part of the debug log.
   If an offset is in "Module", it simply means that it is  somewhere  in  the
   MorphOS module ROM: exec, dos, intuition, sfs...

Q: MorphOS has a JIT emulator. When 68k code crashed, what should I look  for;
   PPC or 68k code?
A: 68k code.
   But, when Trance is running, the PC register is referring to the  start  of
   the translated code-block. This is probably not exactly the point where the
   crash happened but it's the only available reference to it. You might  want
   to try disabling JIT to get the precise location of the problem.

Hardcore problems:

Q: I have a really complex crash and much more StackFrame would be  needed  to
   track the problem in my code. What is it possible to do?
A: There is a BackTraceDepth  argument  to  choose  the  amount  of  displayed
   StackFrame. See the documentation in SYS:Docs/PegasosFirmware.txt

     boot boot.img BackTraceDepth=10

Q: The system freezes, there is no console window and I can't get the ramdebug
A: It may be possible to get the ramdebug log after a reboot if  the  firmware
   didn't clear the memory. It all depends on your hardware setup.
   But the best solution is to use serial debug.

Q: What is the meaning of "FAQ" ?
A: Frequently Asked Questions.

<< PowerPC Registers overview | Index >>