From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112404 invoked by alias); 21 Jan 2016 15:10:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 112388 invoked by uid 89); 21 Jan 2016 15:10:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:interrupted-hand-call.exp, popped, communication, UD:gdb.threads X-HELO: mail-pf0-f179.google.com Received: from mail-pf0-f179.google.com (HELO mail-pf0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 21 Jan 2016 15:10:19 +0000 Received: by mail-pf0-f179.google.com with SMTP id n128so24841099pfn.3 for ; Thu, 21 Jan 2016 07:10:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; bh=ihpdZOWO+xXjjfS2OPRoVxCFIZmqR7kxzwpAuFJEWh4=; b=L9uDrziLRTeu8MefHWfdJ0Ox++ji3A59kixQfIsOnYjCuDrvlxF3riozP3xvjcf4Eh Paay3uDMpI97T++URN3lqGReN4rM5jCCrFZCSkZhcojaE0gp2/WBIHYA+tuRLVaNnQZe Da9DP1xz1/BWd0X157bwlmPPNaZNMcIM0l5v6PZqoRdz7qFArzQhryhm2nT5Ew4eDLCC gJ/LxDiwZH4V8HyPdr9+Mli3Hye7rY3lMiTjrUG5w/DoxvL8l/nvRC2LqN67Ebfp14na AhQWqhhz6ImTh8Qb6V22i/IcgIqr7OwESAJKdWAaqJ585bIlXOE2vMww5g3Bw99gRuX4 Vv0Q== X-Gm-Message-State: ALoCoQn8RrNd8hGM5ifnruEYpI55m0JvQoPH7qwERET4GUGpdoP+rxm1GWvdV24KRtBO1x6Mf6MWajSIER3CmZx8LTxsuiUF1Q== X-Received: by 10.98.18.89 with SMTP id a86mr60788064pfj.143.1453389017606; Thu, 21 Jan 2016 07:10:17 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id v7sm3315655pfa.77.2016.01.21.07.10.14 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 21 Jan 2016 07:10:16 -0800 (PST) From: Yao Qi To: Joel Brobecker Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: one week to go until GDB 7.11 branch creation... References: <20160118034414.GG4059@adacore.com> <86fuxsrz38.fsf@gmail.com> <20160121100545.GB5146@adacore.com> Date: Thu, 21 Jan 2016 15:10:00 -0000 In-Reply-To: <20160121100545.GB5146@adacore.com> (Joel Brobecker's message of "Thu, 21 Jan 2016 14:05:45 +0400") Message-ID: <8637trrmss.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00532.txt.bz2 Joel Brobecker writes: >> - some fails in test cases added by fort_dyn_array patch on some OS and >> targets. I reported them here >> https://sourceware.org/ml/gdb-patches/2016-01/msg00467.html >> and the original patch is >> https://sourceware.org/ml/gdb-patches/2015-10/msg00085.html > > For those, do they only affect Fortran, by any chance? If it is > not a regression, then let's make this a non-blocking known issue. > (communication between the author and myself has been infrequent, > mostly my fault, but we may not get an answer in the near future). As far as I can see, they only affect Fortran. If the author or someone else can't fix them before release, why do we still ship them in the release? Can't we revert the patch? Since they were added three months ago, it shouldn't be hard to remove them. > >> - PR 19491, fail in gdb.base/multi-forks.exp > > Looks like an issue with the test itself, rather than a regression? No ideas without further analysis. > >> - GDB sets breakpoint on the wrong place, if the file basename is >> identical to the current file basename. PR 19474. >> I posted a patch >> https://www.sourceware.org/ml/gdb-patches/2015-12/msg00321.html >> but it causes a regression. > > This one is indeed annoying. What's the status? Looks like you are > saying the patch you suggested introduces a regression too? Correct. > > Let's put it on the "blocking for branching" list for now. > The idea would be: either we fix it before branching, or alternatively > we branch, but only after knowing that the fix will likely be > reasonable for backporting. OK. >> - A fail in gdb.threads/interrupted-hand-call.exp >>=20 >> $ make check >> RUNTESTFLAGS=3D'--target_board=3Dremote-gdbserver-on-localhost >> interrupted-hand-call.exp' >>=20 >> (gdb) PASS: gdb.threads/interrupted-hand-call.exp: dummy frame popped >> continue^M >> Continuing.^M >> FAIL: gdb.threads/interrupted-hand-call.exp: continue until exit (time= out) >> Remote debugging from host 127.0.0.1^M >> ptrace(regsets_fetch_inferior_registers) PID=3D9710: No such process^M >> ptrace(regsets_fetch_inferior_registers) PID=3D9710: No such process^ >>=20 >> I suspect it is about a GDB PR about disappeared inferior, but I can't >> find the PR in bugzilla. I'll look into it. > > A little confusing, at the very least, but if the program did terminate, > I would say this issue is not blocking for the release. WDYT? I am afraid not, the program didn't terminate, at least there is one thread, as far as I can tell. Again, nothing useful to say here without further analysis. PR 19508 is opened to track it. I set the target milestone of PR 19491, PR 19474, and 19508 to "GDB 7.11", so I don't write them down in the wikipage again. --=20 Yao (=E9=BD=90=E5=B0=A7)