[gdb/testsuite] Fix linespec ambiguity in gdb.base/longjmp.exp

PR testsuite/30103 reports the following failure on aarch64-linux
(ubuntu 22.04):
...
(gdb) PASS: gdb.base/longjmp.exp: with_probes=0: pattern 1: next to longjmp
next
warning: Breakpoint address adjusted from 0x83dc305fef755015 to \
  0xffdc305fef755015.
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xffdc305fef755015

__libc_siglongjmp (env=0xaaaaaaab1018 <env>, val=1) at ./setjmp/longjmp.c:30
30	}
(gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
  (PRMS: next over longjmp)
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break 63
No line 63 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint \
  at pattern start (got interactive prompt)
...

The test-case intends to set the breakpoint on line number 63 in
gdb.base/longjmp.c.

It tries to do so by specifying "break 63", which specifies a line in the
"current source file".

Due to the KFAIL PR, gdb stopped in __libc_siglongjmp, and because of presence
of debug info, the "current source file" becomes glibc's ./setjmp/longjmp.c.

Consequently, setting the breakpoint fails.

Fix this by adding a $subdir/$srcfile: prefix to the breakpoint linespecs.

I've managed to reproduce the FAIL on x86_64/-m32, by installing the
glibc-32bit-debuginfo package.  This allowed me to confirm the "current source
file" that is used:
...
(gdb) KFAIL: gdb.base/longjmp.exp: with_probes=0: pattern 1: gdb/26967 \
  (PRMS: next over longjmp)
info source^M
Current source file is ../setjmp/longjmp.c^M
...

Tested on x86_64-linux, target boards unix/{-m64,-m32}.

Reported-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Tom Tromey <tom@tromey.com>

PR testsuite/30103
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30103

0 files changed, 0 insertions, 0 deletions