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

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

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