[Bug record/29721] [gdb, record, aarch64] FAIL: gdb.reverse/solib-precsave.exp: reverse-next third shr1

["vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29721

--- Comment #31 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to B. Larsen from comment #30)
> > Say we assume that they are equal if the target contains an epilogue unwinder, but if not, we're handling things more conservatively.  This kind of fix could be backported to fix the regression that was introduced.
> 
> This sounds ok, but I wonder if "handling things more conservatively" will
> regress
> [record/16678](https://sourceware.org/bugzilla/show_bug.cgi?id=16678). To
> fix that bug I assumed that we knew the frame ID would be the same
> throughout the whole function. If we can't rely on that, how are we supposed
> to detect a breakpoint being hit in a recursive call?

Well, you've fixed that problem for a recursive function with debug info, and
for x86_64 without debug info (meaning, also using
-fno-asynchronous-unwind-tables to make sure there's no cfi directives).

On aarch64 though, I see:
...
$ cat test.c
extern int factorial (int x);
int v;
int main() {
  v = 1;
  factorial(5);
  return 0;
}
$ cat test2.c
int factorial(int x) {
  if (x == 1) return 1;
  int result = x * factorial(x-1);
  return result;
}
$ gcc test2.c -c ; gcc test.c test2.o -g
$ gdb a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x40056c: file test.c, line 4.
Starting program: a.out 

Temporary breakpoint 1, main () at test.c:4
4         v = 1;
(gdb) record
(gdb) next
5         factorial(5);
(gdb) next
6         return 0;
(gdb) reverse-next
0x00000000004005d4 in factorial ()
(gdb) 
...

This is essentially the same problem as in this PR ... and I'm proposing that
we fix it, in a target-independent fashion.

I think the following cases can be distinguished:
- cfi info present, assume frame ID's accurate, no special handling needed
- cfi info not present, but target has an epilogue unwinder , assume frame
  ID's accurate, no special handling needed
- cfi info not present, no epilogue unwinder. Special handling needed,
  but no need to worry about breaking handling of recursive function,
  because it's already broken, and the special handling intends to fix it.

My naive idea on how to approach this was to instead of doing a step-resume
breakpoint at the last insn and resume, do first a single step back, and then
insert the step-resume breakpoint and resume.  This will already fix the
aarch64 case.  There may be cases where this gives the wrong answer, but AFAIU
those cases are broken anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.