| |
Hi All.
I've been thinking about how gdb can be used to debug legOS
programs. I've hashed most of it out, but one thing has me stumped --
how can I do a software trap on a H8300? I'd like to hear any
suggestions as to how I can get round this.
The general idea is to use gdb remote stubs via tcp/ip (using 'target
remote localhost:6789'). A simple tcp/ip server/translator listens on
port 6789 and forwards requests to legOS via LNP. Likewise the server
listens for IR response packets from legOS and sends them back up the
socket to gdb. This allows me to use gdb 'out-of-the-box'.
A stub for legOS is linked with the target program. The stub uses lnp
to receive & decode the gdb packets sent by the server/translator and
action them.
So far I have:
. Built a gdb targeted at the H8 processor.
. Built a coff file for a legOS application such that gdb can read it
symbolicly.
. Prototyped the server/translator (using python). This has allowed me
to understand the gdb remote protocol, and do some simulations of
the target stub.
I now have a good understanding of what is required in the legOS debug
stub. The requirements are mostly straightforward, apart from...
How can I set a breakpoint?
I checked the H8 assembler manual, and I can't find anything like a
software interrupt or trap instruction. Does such a thing exist? If
so, where does it vector too? Oddly, when gdb wants to set a
breakpoint, it writes the opcodes 0x5730 at the breakpoint
location. Searching the gdb source, I found this:
#define REMOTE_BREAKPOINT { 0x57, 0x30} /* trapa #3 */
Where did this come from?
++ How can I single step over an instruction? ++
Again there's no hints in the assembler manual. I don't know that its
even possible on this chip.
The only ideas I've come up with are:
. Use a JMP instruction instead of a trap. Instead of vectoring
through an interrupt, it would JMP straight to my trap handler. This
is difficult, since JMP requires 4 bytes where trap only requires
2. I'd have to find somewhere to stash the extra 2 bytes so that they
can be restored after the bp.
. Use a JMP instruction instead of a single-step. This means
disassembling opcodes to find the offset to the next instruction.
. Do something with the built-in hardware interrupts, such as timers
etc. Hopefully a two-byte opcode would cause an interrupt to be
raised immediately the current instruction completes (emulating a
trap), or after the next instruction completes (emulating a step).
You suggestions would be most welcome!
--
===========================================================================
Les Smithson, Open Network Solutions Ltd, London, England
lsmithso@hare.demon.co.uk http://www.hare.demon.co.uk
PGP: 2B83E8A5/21 89 33 D0 53 45 59 B9 A6 4E 0A A5 62 EF CB FB
|
|
Message has 1 Reply:
 | | Re: gdb & legOS
|
| Hi Les, I've been advocating gdb for quite some time now, great to hear about your efforts. Les Smithson schrieb: (...) My manual says opcodes 0x57nn are unallocated on H8/300. Could this be a Super-H opcode? H8 gdb seems to be tinted in favour of (...) (25 years ago, 18-Feb-00, to lugnet.robotics.rcx.legos)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
