RE: [PATCH 2/2 version 2] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

Carl Love via Gdb-patches
2023-01-19T16:57:00Z

Bruno:

On Thu, 2023-01-19 at 09:04 +0100, Bruno Larsen wrote:
> On 18/01/2023 23:26, Carl Love wrote:
> > Not sure what more I can do at this point. If you have some time,
> > can
> > you take a look at the failures on your machine and let me know
> > what
> > you are seeing. Maybe we can figure out what is going on.
> >
> > Perhaps Bruno can also check to see if the two tests were ran on
> > his
> > machine. If not, hopefully the info above will help Bruno to get
> > the
> > tests to run on his machine and we can see if they fail there as
> > well.
>
> I just tried running the gdb.btrace/rn-dl-bind.exp and also got 9
> passes, so I cant help there, but I did miss the 2 failures in
> tailcall.exp; here's the relevant log:
>
> Breakpoint 1, main () at tailcall.c:37
> 38 answer += 1;
> (gdb) PASS: gdb.btrace/tailcall.exp: next.1
> reverse-next
> foo () at tailcall.c:29
> 29 return bar ();
> (gdb) FAIL: gdb.btrace/tailcall.exp: reverse-next.1
> step
> bar () at tailcall.c:24
> 24 }
> (gdb) FAIL: gdb.btrace/tailcall.exp: step.1
> finish
>
> Some extra context, line 37 (the line that is being "undone" by
> reverse-next) has a call to foo, which calls bar. Whats going on here
> is
> that we're hitting the step-resume breakpoint when exiting the bar
> call,
> instead of when exiting the foo call.Has a very similar smell to the
> type of bug I fixed in commit
> 1f3e37e057e876b37db49dbd8ed5ca22c33f6772,
> but that fix itself might not work because of tailcall optimizations.
>
> If you have the test compiled, you can trigger the bug using regular
> record, no need to use btrace specifically.

Thanks, I went back and tried the tailcall again. I was able to get it
to generate 2 fails on my laptop with just the X86 patch. Not sure why
I didn't see that before, maybe I had a typo??? I did note that git
on my laptop seems to act a bit weird so maybe that was an issue?? I
am having to double check the code changes after running git to make
sure it applied the changes correctly. Not sure why I didn't see the
passes in the full regression suite either. Anyway, I am looking to
see if I can figure out what the regression issue is for this test.

The gdb.btrace/rn-dl-bind.exp test still runs fine with 9 passes.

Carl