Re: [Simulavr-devel] Address of breakpoints from source lines

[ThomasK]

Hi Sebastian,

> From looking at this and at example.py, I got the impression that, to
> "continue" from a breakpoint, you must delete it. And to recognize that
> a breakpoint was reached, you test if getCurrentTime returns increasing
> values when you call doRun?

Yes for the first part. No for the second, I use getCurrentTime() in 
assertInitDone only as a failsave point, if the given init breakpoint 
isn't arrived inside a time limit.

> Is there a way to have non-blocking breakpoints, where only a callback
> is called?

No.

The breakpoint handling is "old", means: simulavr is started to support 
a gdb remote interface. Python interface came later to support testing 
and python scripts too. It wasn't the goal to control simulavr complete 
by python and to write, for example, a avr debug application with 
python. Python interface is - similar to tcl interface - a possibility 
to give access to simulavr core.

The gdb uses breakpoints, as I've seen, also in this way: set a 
breakpoint and if arrived, delete it again. That's the reason for this 
implementation. (correct me, if my assumption is wrong)

> What would be the advantage of simulavr-breakpoints over checking PC
> after Step()-ing in single steps in a python script? Better performance
> because the inner loop is completely in C++?

Yes, better performance and you havn't to support 2 different systems. 
But, you CAN do so! (it was also my solution before I've made some 
changes to use the core functionality!)

> In this manual: http://sourceware.org/binutils/docs-2.20/bfd/index.html
> I found a chapter on how to read line numbers from COFF. In the ELF
> backend chapter, there isn't very much:
> http://sourceware.org/binutils/docs-2.20/bfd/elf.html#elf

If BFD hasn't a dedicated interface to such feature, then the task is a 
little bit more complicated. (and it hasn't as I interpret your answer)

For elf you have to seek at first for elf standard, how to extract debug 
information sections and then for dwarf I resp. dwarf II standard, how 
to interpret debug informations. It's some work, but it's possible (I 
had to work with such in a business project)

But the main statement is, it's not a task of simulavr, it's a task of 
your special application. (in the same manner like gdb) So, maybe there 
is a modul in future to read in such informations and to provide it for 
a application, which need it. But it would be wise in my opinion to hold 
it in a separate project.

> My method (Popen avr-gdb) works for me, so I don't have a big need to
> extend simulavr right now. But if more users need this feature (get
> adress of breakpoint by line) it's maybe worth to implement in simulavr.

Why not. Good old unix tradition! And running on a unix os it shouldn't 
be a problem. It dosn't mean, that we tell: no, till the end of all 
time! ;-) Like I wrote before, it's better to separate such 
functionality (adaptions to have a better support are possible, of 
course) to not to get a "eierlegende Wollmilchsau" (in German, because I 
don't know a right term in english)

cu, Thomas