[llvm-dev] llvm.read_register for %RIP on x86_64

[Kostya Serebryany via llvm-dev]

On Thu, Jan 26, 2017 at 1:45 AM, Renato Golin <renato.golin at linaro.org>
wrote:

> 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
> intrinsic?
>
> 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:
>
> http://lists.llvm.org/pipermail/llvm-dev/2014-March/071472.html
>
> http://lists.llvm.org/pipermail/llvm-dev/2014-March/071530.html
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/fc19ab44/attachment.html>