update

[fw/sdcc] / debugger / README

sdcc/debugger

SDCDB debugger
======================
Notes Feb 10, 2002 - Karl Bongers

SDCDB is a debugger for SDCC compiler.  It works as a front
end to the ucSim simulator/disassembler program.

WARNING: SDCDB is EXPERIMENTAL and NOT A FULLY FUNCTIONING TOOL.

SDCDB does hold out promise for a nice debugger tool that
could integrate well with ucSim and other SDCC tools.  It has
some nice functionality that could augment ucSim nicely.
It reads in a lot of symbolic information from the .CDB
debug files as well as the source code and assembly
listings referred to in these CDB files.
This can be used to display your program data, list
c or asm source code and set breakpoints.

Unfortunately, SDCDB is not quite finished and does not
function well enough yet to recommend for general use.


Usage Notes
======================
Compile with --debug option:
sdcc --debug hi.c
This should generate .cdb symbolic debug files.

Load sdcdb, like this:
sdcdb hi.ihx

Then you need to do an initial "run" command.  It should hopefully
stop somewhere at the main() entrypoint.

Now you should be able to list code, and set breakpoints.  Type
"c" to continue running to a breakpoint, or type "s" to single
step or "n" to skip function calls.  Tpye "help" for a summary
of commands.

Use a preceeding bang("!") to do s51 simulator commands.  So for
example:
!pc
will send the "pc" command to ucSim and
give you the program counter and list the current line of assembly.
!help
will give you the brief command line help listing of ucSim.  But
this help will scroll of the screen.  So to get a list, I redirect
stdout to a text file to examine like this:
sdcdb hi.ihx 2>&1 | tee sdcdb.log

Type '.' to toggle to a full time ucSim prompt.


SDCDB problem areas.
======================

Ok, so what are some of its problems?  Lets try to itemize
them so we can fix them:

* It hangs sometimes when trying to do step or next.

   This probably has something to do with the context
   sdcdb tries to build dynamically.  Sdcdb tries to
   trace program operation by placing hidden breakpoints
   and stepping threw the simulation between these.

* Does not print variables properly.  Seems to use the
  wrong address for the variable. (fixed)

* ASM listing not implemented.
  This should be easy enough to add.  This feature
  really needs to be implemented before this is a useful
  tool.  That or addresses of code functions need to be
  readily available for raw ucSim commands.

* No way to browse symbols, files names.
  Preferably, it is easy to learn the addresses of variables
  and functions too.
  (working on this... see new ls,lm,lf commands)

* Does not allow listing, setting breakpoints or viewing variables
  before starting the simulation.
  (I am fixing now, partly fixed)

* p codestr - print on code char * broken, could be CDB info invalid.


Changes Made
======================

Added a -z option.  Any options after -z on sdcdb invocation line
 are passed directly to ucSim.

Fixed print basic variable command(was not parsing or expecting
  "0x" in data coming from ucSim).  Dump bit command changed from
  "db" to "dump".

Add support for the following alternative ucSim binaries:
 -mz80 - use "uz80" simulator.
 -mavr - use "uavr" simulator.
 -mxa - use "uxa" simulator.

  Note that Z80(and probably avr/xa) does not produce enough
  CDB debugging information to
  make SDCDB useful.  Hopefully CDB support will be
  added to these other linkers and code generators.

Added lf,lm,ls commands(list functions, list modules, list symbols).
 This allows browsing some the CDB information SDCDB pulls in
 to do the wonderful things it does.

Added '.' prefix/command, used alone switches back and forth
 from ucSim/SDCDB command mode).  Also when at the (ucsim) prompt,
 if a command is prefixed with '.' it will route the command to
 the SDCDB command processor.  (This could obsolete the '!' prefix).


======================

Fix any remaining shortcomings above and make sdcdb integrate better with
ucSim.

Concerning the hanging on next/step instructions:  This is critical
to fix.  I beleive the problem is related to SDCDB's attempt to
dynamically track context.  To do this, it sets many temporary break
points and uses these to progress step by step through the source code.
It does not seem reliable.  It might be an idea to offer a simplified
mode of stepping and breakpoints.  Need to study this more.

Make SDCDB integrate better with ucSim.
I think if sdcdb can act more transparently in regard to ucSim
it would be used more.  So stress adding value and enhancing
ucSim operation, and not block or hide the functionality of ucSim.

* combine print "p" & "pt" together.  We have room on the screen,
might as well print its type, address and value in one command.

* "fr" command prints the current position in the C code.
Should also print the raw code address for dumping ucSim code.



Developer Notes:
======================
To debug, it might be helpful to turn on verbose debug dumps
by uncommenting #define SDCDB_DEBUG in sdcdb.h.

Some basic layout:
sdcdb.c - main shell of the program.
cmd.c - process user commands typed in.
simi.c - handle talking to the simulator via a socket connection.
symtab.c - Misc. functions to translate and process linked list
  structures(modules, functions, symbols, etc) and CDB file
  parsing.
break.c - track and implement break points.

Understanding the structures and access mechanisms of SDCDB
is a bit of work.  The structures include generic linked list
and function access.  These lists are accessed in part by the
functions from ../../src/SDCCset.c and SDCChash.c.  See the
cmd.c:infoSymbols() routine to gain some insight into these
main program structures.  Or type "info symbols" to dump
out some of these.  The new ls,lm,lf commands are also based
on showing information about these lists of structures.

Generic functions are used to act on these linked lists of
structures.  For example, in cmd.c, DEFSETFUNC(funcWithName)
function will find a function structure with a given name.
So the linked list of function structures(with the head
"functions") is traversed and when one is found with a matching
name, a pointer to the function structure is returned.

The src/SDCCset.c,SDCCset.h contain much of the core helper
routines to allowed to implement these linked list access
functions.

The dynamic context tracking is difficult to understand.
It has some concept of stack use, as in
cmd.c:printSymValue(), where it can print variables relative
to the stack pointer.