From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28008 invoked by alias); 1 Feb 2020 03:20:58 -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 28000 invoked by uid 89); 1 Feb 2020 03:20:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=quit, bouncing, Pending X-HELO: pb-smtp21.pobox.com Received: from pb-smtp21.pobox.com (HELO pb-smtp21.pobox.com) (173.228.157.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Feb 2020 03:20:56 +0000 Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 6D908B5F88 for ; Fri, 31 Jan 2020 22:20:54 -0500 (EST) (envelope-from jonah@kichwacoders.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=DSjl2RibIkpCZM+f9dhQncuaEjQ=; b=APJGQx u24ntgGeloLzzT+2hN5wkmpTCp0oXEm5r60lCsmkSKp47UnPxqwrqGcC7FOo+uD2 qCtH0F5c85xx56ROQyWbsn29jX2OxJrHfPWPCKfxPwBCKpkm4YOWXvhK0ry+Vf2p Lbae2a7iODpxqYfsZSxmB13NER8P9/SkPArqk= Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id 667CFB5F87 for ; Fri, 31 Jan 2020 22:20:54 -0500 (EST) (envelope-from jonah@kichwacoders.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=kichwacoders.com; h=mime-version:references:in-reply-to:from:date:message-id:subject:to:cc:content-type; s=mesmtp; bh=u/OwxgZ1aiZgZo41/HyJd+s2yWU88WOZg2mTJ5CXLiE=; b=nnnC1g+9UcYn2yvdivcWwqKwSuo3htftUxzrTrM+LMyUTiRsSS71TS+32CjLkBzMY7/IwPi5MBesI4xMiBBIdRfpVawiRmD2WRnG9Nl+L2tev8P/5ULJPgAysJnZClUnGfwP17QiqfDbHY98R8qn63rdjdGGOX6QxsHa6XEgL3o= Received: from mail-qt1-f181.google.com (unknown [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id 2536AB5F86 for ; Fri, 31 Jan 2020 22:20:51 -0500 (EST) (envelope-from jonah@kichwacoders.com) Received: by mail-qt1-f181.google.com with SMTP id v25so7072266qto.7 for ; Fri, 31 Jan 2020 19:20:51 -0800 (PST) MIME-Version: 1.0 References: <20200126114033.GA20733@adacore.com> In-Reply-To: <20200126114033.GA20733@adacore.com> From: Jonah Graham Date: Sat, 01 Feb 2020 03:20:00 -0000 Message-ID: Subject: Re: Propose we release GDB 9.1 next weekend (Feb 01-02) To: Joel Brobecker Cc: gdb-patches@sourceware.org, Pedro Alves , Iain Buclaw , Nick Alcock , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: D923E73A-44A1-11EA-A21F-8D86F504CC47-18936988!pb-smtp21.pobox.com X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00005.txt.bz2 On Sun, 26 Jan 2020 at 06:40, Joel Brobecker wrote: > > Pending comments, I will work on the GDB 9.1 release during > the weekend of Feb 01-02. > > Hi folks, Sorry to be coming to the party a little late on this - but GDB 9.1 has a serious regression related to path handling. This affects Eclipse CDT users because the default build system in CDT does not pass absolute paths to GCC when compiling. Thanks to some efforts of users who have been exposed early to this thanks to fc31 pushing pre-releases of 9.1 out we have detected it before release, but just barely :-) The Bug is https://sourceware.org/bugzilla/show_bug.cgi?id=24915 and it has been bouncing around for a while, with it seemingly fixed for a while, but it turns out that there are lots of cases that it is not fixed. The patch that causes the problem is https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a0c1ffedcf1988bc13fc5b6d57d3b74a17b60299 The summary is that GDB is often failing to insert breakpoints when the absolute path to the file is passed to GDB if it was compiled with a different path, such as a path with .. in the compilation path, or symlinks. This would require IDEs to know the compilation path of a file it has open when a breakpoint is inserted, rather than only having to know the absolute path to the file that is actually open. Setting basenames-may-differ to on is a workaround as the new code in the commit is guarded by that. However GDB is failing even when basenames don't differ. I have added two short traces in Comment 17 with all the commands (https://sourceware.org/bugzilla/show_bug.cgi?id=24915#c17), but I want to show you the part of the trace that indicates this is a bug. The breakpoint fails to insert on the first instance - but then works on the second try with the intervening break with no path. $ /scratch/gdb/build-gdb-9/gdb/gdb --quiet main Reading symbols from main... (gdb) b /scratch/gdb/test/src/main2.c:1 ## Breakpoint fails here No source file named /scratch/gdb/test/src/main2.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b main2.c:1 Breakpoint 1 at 0x609: file ../src/main2.c, line 2. (gdb) b /scratch/gdb/test/src/main2.c:1 ## same command works here Note: breakpoint 1 also set at pc 0x609. Breakpoint 2 at 0x609: file ../src/main2.c, line 2. (gdb) quit $ Sorry for bringing this up so late in the dev cycle - I thought this was fixed, but it was only fixed for a limited number of cases. Jonah