Kostya Serebryany via llvm-dev
2017-Jan-26 00:08 UTC
[llvm-dev] llvm.read_register for %RIP on x86_64
Hi, 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? I can only find r208104 which introduces llvm.read_register: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20140505/215840.html The LangRef says:> Warning: So far it only works with the stack pointer on selectedarchitectures (ARM, AArch64,> PowerPC and x86_64). Significant amount of work is needed to supportother registers and even> more so, allocatable registers.Is it reasonable to extend llvm.read_register to handle the program counter register (on x86_64)? Or InlineAsm is a better way? Thanks, --kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170125/193c0cc0/attachment.html>
Reid Kleckner via llvm-dev
2017-Jan-26 00:14 UTC
[llvm-dev] llvm.read_register for %RIP on x86_64
I would do inline asm for now. If you wanted to avoid the asm, I recommend adding a new intrinsic to get the "current" PC. The intrinsic would probably have to be modeled as reading and writing memory to establish control dependence and avoid being CSE'd to the entry block. On Wed, Jan 25, 2017 at 4:08 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > 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? > > I can only find r208104 which introduces llvm.read_register: > http://lists.llvm.org/pipermail/llvm-commits/Week- > of-Mon-20140505/215840.html > > The LangRef says: > > Warning: So far it only works with the stack pointer on selected > architectures (ARM, AArch64, > > PowerPC and x86_64). Significant amount of work is needed to support > other registers and even > > more so, allocatable registers. > > Is it reasonable to extend llvm.read_register to handle the program > counter register (on x86_64)? > Or InlineAsm is a better way? > > Thanks, > > --kcc > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170125/e1c8daea/attachment.html>
Renato Golin via llvm-dev
2017-Jan-26 09:45 UTC
[llvm-dev] llvm.read_register for %RIP on x86_64
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. 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
Kostya Serebryany via llvm-dev
2017-Jan-31 20:58 UTC
[llvm-dev] 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>