From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 947963858C50 for ; Thu, 9 Feb 2023 12:19:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 947963858C50 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de 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-out1.suse.de (Postfix) with ESMTPS id D0E25372C3; Thu, 9 Feb 2023 12:19:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1675945174; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AhUlM3aIrB7xUFxkiwW+kVFCyZPWe8Y7xSqb8/zGmRc=; b=ia0fh39IfIb+yef6bdN9HHiSGHZUd1KyDgzojxkUdezYkpiuKUUZlKVQl+ajV6PbRa8mtn 7KEUwHkC90LtPcOyXXPNP9MwCTWTYj6e4CRE5Ue1xPzV/GiQSAeQG1ZTRVdVX4CSos95Jg Wno90VOp9cb55j9tZaNOF2bw/ttkRmg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1675945174; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AhUlM3aIrB7xUFxkiwW+kVFCyZPWe8Y7xSqb8/zGmRc=; b=8vCg7/MKGZsY0CNkWT5fjBsACcPAekje4tEblNihokLBZ5TMBCsAELX+ipthSGsDZXTcP6 p2R5sA7r8otvGEAw== 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 BB989138E4; Thu, 9 Feb 2023 12:19:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +vaiLNbk5GPwUwAAMHmgww (envelope-from ); Thu, 09 Feb 2023 12:19:34 +0000 Message-ID: <34948fdd-acd2-7dee-dbd2-b5c7e7734c71@suse.de> Date: Thu, 9 Feb 2023 13:19:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [pushed] [gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp Content-Language: en-US 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> <53610c56-49e5-643d-b44a-abe70821e7be@suse.de> <70bee05b-f07b-8fe8-d766-dfbefff244dc@arm.com> <943e3c5c-091b-5a15-881d-58bf360d2d96@arm.com> From: Tom de Vries In-Reply-To: <943e3c5c-091b-5a15-881d-58bf360d2d96@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 " with >>> "break $srcfile:".  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