Add builtin/intrinsic to get current instruction pointer?

[nikic]

The linux kernel has a macro like this:

#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; })

This is used to get the current instruction pointer for error reporting purposes. It is not used to perform any control flow transitions to the label.

This usage is problematic, because it violates LLVM's requirements for blockaddress usage:

This value only has defined behavior when used as an operand to the ‘indirectbr’ or for comparisons against null. Pointer equality tests between labels addresses results in undefined behavior — though, again, comparison against null is ok, and no label is equal to the null pointer. This may be passed around as an opaque pointer sized value as long as the bits are not inspected. This allows ptrtoint and arithmetic to be performed on these values so long as the original value is reconstituted before the indirectbr instruction.

Basically, LLVM only actually supports block labels when used together with computed goto. If block labels are used without computed goto, the label can be optimized away and replaced with a dummy address. We have just enough hacks to prevent this from happening in common cases, but I feel like this is architecturally not sustainable.

I am wondering if it would make sense to add something like __builtin_instruction_pointer() / @llvm.instruction.pointer() to obtain the current instruction pointer? Where "current" is necessarily a best-effort approximation.

@nathanchance @kees Would that be suitable for the kernel use case?

cc @efriedma-quic

[efriedma-quic]

We'd need to be careful to ensure this interacts appropriately with optimizations... it's not really possible to define such a function in a way that forbids CSE, but in the interest of generating useful information, we don't want to do that.

But something like that would be good, I think.

[nikic]

We'd need to be careful to ensure this interacts appropriately with optimizations... it's not really possible to define such a function in a way that forbids CSE, but in the interest of generating useful information, we don't want to do that.

What I had in mind is to make the intrinsic memory(inaccessiblemem: readwrite), which would prevent CSE and overly aggressive code motion, while still being mostly transparent otherwise.

[kees]

As far as Linux is concerned, if it's functionally equivalent, then yeah, it'd be fine to use. Most of its use is for identifying callers for various traces (allocations especially), but as long as it works and behaves under relocation, etc, I don't foresee any issues. It should be easy to do a binary diff to double-check the results too.

[pcc]

The AArch64 backend supports pc as an argument to llvm.read_register and we use that in the HWASan pass. Maybe the same can be done for other architectures.

[pinskia]

Basically, LLVM only actually supports block labels when used together with computed goto.

GCC actually only supports them when used together with computed goto's too. labels in functions without computed gotos can be moved "randomly".

[pinskia]

Now without a new builtin, you could just do:

[[gnu::noinline]]
void *get_IP(void)
{
  return __builtin_extract_return_addr (__builtin_return_address (0));
}

Yes this is an extra function call but isn't this just on the error path? This has worked since GCC 4.5/clang 9.0.

[pinskia]

The other thing is the log functions could instead just use __builtin_extract_return_addr (__builtin_return_address (0)) to get where it is called from and __builtin_return_address (1) to get where the caller is called from instead of passing directly to the log function.

Oh I also see:
include/linux/instruction_pointer.h:#define _RET_IP_ (unsigned long)__builtin_return_address(0)

That is broken for return address signing case on aarch64 (and maybe other targets).

[pinskia]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120071

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nikita Popov (nikic)

The linux kernel has a macro like this: ``` #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) ```

This is used to get the current instruction pointer for error reporting purposes. It is not used to perform any control flow transitions to the label.

This usage is problematic, because it violates LLVM's requirements for blockaddress usage:

> This value only has defined behavior when used as an operand to the ‘indirectbr’ or for comparisons against null. Pointer equality tests between labels addresses results in undefined behavior — though, again, comparison against null is ok, and no label is equal to the null pointer. This may be passed around as an opaque pointer sized value as long as the bits are not inspected. This allows ptrtoint and arithmetic to be performed on these values so long as the original value is reconstituted before the indirectbr instruction.

Basically, LLVM only actually supports block labels when used together with computed goto. If block labels are used without computed goto, the label can be optimized away and replaced with a dummy address. We have just enough hacks to prevent this from happening in common cases, but I feel like this is architecturally not sustainable.

I am wondering if it would make sense to add something like __builtin_instruction_pointer() / @<!-- -->llvm.instruction.pointer() to obtain the current instruction pointer? Where "current" is necessarily a best-effort approximation.

@nathanchance @kees Would that be suitable for the kernel use case?

cc @efriedma-quic