[eresi-dev] KEDBG-JTAG meeting #3 Sum up

[Julien Vanegue]

Here is what has been said during the Meeting #3:

Step 1 has been succesfully implemented and tested. Many bugs were
corrected. We have let some minor features on the side to keep advancing on
the main stuff.

We now have a correct connection to the embedded server, and D/X
(disasm/hexa) working in kedbg / dynamic mode when connected to a JTAG
target.

We now need:

(2) Update libgdbwrap internal structures to be able to handle ARM
architecture (3) Add the necessary vector handlers in kedbg to implement
specific ARM/JTAG operations for break, step, getregs, setregs, etc for the
JTAG target

We have identified that only the register context structure needs to be
redefined for ARM. For this reason, we merge step 2 and 3 starting from now.

Here are the substeps for the remaining work before feature freeze:

A. Finish the implementation of the MONITOR command for kedbg. In gdb, all
commands for openocd are sent using the MONITOR prefix.
    => API already exist, needs to register a new command.
    => See how the command parameters are handled in other commands handler.
    => Test if start and continue now works after setting a monitor
breakpoint.
    => Also test the monitor step command.

B. ARM registers context structure:
    => Create the ARM register context structure type in libgdbwrap. Find
the structure in openocd's gdbserver source code.
    => Implement kedbg getregs handler and register it.
    => Implement getpc getfp and getret handlers (see existing examples in
kedbg).
    => See if dumpregs command handler (in kedbg) needs any change to work
on ARM, and implement them.
    => Make sure dumpregs command works when reaching a breakpoint.
    => Make sure reaching a breakpoint now print the good instruction
(verify with D). If not, something in the breakpoint command handler need to
be adapted.
    => Implement kedbg setregs handler and try to play with register values
(using "set $reg val" then some "step" should  be enough to see if it
works).

C. Final handlers implementation
    - Identify the traffic generated by a monitor breakpoint / step using
wireshark.
    - Create a openocd-specific handler for those operations (so that we
dont have to do "monitor break XXXX" all the time, but use the normal break
(or step) command)


Additionally, we want to support graphing of ARM code. Thiago Figuereido
came back from the grave and has restarted to work on the libasm ARM. We
will need the following to make graphs to work for ARM:

D. Make graphs to work on ARM code:
   - Make sure all b/bx/bl/blx instructions are entirely supported and well
printed.
   - Add semantic flags for instructions (CONDBRANCH, IMPBRANCH, CALLPROC,
RETPROC) by setting the ->type field of the instruction structure
   - Try to graph rtos.elf main function like that: "graph bloc main" in
elfsh
   - Do the same in dynamic mode from kedbg.

We agreed that the development should freeze in 2 weeks so that Jesus can
work on his report. We are thus expecting advances on those points for the
next days.

Have fun !

Julien Vanegue / the ERESI team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einherjar.de/pipermail/eresi-dev/attachments/20090504/f5b076aa/attachment.html>