Re: [PATCH 2/2] Fast tracepoint for powerpc64le

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

Wei-cheng Wang wrote:

[Note, see also Pedro's comments here:
https://sourceware.org/ml/gdb-patches/2015-03/msg00132.html ]

> This patch adds an IPA function, jump_pad_area_hint, for giving a hint
> where to map jump pad buffer.  addr = pagesize is too low for powerpr
> executable.

As a general comment, the relative branch range will impose user-visible
restrictions on the fast tracepoint feature here.  We need to jump from
the tracepoint location to the jump pad, and back again.  The jump *to*
the jump pad could use an absolute branch, as long as the jump pads are
allocated in low memory.  However, the jump back is a problem.  (In
Power8, we might be able to use a bctar, but we may not be able to rely
on the TAR register being available.)

With your change, we are able to branch back from a jump pad to the main
executable, as long as it is mapped at the default location, and does
not exceed 32 MB in code size.  We cannot place fast tracepoints in any
shared library, in any executable loaded at a non-default address (which
might be an issue with address-space randomization) or with executables
whose code size exceeds 32 MB (which is not that uncommon).

As a first implementation, I guess I'd be fine with those) restriction,
but we should be thinking of how we could lift (some of) them.  We might
want to, for example,
 - determine the actual mapping base of the main executable and place
   the jump pad close even if it is not at the default address
 - use multiple jump pads, one for the main exectuable and one for
   each shared library

Also, current code already supports two areas, one for the main jump
pads, and one for "trampolines" (the latter are already placed at
platform-specific addresses).  Maybe it would make sense to exploit
that mechanism: use an *absolute* branch at the tracepoint address
to jump to a jump pad in low memory, do most of the tracepoint
activity there, and then jump (via bctr/blr) to a trampoline that
restores the last few registers (CTR/LR and SP?) and then branches
back via relative branch to user code.  This might help fit more
tracepoints if we, say, only have a single page available between
shared library mappings ...

> Besides, "MAP_FIXED" flag is removed.  See MMAP(2)
>
>    If the memory region specified by addr and len  overlaps  pages
>    of any existing mapping(s), then the overlapped part of the existing
>                                                            ^^^^^^^^^^^^
>    mapping(s) will be discarded.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I agree that MAP_FIXED is dangerous.  Leaving MAP_FIXED off, however,
translates the "addr" parameter into a mere *hint*, so you might get
a mapping at *some different location* returned instead.  You should
at least check for that case ...

Bye,
Ulrich

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