Re: [PATCH v2] gdb: fix "frame function" issue when call is last instruction

[Sahil <icegambit91@gmail.com>]

Hi,

Thank you for the review.

On Wednesday, July 3, 2024 7:54:43 PM GMT+5:30 Guinevere Larsen wrote:
> [...]
> I would prefer if you wrote "the last instruction in a frame is a call"
> or something similar. I ask this because when I read the commit message,
> I thought "last instruction" was referring to last instruction executed,
> and couldn't understand  why I couldn't reproduce without __builtin_abort.
> 

Sorry about that. I should have been clearer. I'll modify the commit message.

> > Using "get_frame_address_in_block" instead of
> > "get_frame_pc" resolves this issue.
> > 
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30929
> > ---
> > Changes since v1:
> > * frame-selection-last-instr-call.exp: Modify test to fix regressions on
> > arm/aarch64
> > 
> > Patch v1:
> > https://sourceware.org/pipermail/gdb-patches/2024-June/210251.html
> And responding to your v1 comment about why you created a new test file,
> you mention creating a new C file for this test. Have you tried
> extending the original frame-selection.c file with a new function that
> calls __builtin_abort instead?

I tried extending frame_selection.c initially but I was uncertain about
adding a function that calls __builtin_abort since "main" would never
return. I thought the last statement in main - "return i + j" - also plays
a role in the test.

After taking a look at the test again, I don't think that should cause
a hindrance. I'll experiment with this.

> It seems to me that it should work, and
> you should be able to extend the existing frame-selection.exp file, but
> I might be missing something.
> 
> I would prefer if we just extended the test, instead of added a new one,
> but if I indeed missed something and it isn't as easy to extend it as I
> think, we can have the new test :)
> 

I don't think extending frame-selection.exp should be difficult. I was mainly
unsure about frame-selection.c.

> [...]
> > diff --git a/gdb/testsuite/gdb.base/frame-selection-last-instr-call.exp
> > b/gdb/testsuite/gdb.base/frame-selection-last-instr-call.exp new file
> > mode 100644
> > index 0000000000..5ba52cc069
> > --- /dev/null
> > +++ b/gdb/testsuite/gdb.base/frame-selection-last-instr-call.exp
> > @@ -0,0 +1,130 @@
> > +# Copyright 2024 Free Software Foundation, Inc.
> 
> If we do keep this test, the copyright year should be kept as 2018-2024,
> since the file is very close to an existing file.

Ok, understood.

> [...]
> > +runto_main
> > +gdb_breakpoint abort
> > +gdb_continue_to_breakpoint abort
> > +
> > +gdb_test "bt" "#0  $hex in abort .*#1  $hex in frame_1 .*#2  $hex in
> > main.*" "backtrace at breakpoint"
> Similarly, if we keep this test, I would prefer if this backtrace test
> used the "multi_line". That's because ".*" could eat whole lines, and
> make the test pass when it shouldn't. Something like:
> 
> gdb_test "bt" [multi_line "#0 $hex in abort \[^\\r\\n\]*" "#1 $hex in
> frame_1\[^\\r\\n\]*" "#2  $hex in main \[^\\r\\n\]*"] "backtrace at
> breakpoint"
> 
> (with the appropriate line breaks, also I haven't tested the regexes,
> they probably have some error in them).
> 

Got it. I'll modify this.

Thanks,
Sahil