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

[Tom de Vries <tdevries@suse.de>]

On 2/8/23 19:06, Luis Machado wrote:
> 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.

I suspect the FAILs will disappear if we replace "break <n>" with "break 
$srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.

Please file a PR and attach the entire gdb.log, I want to take a look at it.

Thanks,
- Tom