Re: [Simulavr-devel] modification of AVR simulator for SCA

[Petr Hluzín]

On 10 February 2016 at 17:50, Klaus Rudolph <address@hidden> wrote:

> The problem with the thread I can't explain. I never looked in that code and 
> I have no idea what the tread is good for while accessing registers. Maybe 
> this stuff can also be removed...
>
> Maybe someone else can give some hints especially for this "mystery" 
> threading things?
>

The ThreadList class watches writes to SPH and SPL and maintains a
simple state machine that allows it to distinguish:
(a) writes that grow or shrink a stack
(b) writes that initialize stack pointer in libc's startup code
(c) writes that switch stack to a different thread when the simulated
application uses an RTOS.

Simulavr then reports the detected call stacks as threads to GDB and
you can type "thread apply all backtrace" to see call-stacks of the
non-running threads.

Unfortunately GDB's code for unwinding stack is weaker than I
anticipated and the RTOSes I investigated do nonsensical stuff to SP
(in addition to switching threads) confusing the state machine, so the
feature is mostly useless right now. I guess you can rip it of from
the sources.


Regarding the assertion: assert(0 != SP_value)

Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself. Therefore the line should not be an
assertion, it should print a message and pause simulation to allow
user to investigate using GDB. However, as you can see from the
backtrace, the situation is detected quite deep in simulavr and we
have no mechanism to report breakpoints from such depth.

(Also we do not have a mechanism to report multiple
breakpoints/problems triggering on the same instruction, imagine e.g.
an instruction execution accesses memory watched by gdb, a peripheral
detects something wrong at the same time and the next instruction has
an ordinary gdb breakpoint, etc. It is a nice capability to have,
would solve the problem of reporting a problem from the depth.)


Nikita wrote:
> If I do something like that on AvrDevice::GetIOReg it changes the
> behaviour of the program when I test it:
> only each 2nd character entered by the used is actually handled by the
> program
> (I am testing it on examples/simple_ex1 that is also on the website).
> I found a hack to me it work for AvrDevice::GetIOReg by just reading the
> value once in a tmp variable and then using it
> in my leakValue funciton and in the return, like that:

This is because calling RWMemoryMember::operator unsigned char() has a
side-effect of removing a byte from UART peripheral.

IMHO simulavr over-uses operator overloading. The code would be easier
to read if the various operators were changed to a named function. (I
am not against operator overloading in general. They do have a place -
when they are used often enough and when their semantics is obvious
enough.)

Also src/cmd/gdbserver.cpp need to read memory without causing
side-effects (or prevent reading the byte). This is not fixed.