From: Tom de Vries <tdevries@suse.de>
To: Luis Machado <luis.machado@arm.com>, gdb-patches@sourceware.org
Subject: Re: [pushed] [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp
Date: Thu, 9 Feb 2023 13:19:34 +0100 [thread overview]
Message-ID: <34948fdd-acd2-7dee-dbd2-b5c7e7734c71@suse.de> (raw)
In-Reply-To: <943e3c5c-091b-5a15-881d-58bf360d2d96@arm.com>
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?
Thanks,
- Tom
next prev parent reply other threads:[~2023-02-09 12:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 12:46 Tom de Vries
2023-02-08 13:27 ` Luis Machado
2023-02-08 14:48 ` Tom de Vries
2023-02-08 14:51 ` Luis Machado
2023-02-08 15:38 ` Tom de Vries
2023-02-08 18:06 ` Luis Machado
2023-02-08 20:36 ` Tom de Vries
2023-02-09 10:37 ` Luis Machado
2023-02-09 11:58 ` Luis Machado
2023-02-09 12:19 ` Tom de Vries [this message]
2023-02-09 14:34 ` Luis Machado
2023-02-09 16:44 ` Luis Machado
2023-02-10 11:09 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=34948fdd-acd2-7dee-dbd2-b5c7e7734c71@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).