From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8gn+A9sH5GNZfy0AWB0awg (envelope-from ) for ; Wed, 08 Feb 2023 15:36:43 -0500 Received: by simark.ca (Postfix, from userid 112) id F0AFD1E15D; Wed, 8 Feb 2023 15:36:42 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=Wmz5OnvR; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2E8961E110 for ; Wed, 8 Feb 2023 15:36:42 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C2F3C3858C53 for ; Wed, 8 Feb 2023 20:36:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C2F3C3858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675888601; bh=3A7WQzp5Qxxl/RWDvZslb97rm0t9JIoedRYV8lqbhw4=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=Wmz5OnvRpN024tbdIve4U0G8Q2BWQiuHEbY490FKEtpfnV3MfJ2R6xm3kHg2aVHKW QR2VWVs7DvYCS4CJhveO3Pcfevd1WFdlwcGdEoAYFQaFWWySDVV3iG3hzWUs25n6no gx+3irJt83j0MHh/OLvwp5hlpJXJyahPX6pMPrlQ= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 65B6D3858D20 for ; Wed, 8 Feb 2023 20:36:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 65B6D3858D20 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 83812208C6; Wed, 8 Feb 2023 20:36:20 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 70A231358A; Wed, 8 Feb 2023 20:36:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 0XNyGsQH5GO8MgAAMHmgww (envelope-from ); Wed, 08 Feb 2023 20:36:20 +0000 Message-ID: <53610c56-49e5-643d-b44a-abe70821e7be@suse.de> Date: Wed, 8 Feb 2023 21:36:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [pushed] [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp To: Luis Machado , gdb-patches@sourceware.org References: <20230208124652.29570-1-tdevries@suse.de> <23f68beb-39c5-33c8-2d2d-f076192d2648@suse.de> <57277a06-0a9c-e731-beee-1f6d0e88ea6f@arm.com> <2503e9bb-78d0-52ab-71b3-3c8fe6c9415d@arm.com> Content-Language: en-US In-Reply-To: <2503e9bb-78d0-52ab-71b3-3c8fe6c9415d@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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 " with "break $srcfile:". 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