Re: [pushed] [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp

[Luis Machado <luis.machado@arm.com>]

On 2/8/23 15:38, Tom de Vries wrote:
> On 2/8/23 15:51, Luis Machado wrote:
>> On 2/8/23 14:48, Tom de Vries wrote:
>>> On 2/8/23 14:27, Luis Machado wrote:
>>>> Hi Tom,
>>>>
>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>
>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>
>>> Hi,
>>>
>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>
>>
>> Alright. That's good to know.
> 
> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.

I did a brief investigation on this one, and gdb seems to be doing something strange.

For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:


(gdb) info source
Current source file is longjmp.c
Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
Contains 82 lines.
Source language is c.
Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
  -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
tection.
Compiled with DWARF 4 debugging format.
Does not include preprocessor macro info.
(gdb) b 69
Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
tsuite/gdb.base/longjmp.c, line 69.
(gdb)

And for Ubuntu 22.04:

(gdb) info source
Current source file is ./setjmp/longjmp.c
Compilation directory is ./setjmp
Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
Contains 82 lines.
Source language is c.
Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
on.
Compiled with DWARF 5 debugging format.
Does not include preprocessor macro info.
(gdb) b 69
No line 69 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.

What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.

Investigating further, if you "list", it will output the sources from the testcase file as well.

Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.

I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
and which one to use for various commands.

I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.

Maybe we just uncovered a new bug with source handling.