From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79066 invoked by alias); 12 Feb 2020 04:49:47 -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 79054 invoked by uid 89); 12 Feb 2020 04:49:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= 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; Wed, 12 Feb 2020 04:49:45 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 066581E602; Tue, 11 Feb 2020 23:49:44 -0500 (EST) Subject: Re: [PING] [PATCH] Rebase executable to match relocated base address To: Hannes Domani , Gdb-patches References: <691075103.286431.1581179823782.ref@mail.yahoo.com> <691075103.286431.1581179823782@mail.yahoo.com> <568325237.2257415.1581420878458@mail.yahoo.com> Cc: Luis Machado From: Simon Marchi Message-ID: Date: Wed, 12 Feb 2020 04:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <568325237.2257415.1581420878458@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00441.txt.bz2 On 2020-02-11 6:34 a.m., Hannes Domani via gdb-patches wrote: >> This function is needed, but the question is how it should get the base >> address from the target. >> >> The auxv trickery works, but that may have other implications. I'm not >> sure if GDB won't try to fetch more stuff given we now have an "auxv". >> And it is also a bit misleading. > > I've used this approach for a while now, and never had any problem with it. > Also, gnu-nat.c creates a fake auxv entry as well. > > >> Is there some other way one can fetch this data? Registers? Memory? > > I'm not sure how that would work. If that value was stored in some data structure in the process' memory or register, we could get it from there. But that doesn't seem to be the case, it's only given at the create process debug event. >> If not, then maybe we could create a new qxfer request to fetch this >> data for Windows, say, TARGET_OBJECT_WINDOWS_LOADBASE. It would be >> cleaner and would handle both gdbserver and gdb. >> >> In case we want to make the request more generic, maybe call it >> TARGET_OBJECT_EXEC_LOADBASE or somesuch. > > I agree that this would be the cleanest solution, but I thought touching > the gdbserver interface isn't the best idea when it can be avoided. I lean towards Luis' side, I think it's worth taking the time to do things right, since once it's published it's hard to change. auxv is not really meant to be an abstraction to be used on all platforms. So there's Luis' suggestion of a new target object. I also noticed there's a qGetTIBAddr packet that does a similar job. Should we introduce a new dedicated packet just like this one, or is that an old/obsolete way of doing things? Simon