Testing gdb/monitor.c

Testing gdb/monitor.c

[Pedro Alves]

Guys,

 If I wanted to do some changes to the monitor target(s) (monitor.c),
what's the best and easiest way to test them?  I never used this
target before.  Do I need hardware for that, or is there
some (maintaned) --target that uses it with a simulator?  Or?

-- 
Pedro Alves

Re: Testing gdb/monitor.c

[Michael Snyder]

On Thu, 2008-07-03 at 14:59 +0100, Pedro Alves wrote:
> Guys,
> 
>  If I wanted to do some changes to the monitor target(s) (monitor.c),
> what's the best and easiest way to test them?  I never used this
> target before.  Do I need hardware for that, or is there
> some (maintaned) --target that uses it with a simulator?  Or?

Hmmm...

The "monitor" target is for debugging a "bare metal" development
board that has no operating system, and doesn't even have a gdb
"stub" that can communicate using the remote protocol.

It works by sending "rom monitor" type commands and interpreting
their output.

Such a system is unlikely to implement threads.
I understand your desire to canonicalize target thread behavior, though.

I don't know of any way to test the monitor target, except 
by using real hardware that has a rom monitor for which gdb
has a syntax spec.

It would certainly be possible to construct a gdbreplay-like
software emulation that would mimic a monitor target, but you
would still need a real one from which to record some sessions.

The return on investment would probably be small, though...
;-/

Michael

Re: Testing gdb/monitor.c

[Pedro Alves]

Thanks Michael,

On Thursday 03 July 2008 19:57:54, Michael Snyder wrote:
> On Thu, 2008-07-03 at 14:59 +0100, Pedro Alves wrote:
> > Guys,
> >
> >  If I wanted to do some changes to the monitor target(s) (monitor.c),
> > what's the best and easiest way to test them?  I never used this
> > target before.  Do I need hardware for that, or is there
> > some (maintaned) --target that uses it with a simulator?  Or?
>
> Hmmm...
>
> The "monitor" target is for debugging a "bare metal" development
> board that has no operating system, and doesn't even have a gdb
> "stub" that can communicate using the remote protocol.
>
> It works by sending "rom monitor" type commands and interpreting
> their output.
>
> Such a system is unlikely to implement threads.
> I understand your desire to canonicalize target thread behavior, though.
>
> I don't know of any way to test the monitor target, except
> by using real hardware that has a rom monitor for which gdb
> has a syntax spec.
>
> It would certainly be possible to construct a gdbreplay-like
> software emulation that would mimic a monitor target, but you
> would still need a real one from which to record some sessions.
>
> The return on investment would probably be small, though...
> ;-/

"probably"?  :-)

-- 
Pedro Alves