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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Simon Marchi wrote:

> Since we are working on fast tracepoints for ARM, I can provide an
> additional data point to the discussion.  We have a similar problem,
> that is when generating the branch to gdb_collect, we need to know
> whether gdb_collect is an ARM or Thumb symbol.  If the symbol is an
> ARM one, the branch instruction must jump to an even address
> (e.g. 0xd3c8), whereas if the symbol is Thumb, the destination address
> must have its bit 0 set (e.g. 0xd3c9).

Thanks for the additional info, that's quite interesting as well!
 
> To achieve this, we extended qSymbol to allow sending the symbol target
> flags (coming from MSYMBOL_TARGET_FLAG_{1,2}).  Those flags are target/arch
> specific.  In the case of ARM, one of them indicates that the symbol is
> a Thumb one.  This solution works well, but we also have to think about
> backwards compatibility of the protocol.  It shouldn't be too complicated
> however, since we are adding an optional field.
> 
> On the other hand, Marcin's solution would work as well for the ARM
> architecture.  The compiler would place the right value in gdb_collect_ptr,
> regardless of whether gdb_collect is an ARM (bit 0 cleared) or a Thumb
> (bit 0 set) symbol.

This is similar to the second option I suggested last year, which was
to add an extra field to qSymbol so it could return both a code address
*and* a function pointer value for function symbols.

This it seems would work for your case too, since you could determine
ARM vs. Thumb from the function pointer value.

On the other hand, I'm now wondering if it makes sense to add extra
protocol support to provide function pointer values, when we can just
as well use Marcin's trick to simply read a function pointer ...

Bye,
Ulrich

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