| |
> > > > > "Markus" == Markus L Noga <markus@noga.de> writes:
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> (it's only two bytes long) and use the task
Markus> scheduler. That would render waiting for a breakpoint to
Markus> occur very easy - just do a wait_event on *(unsigned
Markus> short)(other_ip)==ENDLESS_LOOP_INSN.
I'm not sure I follow this. My understanding is that that a task can
wait on another task to return a status. This other task spins on some
variable. How does his help here?
While trying to work this one out, another idea occurred to me. Is this
what you had in mind? Do you think this would work?
. Insert a 'bra #0' at the breakpoint.
. When this breakpoint is hit, the task goes into an infinite loop.
. A timer interrupt eventually occurs and tm_scheduler(old_sp) is
called.
. tm_scheduler is modified such that it examines the stack frame, and
if the instruction that was just interrupted was a 'bra #0' (0x0400,
I think), then call the breakpoint handler.
. The breakpoint handler sends a message to the host via lnp.
. If the program is to be continued after the breakpoint, the old
instruction is restored and tm_scheduler returns as normal.
A global flag is needed to prevent other tasks scheduling while in the
trap_handler.
The same 'bra #0' mechanism can be used for single-stepping, observing
your note about branches etc.
The other thing I'll have to be careful of is lnp. These need to be
made synchronous such that it doesn't depend on multi-tasking.
Markus> Naturally, you'd loose the ability to debug some parts of
Markus> the kernel that way.
But the kernel works, so why debug it!
--
===========================================================================
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 is in Reply To:
 | | 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
|
|
|
|
