From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id C8D773858D28 for ; Fri, 10 Feb 2023 11:09:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C8D773858D28 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-out2.suse.de (Postfix) with ESMTPS id 117D367496; Fri, 10 Feb 2023 11:09:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1676027344; 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=EEgiZiXpbXiuRz6ULziToHi1hkjxmAVwdn7T4KYNp98=; b=kNI9O2uy2RHFUf47ipkp/4li1nntzncvF5gE6xa19q4OqCG9EoMDnotF/oVx7XmgCmFPih ehLFmLkBbO6JHjFiSCs1o0q4Xdf9qU6vj5/aqCmeO2koRzXi5UgIrAkVn+v/cUcDwuUUM1 4lPvjK5xXrGO5MS1/ICJhXbX8dmXWL4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1676027344; 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=EEgiZiXpbXiuRz6ULziToHi1hkjxmAVwdn7T4KYNp98=; b=Rp9uFCBeAVfG5+37aaZwPQS/c0JPwLofigiOCiO+9+V1YZbmNNixnf8/Vn79/CTar4LpXY z46oD2tyTNY5nkBg== 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 EFEB11325E; Fri, 10 Feb 2023 11:09:03 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id TQclOc8l5mPVXwAAMHmgww (envelope-from ); Fri, 10 Feb 2023 11:09:03 +0000 Message-ID: <1d9739f2-3292-6d37-c22c-9a0e3d26ac87@suse.de> Date: Fri, 10 Feb 2023 12:09:03 +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> <34948fdd-acd2-7dee-dbd2-b5c7e7734c71@suse.de> <81010327-729e-4ac0-66cd-a7eaf97756e4@arm.com> From: Tom de Vries In-Reply-To: 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 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 " 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? >>> >> >> 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