Description Didier Brachet 2012-10-17 10:38:59 EDT

Build Identifier: 

First of all, sorry for the pretty long description but I see various related problems.

I am currently looking at fixing some issues we have with reverse
run-control support in TCF agent (we are using Simics simulator). While
looking into this, there are a couple of questions/issues that have been raised:

If my understanding is correct, when doing reverse stepping over a "C"
line, the sequence looks like this (at least in simple case):

Let's consider we have a "C" source code made of three lines (no branch
in this code):

void mytest() {
foo1();
foo2();
foo3();
}

and that current program counter is on third line (call to foo3). To do a reverse next line (reverse step over line 2), the TCF run-control code does:

1 - We reverse step until we step-out "line 3"
2 - When this is completed, we detect that we have stepped-out the line but that we are not at the beginning of a "C" line (we are at the end of "line2". To fix this, we (reverse) step-out "line 2"
3 - We have stepped "line 2" and we are now at the end of "line 1", we now step forward until we enter again "line 2"

That works in most cases but I was wondering why we do not optimize the
code to avoid the step 3 in most cases. To do this, it seems to me it would
be enough to increment the start address of the step range we compute in
step 2 (note that this applies only to reverse stepping). In this case,
in most cases, at the end of "step 2" we would be at the beginning of
"line 2" and reverse-next would be done. There may be some cases, where
we will exit line 2 without going back to the first instruction but this
would be handled by the "old" algorithm, I don't think we would break
anything by adding this code.

Note that this is not really a bug but I think it would be a nice and easy improvement and it would partially fix the second issue I have.

I have a second issue with the current code, in update_step_machine_state() routine. In my case, when I try to do a reverse step over "line 2", it does not work. The issue I have is that step 3 (as described above) is not properly handled because we detect that the line we are currently in is the function prologue (and thus we do not increment ext->step_line_cnt).

If I try to reverse step-over line 1, the I get another different issue (but same result) because in step 2 I detect current line is a function prologue. 

What I don't understand is why we do not increment ext->step_line_cnt when we detection that the current line is a function prologue; that would solve the first case but I am not sure of what could be the side effect of doing this. For the 2nd case (trying to reverse step over the 1st line of the source code), I think this fix + the optimization I describe above should work (the optimization will allow not stepping out of the current routine which may cause issues -if the code we would execute otherwise is not built with debug info-).

I can work on those fixes but I would first like to make sure I don't miss anything and that we agree on the potential fixes.

I have another (the last one) issue that is mostly related to reverse stepping. This issue is specific to PowerPC support. Because of the way we implement reverse-stepping, we often try to get the stack trace of a function while it is executing the last instruction of a function (this is at the end of a reverse-step-out if the previous line was a function call). The issue we have with PPC & GNU compiler (at least the version I use) is that debug information are incorrect when we are in the epilogue of a function (it is okay when PC is at the beginning of the epilogue, not when it is at the end). In this case, the stack walking code reports an invalid stack frame (incorrect return address) but does not report any error and this breaks run-control step line support. I have added a work-around to skip the function epilogue (similarly to what is done to skip the buggy prologue); I don't know if we can add this kind of architecture specific "fix" in generic code...

Regards


Reproducible: Always

Steps to Reproduce:
See description