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