From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102493 invoked by alias); 4 Feb 2016 11:05:19 -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 102473 invoked by uid 89); 4 Feb 2016 11:05:18 -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=Hx-languages-length:1701, H*M:1020500, UD:gdb.arch, gdb.arch X-HELO: mail-pf0-f178.google.com Received: from mail-pf0-f178.google.com (HELO mail-pf0-f178.google.com) (209.85.192.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 11:05:16 +0000 Received: by mail-pf0-f178.google.com with SMTP id n128so41532519pfn.3 for ; Thu, 04 Feb 2016 03:05:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=xR2TDR9AfadmfR/QW2yw91iottXXtaxyLs+dRICj69Q=; b=IupNcRDmdo1boDPrjvGhf8JdvemQiIhAai0aa3FsiMYzoLZ/dN9EMxRdCciryp1QIs jA8hgmALwzE/+VjMwHbXGbj2QanktT3J5qEA/6uR+NkNrP5mBypEzHT93Pxp5NdU5dcG dAGyeoFKszVrQtAgpeoJFCx6Ak87l+vp4YzyPVQaFlx9Zxq5VeZVM4oKRiKacQU1Q3uz b7f6RWAlXc0yV9vNXuwb+ZjkoH7aXm49E7nUbqfDMQr4dQQMWRTHWo0zkcQ7yQkjRiw/ QrEuiyn27OKd8KLJy2E0A1EOlhsQ3HVljOA9Jlt3TZoncn4rBnneq+fma7U+o/2lrcwU p9BQ== X-Gm-Message-State: AG10YORVnw1Sp0YW/79rJK5d68a6i8WDFsj5kFwyyQEc06iSkF1qYkGGCAuiiablps089g== X-Received: by 10.98.68.194 with SMTP id m63mr9980174pfi.153.1454583915159; Thu, 04 Feb 2016 03:05:15 -0800 (PST) Received: from [127.0.0.1] (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id q20sm16277624pfa.70.2016.02.04.03.05.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Feb 2016 03:05:14 -0800 (PST) Subject: Re: [RFC] breakpoints/19474 [was Re: RFC: branching for GDB 7.11 soon? (possibly Wed)] To: Keith Seitz , "gdb-patches@sourceware.org ml" References: <20160201030638.GG4008@adacore.com> <56AFB750.3030702@redhat.com> <56B29F17.6020603@redhat.com> From: Yao Qi Message-ID: <56B33065.1020500@gmail.com> Date: Thu, 04 Feb 2016 11:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56B29F17.6020603@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00104.txt.bz2 [I am back from vacation...] Hi Keith, Thanks for looking at this bug. On 04/02/16 00:45, Keith Seitz wrote: > It is also here where we know we are attempting to fetch a list of > symtabs for the default source file, meaning all symtabs with the "same" > file name as default symtab. > > So the simple (but apparently working?) algorithm simply compares the > default symtab's fullname vs a reconstruction of the SYMTAB_DIRNAME and > basename of the "collected" symtab. [It also considers substitute-path.] The algorithm/rationale sounds good to me. I had a similar fix in my side, but it causes regressions in the following test cases, in which DW_AT_comp_dir is empty or incorrect. gdb.arch/amd64-entry-value-param.exp gdb.cp/namelessclass.exp gdb.dwarf2/dw2-common-block.exp gdb.dwarf2/dw2-single-line-discriminators.exp but your patch looks better. > > I would consider this fairly risky for inclusion into a release without > sufficient testing in HEAD, but when it comes to releases, I tend to be > quite conservative. > Yes, I agree. The problem itself can't be fixed properly without a big structural change. We don't have to ship this patch to 7.11, IMO. It is OK for mainline, however. > I've appended the patch below. This patch causes no regressions in the > test suite, and it fixes 19474. > > > I'm sure there are corner cases and a whole bunch of other problems with > this approach, but at least it is isolated to one place (for better or > worse). > > Anyone have a better idea? I don't have any. I agree that the directory name comparison in you next mail is better. -- Yao (齐尧)