From: Simon Marchi <simark@simark.ca>
To: Hannes Domani <ssbssa@yahoo.de>,
Gdb-patches <gdb-patches@sourceware.org>
Cc: Luis Machado <luis.machado@linaro.org>
Subject: Re: [PING] [PATCH] Rebase executable to match relocated base address
Date: Wed, 12 Feb 2020 04:49:00 -0000 [thread overview]
Message-ID: <ce20b548-ee6d-3307-635e-f7e2455731fb@simark.ca> (raw)
In-Reply-To: <568325237.2257415.1581420878458@mail.yahoo.com>
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
next prev parent reply other threads:[~2020-02-12 4:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <691075103.286431.1581179823782.ref@mail.yahoo.com>
2020-02-08 16:37 ` Hannes Domani via gdb-patches
2020-02-11 0:29 ` Luis Machado
2020-02-11 11:34 ` Hannes Domani via gdb-patches
2020-02-12 4:49 ` Simon Marchi [this message]
2020-02-12 18:05 ` Hannes Domani via gdb-patches
2020-02-12 18:19 ` Christian Biesinger via gdb-patches
2020-02-12 18:38 ` Hannes Domani via gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ce20b548-ee6d-3307-635e-f7e2455731fb@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.org \
--cc=ssbssa@yahoo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox