From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 1089E3840C23 for ; Fri, 19 Jun 2020 12:36:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1089E3840C23 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id DBE6B8370E; Fri, 19 Jun 2020 14:36:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyqkRgaHETuY; Fri, 19 Jun 2020 14:36:08 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbb33.dip0.t-ipconnect.de [79.221.187.51]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 5F4AD83070; Fri, 19 Jun 2020 14:36:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1592570168; bh=Dgcm/cSaIoRUxAJKoCsF4H8do1CtXRYzrIPwbspW/vU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cGpdUZGWgzXyVVi1sz7tzJF+ehdBPWgV56elr27Cn0OijoZgvkYMRI+0KZoMC664W eFpnDAgWHtlu3opWsAszZAvv5qhJ6ohlzK65wSIdvqaZcl+g43mhk+nBEqlhK623nY OU0jpiIyYJFzewmQGAXO2L+hwYQVKFA0/qNw7EyOdyAUuKnuMXffZ2kih0NEnzUAwy UE/J+2kRZK/Y//xZnBiB93bT+y1u5/EPW04zH9rGsZxu7QDOyH2d3WIWEcgbY0BIV8 fSQf41US+6Zi1IaoQk3VtYiC69QGvBHhEkbYpxNiSs8bFrm0YkAZTA53/mWv/929qI fdsxPrGrqaP6w== From: Rainer Orth To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: Unbreaking gdb on Solaris post-multitarget [PR 25939] References: <7fb790ae-61a9-a6a3-3b87-74fcac400664@redhat.com> <0e3e81a9-a5de-42bc-7d58-094f2adca164@redhat.com> Date: Fri, 19 Jun 2020 14:36:07 +0200 In-Reply-To: (Pedro Alves's message of "Thu, 18 Jun 2020 16:51:49 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3791.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 19 Jun 2020 12:36:12 -0000 Hi Pedro, > On 6/18/20 3:55 PM, Pedro Alves via Gdb-patches wrote: >> On 6/17/20 3:45 PM, Rainer Orth wrote: >>> [Thread debugging using libthread_db enabled] >>> [New Thread 1 (LWP 1)] >>> Breakpoint 1 at 0x401036: file hello.c, line 6. >>> bottom-gdb.gdb:3: Error in sourced command file: >>> procfs: couldn't find pid 0 in procinfo list. >> >> I see what this is. This is procfs_target::wait relying on >> inferior_ptid. Since the multi-target series, inferior_ptid >> is null_ptid before we call target_wait: >> >> static ptid_t >> do_target_wait_1 (inferior *inf, ptid_t ptid, >> target_waitstatus *status, int options) >> { >> ptid_t event_ptid; >> struct thread_info *tp; >> >> /* We know that we are looking for an event in the target of inferior >> INF, but we don't know which thread the event might come from. As >> such we want to make sure that INFERIOR_PTID is reset so that none of >> the wait code relies on it - doing so is always a mistake. */ >> switch_to_inferior_no_thread (inf); >> >> >> I'm working on a patch. I'd identified procfs_target::wait as the cause of the find_procinfo_or_die call with pid = 0 by adding a sleep call in the latter and attaching gdb to look where I am, but hadn't gotten further yet. > Here it is. This works for me on a Solaris 11.3 (virtual and slow...) machine. I'd meant to suggest trying gcc211 in the GCC compile farm, but the machine was quite busy when I looked/tried, lacked some vital software (bison, patch, makeinfo, make only as gmake, gcc 5.5.0 only which may or may not work). I've built those myself and managed a gdb build, too, but the experience wasn't too pretty: not what I'd want to work with as a developer on a foreign platform meant to support gcc/gdb/binutils... > Debugging GDB itself works for me, and I've checked that the gdb.base/break.exp > testcase passes cleanly, at least. > > Your push_target fix is still necessary, FAOD. Should I push it as is (with an appropriate description, of course) or would the code change need a comment, too? > Could you give it a try? I did so now, both on amd64-pc-solaris2.11 (Solaris 11.4), and sparcv9-sun-solaris2.11 (Solaris 11.3, gcc211 above). gdb basically works again, but compared to the pre-multi-target results I have still a considerable number of regressions: before: # of expected passes 62928 # of unexpected failures 1841 # of unexpected successes 4 # of expected failures 49 # of unknown successes 6 now: # of expected passes 63768 # of unexpected failures 2411 # of expected failures 52 # of unknown successes 1 Of course there's months of gdb development between the two, but e.g. I see 268 /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:336: internal-error: thread_info::thread_info(inferior*, ptid_t): Assertion `inf_ != NULL' failed. 119 /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:86: internal-error: thread_info* inferior_thread(): Assertion `tp' failed. 88 /vol/src/gnu/gdb/hg/master/local/gdb/inline-frame.c:384: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_stacore LWP 1 In: ' failed. compared to previous 487 /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed. 72 /vol/src/gnu/gdb/hg/master/reghunt/gdb/inline-frame.c:367: internal-error: void skip_inline_frames(thread_info*, bpstat): Assertion `find_inline_frame_state (thread) == NULL' failed. Some of those are definitively regressions, although it's difficult to say with the flaky nature of several tests on Solaris. Whatever the case, it looks like I have months of work ahead ;-) Thanks a lot for fixing this. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University