[llvm-dev] llvm.read_register for %RIP on x86_64
Kostya Serebryany via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 31 12:58:23 PST 2017
On Thu, Jan 26, 2017 at 1:45 AM, Renato Golin <renato.golin at linaro.org>
> On 26 January 2017 at 00:08, Kostya Serebryany via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I want implement an instrumentation that gets the current PC.
> > On x86_64 I can do it using inline asm (something like "lea (%%rip),%0"),
> > but I wonder if there is some more LLVM-ish way to do it, e.g. an
> Hi Kostya,
> I'd also want something that GCC understands, as this code could end
> up there, too.
> The read_register intrinsic can be lowered by Clang from a number of
> different builtins, so we could easily "support" some already-existing
> GCC builtin for reading the PC, if you need to get it from C code.
> Right now, the read_register is locked at the stack pointer as a
> design decision. We do not know, nor we discussed the implications of
> that intrinsic for any other register on purpose. If you want to read
> the PC via a builtin, then we'll have to have that conversation one
> way or another.
> I strongly recommend you to use read_register, since support is
> already there (you only need to add "PC" to the list and everything
> works), and it's documented and the semantics are clear.
hmm. I am not sure I understood you. The last two paragraphs seem to
contradict each other.
So, you recommend to extend read_register to read the PC, or
"read_register is locked at the stack pointer as a design decision"?
> A way to convince people that reading the PC in certain cases is not
> just ok, but meaningful, is to create a piece of inline asm and show
> your case. It will certainly help the discussion to understand the
> constraints and limit support for the cases we know are safe.
> These are the original threads:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev