This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PING] [PATCH] Rebase executable to match relocated base address
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