Re: [Simulavr-devel] [PATCH] Add BREAK-instruction, causes simulavr to halt.

[Petr Hluzín]

On 30 December 2011 12:21, Klaus Rudolph <address@hidden> wrote:
> Hi,
>
> I can't see a reason to add a pseudo break instruction. Breakpoints handled 
> in simulavr with a address table which works together with gdb.

Breakpoints are usually planted at places that are interesting to a
programmer. Usually a programmer has its own idea which places are
important and sets them through debugger. Sometimes a library knows
that a place is important (e.g. when an argument is out of range,
invoking an operation while in invalid state). Essentially an
assertion.

Maybe we should implement some other mechanism instead of or in
addition to break-instruction. For example avrtest [1] will terminate
the program if execution reaches exit(), abort(), or endless loop with
interrupts disabled. Nevertheless the instruction is already
documented by Atmel.

(Break instructions are also used in JTAG debugging - ICD peripheral
can add only ~4 hardware-accelerated breakpoints.)

> To stop the execution of simuavr without gdb there is already a command line 
> option.

Yes, but it is more difficult to coordinate various libraries in user's program.

> Building different binaries for real target and simulation is exactly the 
> opposite of what I prefer :-)
>

Yes, having a separate build is a pain. However currently users have
to mock-up hardware circuits in software and I would like to implement
simulating more hardware lessen the need.

However if user is willing to have separate builds then simulavr can
provide (with cooperation from user's libraries):
* detect stack-heap collision
* detect stack overflow
* detect using freed/unallocated memory
** possibly create a functionality similar to memory protection unit
(MMU, or MPU)
* better thread view
* deadlock detection (lock hierarchy violation)
* executing marked debugging code in zero time (peripheral time stopped)
* etc. Ideas?

Personally I would recommend three build targets to reap all the
benefits: release build (with no debugging code, with extra
optimization), debug build (with debugging code - I use that a lot,
almost no optimization), build for simulator (with debugging code -
including a code which depends or a simulator, mock-ups for
non-simulated hardware). Obviously one can build other combinations if
needed.

[1] http://winavr.cvs.sourceforge.net/viewvc/winavr/avrtest/

-- 
Petr Hluzin