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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Marcin Kościelnicki wrote:

> On powerpc64, qSymbol for a function returns the function code address,
> and not the descriptor address.  Since we emit code calling gdb_collect
> and some other functions, we need the descriptor (no way to know the
> proper TOC address without it).  To get the descriptor address, make
> global function pointer variables in the IPA pointing to the relevant
> functions and read them instead of asking for them directly via qSymbol.

Huh.  This problem already came up last year with Wei-cheng's patches.
See my reply here:
https://sourceware.org/ml/gdb-patches/2015-02/msg00838.html

At the time, I suggested two possible fixes by changing how qSymbol works.
Your approach is yet another fix, however ...

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.

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.

If this is true, how does thread-db support work?  This is the one
pre-existing user of qSymbol for function symbols in gdbserver.
I had been under the assumption that this actually works now.  Is
this not in fact true?

If this is indeed just completely broken at the moment, my
preferred fix would actually be to change qSymbol to just return
the function descriptor address (i.e. work as on any other platform)
and have the function descriptor -> function code address lookup
be done on the gdbserver side when necessary for thread-db support.
(This would have been my preferred fix anyway, except for the fact
that it breaks protocol compatibility.  However, if the current
implementation simply doesn't *work*, there's no reason to worry
about compatibility.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com