From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130222 invoked by alias); 10 Jan 2020 20:03:39 -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 130211 invoked by uid 89); 10 Jan 2020 20:03:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=finishing, Keith, HX-Languages-Length:1588, keith X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Jan 2020 20:03:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1578686615; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nNgA6UyUDpyt1MQVdX7QCNTYU2awp5XC9QwGdrd1Ahw=; b=QBpVWkh6TvGqDcVi13CkPr3FvXAth+WRLJTu80+d8f5o+xykOzRsNAMLI0Mb3ECcZYip/y DinSBIrt494d81ZmKO8eZxVaNYZ0nrwEnXSGkHyG7CVCREbyyzc0od+5ozN92YPEaEtK2F VYi0XhKHFPsk6KE2/DmbNN2au/ciryw= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-280-reEgwzo9NpOPvN2VWurQcQ-1; Fri, 10 Jan 2020 15:03:34 -0500 Received: by mail-wr1-f71.google.com with SMTP id z10so1362342wrt.21 for ; Fri, 10 Jan 2020 12:03:34 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id e12sm3497129wrn.56.2020.01.10.12.03.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2020 12:03:32 -0800 (PST) Subject: Re: [PATCH] Switch the inferior too in switch_to_program_space_and_thread (Re: [PATCH v2 08/24] Introduce switch_to_inferior_no_thread) To: Tom Tromey References: <20191017225026.30496-1-palves@redhat.com> <20191017225026.30496-9-palves@redhat.com> <489c25ee-b0ae-6a17-65cc-32c5d7c652d2@redhat.com> <9039e000-1d8c-ffcc-60bd-659b3a983a43@redhat.com> <87lfqfwfc5.fsf@tromey.com> Cc: "Aktemur, Tankut Baris" , "gdb-patches@sourceware.org" , "Paunovic, Aleksandar" From: Pedro Alves Message-ID: <67fdceab-5a70-f7c1-980d-ca2b0825fbcd@redhat.com> Date: Fri, 10 Jan 2020 20:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87lfqfwfc5.fsf@tromey.com> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00269.txt.bz2 On 1/10/20 2:34 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> The crash happens while doing a breakpoint re-set, called by > Pedro> clear_symtab_users at the tail end of (3). That is, while recreating > Pedro> breakpoints for the current program space, which is the program space > Pedro> we're tearing down. During breakpoint re-set, we try to switch to the > Pedro> new location's pspace (the current pspace set in (1), so the pspace > Pedro> we're tearing down) with switch_to_program_space_and_thread, and that > Pedro> hits the failed assertion. > > Whatever happened to fine-grained breakpoint resetting? > Among other things maybe that would help with this sort of problem. Yeah... Many years ago Keith gave it a try, and then he had to go do something else. And then few years later, I gave it another go. I got to somewhere quite close to useful, but never managed to get back to finishing it. The branch doesn't look like is on my github, I'd have to dig it out. This was pre-C++... Maybe starting to scratch is better... > > Pedro> I'm not hard set on this approach though; I can go with adding the > Pedro> symfile_add_flags parameter to program_space::free_all_objfiles if > Pedro> people prefer that. > > This approach seems fine. > Longer term I would like to get rid of clear_symtab_users. Maybe it > could be replaced with more precisely targeted observers instead. Thanks, Pedro Alves