[PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers.

[Marcin Kościelnicki]

On 14/03/16 18:49, Ulrich Weigand wrote:
> Marcin Kościelnicki wrote:
>> On 14/03/16 15:41, Ulrich Weigand wrote:
>>> I'm not sure I really like your approach, it seems odd to make common
>>> code jump through "unnatural" hoops just so that powerpc64 works.
>>> On the other hand, your approach certainly involves the least amount
>>> of changes to the current code base.
>>>
>> Yeah, I'm not that happy with it either... but we're going to need to
>> jump through some hoops in gdbserver anyway - eg. for gdb_collect, we
>> need the descriptor address, while for stop_tracing, we need the code
>> address.  So we will need some special handling for one of these sets of
>> symbols either way, and uglify the common code with it.
>
> That's certainly true as well.  Also, implementing the descriptor to
> code address lookup in exactly the same way as GDB does might be
> difficult for gdbserver to do, since it is currently reading the BFD,
> which gdbserver doesn't have available.
>
>>> I am somewhat confused about one thing, though.  In your other patch
>>> https://sourceware.org/ml/gdb-patches/2016-03/msg00201.html
>>> you seem to imply that qSymbol for function symbols simply does not
>>> work at all on powerpc64 at the moment.
>>
>> It works *sometimes* - I'm not sure what it depends on, as I'm not
>> familiar with BFD internals, but it seems gdb could have the necessary
>> information cached and not need to read the file during qSymbol
>> processing.  I, for one, had one hell of a debugging session, since my
>> simple test program linked against the IPA had all the IPA symbols
>> properly fetched, while the testsuite programs failed at the same.
>> Could be something like library load order...
>
> Hmm.  I just checked, and it turns out that as of Dec 2015 gdbserver
> actually no longer even uses the td_ta_set_event libthread_db
> callback at all.  Instead, it now always relies on PTRACE_EVENT_CLONE
> to detect new inferior threads.  This means that thread support
> shouldn't actually require qSymbol on a function symbol any more.
>
> In addition, it probably used to work in the past because GDB only
> uses the vFile packet when it is reading the target libraries from
> the target itself.  In past, GDB usually required copies of the
> target libraries to be present on the host system as well, and
> used them from there.  While there was support for loading target
> libraries remotely for a while, it was only made default about
> a year ago.
>
>
>> Yep, I thought about it, but there's the protocol compatibility issue...
>
> The more I think about it, the more I tend to agree that your
> proposal is actually the best solution.  I'd still like to give
> it a couple of days to give others a chance to comment as well ...
>
> Bye,
> Ulrich
>

Alright, so what should we do about this issue?