From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65427 invoked by alias); 22 Apr 2019 18:22:43 -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 65419 invoked by uid 89); 22 Apr 2019 18:22:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=tip, H*F:D*ca, Thinking, H*Ad:D*ca X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 22 Apr 2019 18:22:41 +0000 Received: from [172.16.0.120] (192-222-157-41.qc.cable.ebox.net [192.222.157.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0DAD51E0A9; Mon, 22 Apr 2019 14:22:40 -0400 (EDT) Subject: Re: [PATCH] solib-svr4: Pass down svr4_info as much as possible To: Pedro Alves , gdb-patches@sourceware.org References: <20190409131410.10205-1-palves@redhat.com> <09d82f92-8f73-b2b1-827e-28cd7b7dc688@redhat.com> From: Simon Marchi Message-ID: <2280ee2d-a4b4-7583-e5c9-17e75ed0b596@simark.ca> Date: Mon, 22 Apr 2019 18:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <09d82f92-8f73-b2b1-827e-28cd7b7dc688@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-04/txt/msg00425.txt.bz2 On 2019-04-22 9:57 a.m., Pedro Alves wrote: > On 4/19/19 4:03 PM, Simon Marchi wrote: >> On 2019-04-10 10:49 p.m., Simon Marchi wrote: >>> I am not able to reproduce the problem, and the test doesn't fail here, without >>> the rest of the patch applied. I think it's because on my system gdb doesn't use >>> the probe based interface. >>> >>> Anyhow, the fix makes sense. Since the probe is deleted on objfile destruction, the >>> corresponding probe_and_action structures should too. >>> >>> Simon >> >> While reviewing this patch, I had written the patch below to experiment, and >> while it's not super important, I think it's a good cleanup. >> >> >> From aedf5f7d846672ba6edc2780853baa43f35dd3c4 Mon Sep 17 00:00:00 2001 >> From: Simon Marchi >> Date: Wed, 10 Apr 2019 22:02:33 -0400 >> Subject: [PATCH] solib-svr4: Pass down svr4_info as much as possible >> >> While reviewing >> >> https://sourceware.org/ml/gdb-patches/2019-04/msg00141.html >> >> I noticed that we relied heavily on global state through the >> get_svr4_info function, which uses current_program_space. I thought we >> could improve this (make things more explicit and easier to follow) by >> >> - Making get_svr4_info accept a program_space parameter, making it >> return the SVR4 info for that program space. >> - Passing down the svr4_info object from callers as much as possible. >> >> This means looking up the svr4_info for the appropriate program space at >> the entry points of the solib-svr4.c file and passing it down. For now, >> these entry points (most of them are "methods" of svr4_so_ops) rely on >> current_program_space, but we can later try to change the target_so_ops >> interface to pass down the program space. > > Seems fine to me. Please go ahead. Pushed, thanks. > Thinking a bit longer term we could end up passing down an inferior pointer > around in functions in this file instead. That's because we use target_gdbarch() > in these routines, which is really inferior->gdbarch. The program space can be > found at inferior->pspace. Etc. Then again, the end up going target calls in > a number of these routines, which implicitly refers to the current > inferior/thread/pspace too... Anyway, I'm happy with the patch as is, TBC. Ok, thanks for the tip. Simon