On 08/27/18 00:33, Peter Zijlstra wrote:
>
> What problem are we trying to solve? _THIS_IP_ and _RET_IP_ work fine.
> We're 'good' at dealing with text addresses, we use them for call stacks
> and all sorts. Why does this need changing?
>
_RET_IP_ works fine, with the following two caveats:
1. To get a unique IP for each call site, the function call needs to be
tailcall protected (easily done by wrapping the function in an
__always_inline function with the notailcall() function I described
earlier. Alternatively, a generic macro wrapper for the same thing:
#define notailcall(x) ({ typeof(x) _x = (x); asm volatile(""); _x; })
2. To uniformly get the return IP, it needs to be defined as:
#define _RET_IP_((unsigned long) \
__builtin_extract_return_addr(__builtin_return_address(0)))
[sorry for the line wrapping]
Using the type unsigned long instead of void * seems kind of pointless
though.
_THIS_IP_, however, is completely ill-defined, other than being an
address *somewhere* in the same global function (not even necessarily
the same function if the function is static!) As my experiment show, in
many (nearly) cases gcc will hoist the address all the way to the top of
the function, at least for the current generic implementation.
For the case where _THIS_IP_ is passed to an out-of-line function in all
cases, it is extra pointless because all it does is increase the
footprint of every caller: _RET_IP_ is inherently passed to the function
anyway, and with tailcall protection it will uniquely identify a callsite.
For the case where _THIS_IP_ is used inline, I believe the version I
described will at the very least avoid hoisting around volatile accesses
like READ_ONCE(). Surrounding the marked code with asm volatile("");
[which should be turned into a macro or inline, obviously] might be
necessary for it to make any kind of inherent sense.
The proposed "location identifier" does have a serious problem: with
inline functions you might very well have a bunch of duplicates pointing
into the inline function, so a single callsite isn't identifiable.
-hpa
