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

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

On 2/9/23 17:44, Luis Machado wrote:
> On 2/9/23 14:34, Luis Machado via Gdb-patches wrote:
>> On 2/9/23 12:19, Tom de Vries wrote:
>>> On 2/9/23 12:58, Luis Machado wrote:
>>>> On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
>>>>> On 2/8/23 20:36, Tom de Vries wrote:
>>>>>> 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.
>>>>>
>>>>> I suppose. But it seems there is a different underlying issue of 
>>>>> gdb getting confused about what is the current source file.
>>>>>
>>>>>>
>>>>>> Please file a PR and attach the entire gdb.log, I want to take a 
>>>>>> look at it.
>>>>>
>>>>> Will do.
>>>>
>>>> Looking around I found 
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems 
>>>> to indicate some confusing cases aren't really a bug.
>>>
>>> Does that mean you're not planning to post the gdb.log?
>>>
>>
>> No. I was creating a new bug when I stopped to read the above one.
>>
>> I currently have a different set of tests on the logs. I'll reproduce 
>> the gdb.base/longjmp.exp FAIL's again and will attach to a new bug. 
>> Then we can
>> decide it is a duplicate or not.
> 
> Done now: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
> 

Ack, understood, thanks for posting it.

I've submitted a patch here ( 
https://sourceware.org/pipermail/gdb-patches/2023-February/196807.html ).

Thanks,
- Tom