llvm dev - Jan 2017 - llvm.read_register for %RIP on x86_64

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>

On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <kcc at
google.com> wrote:

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"?


Both. :-)

There was a design decision to only support SP because we had no clear case
for anything other than the stack pointer.

If you have one for the PC, it would be a much better technical decision to
reuse the machinery that already exists, is documented and tested, than
come up with an independent implementation.

The discussion whether to support it in clang or not is orthogonal. But
once decided that we should support reading the PC, then read_register is
the obvious place.

If the clang developers refuse the idea, then inline assembly is the only
option that would work across compilers.

Makes sense?

Cheers,
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/7bfd725a/attachment.html>

On Tue, Jan 31, 2017 at 3:11 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <kcc at
google.com> wrote:
>
> 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"?
>
>
> Both. :-)
>
> There was a design decision to only support SP because we had no clear
> case for anything other than the stack pointer.
>
> If you have one for the PC, it would be a much better technical decision
> to reuse the machinery that already exists, is documented and tested, than
> come up with an independent implementation.
>
> The discussion whether to support it in clang or not is orthogonal. But
> once decided that we should support reading the PC, then read_register is
> the obvious place.
>
> If the clang developers refuse the idea, then inline assembly is the only
> option that would work across compilers.
>
> Makes sense?
>
Yep, will give it a try.

>
> Cheers,
> Renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/e5bf7a07/attachment.html>