| |
Hi Les,
I've been advocating gdb for quite some time now, great to hear about
your efforts.
Les Smithson schrieb:
> 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?
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 that subspecies.
As far as I know, there is no software interrupt or trap instruction at
all. Divide by zero won't work either - it will just set the zero bit of
the condition code. You might try and fiddle with timer interrupts - the
8 bit timers can be set to ratios as high as half the processor clock (4
clocks ^= 1 instruction). One of them generates the IR carrier, but the
other one is only used for sound.
I'd recommend using a jmp instruction directly into your handler. Of
cause, that means backing up four bytes (the vector table for two byte
jumps is in ROM, unfortunately) and dealing with stack issues.
You could also use an endless relative loop instruction (it's only two
bytes long) and use the task scheduler. That would render waiting for a
breakpoint to occur very easy - just do a wait_event on
*(unsigned short)(other_ip)==ENDLESS_LOOP_INSN.
Naturally, you'd loose the ability to debug some parts of the kernel
that way.
> ++ 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.
You cannot single-step. You'll have to figure out the offset of the next
instruction - either from the information gcc gives you, or by analyzing
the actual opcode - and set a breakpoint after it. This is a little
cumbersome for conditional branches (you'll have to put the breakpoint
in the correct branch) and register-relative jumps (you'll have to
figure out the branch target), but it is guaranteed to work.
Determining the length from the opcode should be simple, too - the chip
has to do it at 16 MHz, so it's probably determined by some combination
of bits in the opcode. It doesn't seem to be documented, anyway.
Sorry for my English tonight, I've been writing in German a lot tonight,
and my brain is capable of elegance in one language of a time only.
Night,
Markus.
|
|
Message has 1 Reply:
 | | Re: gdb & legOS
|
| (...) Markus> Hi Les, I've been advocating gdb for quite some time now, Markus> great to hear about your efforts. Hi Markus. Thanks for responding. Your input is much valued. Markus> You could also use an endless relative loop instruction Markus> (...) (25 years ago, 19-Feb-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | gdb & legOS
|
| 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 (...) (25 years ago, 17-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
