Alexander Potapenko via llvm-dev
2018-Mar-16 16:53 UTC
[llvm-dev] Mapping InlineAsm parameters to ConstraintInfoVector elements
Hi all, I'm trying to figure out which parameters of a given InlineAsm instruction are its inputs, and which are the outputs (rationale: make sure MSan doesn't check the output parameters of an asm() statement). As far as I understand, this information is only available through the ConstraintInfoVector for the InlineAsm. However there's no exact match between the constraints and the InlineAsm params. In addition to clobber constraints, which should be safe to ignore, there can be multiple occurrences of a single parameter having different constraints. Also, for InlineAsm instructions returning non-void values there's one additional constraint, but it's unclear whether it always goes first. My current implementation is quite ad-hoc, so I'm wondering if there's any code that already does what I'm trying to achieve. Thanks in advance, Alexander -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Evgenii Stepanov via llvm-dev
2018-Mar-16 22:42 UTC
[llvm-dev] Mapping InlineAsm parameters to ConstraintInfoVector elements
Could you provide an example where MSan checks an output parameter? On Fri, Mar 16, 2018 at 9:53 AM, Alexander Potapenko via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Hi all, > > I'm trying to figure out which parameters of a given InlineAsm instruction > are its inputs, and which are the outputs (rationale: make sure MSan > doesn't check the output parameters of an asm() statement). > > As far as I understand, this information is only available through the > ConstraintInfoVector for the InlineAsm. However there's no exact match > between the constraints and the InlineAsm params. In addition to clobber > constraints, which should be safe to ignore, there can be multiple > occurrences of a single parameter having different constraints. Also, for > InlineAsm instructions returning non-void values there's one additional > constraint, but it's unclear whether it always goes first. > > My current implementation is quite ad-hoc, so I'm wondering if there's any > code that already does what I'm trying to achieve. > > Thanks in advance, > Alexander > > -- > Alexander Potapenko > Software Engineer > > Google Germany GmbH > Erika-Mann-Straße, 33 > 80636 München > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Alexander Potapenko via llvm-dev
2018-Mar-19 14:16 UTC
[llvm-dev] Mapping InlineAsm parameters to ConstraintInfoVector elements
Sorry, I've stated the problem incorrectly. Turns out that I'm seeing false positives exactly because MSan fails to see that the inline assembly routine initializes its outputs. E.g. for functions like __test_and_set_bit() in the kernel, there's a local variable holding the return value: static __always_inline <https://elixir.bootlin.com/linux/latest/ident/__always_inline> bool __test_and_set_bit <https://elixir.bootlin.com/linux/latest/ident/__test_and_set_bit>(long nr <https://elixir.bootlin.com/linux/latest/ident/nr>, volatile <https://elixir.bootlin.com/linux/latest/ident/volatile> unsigned long *addr){ bool oldbit; asm <https://elixir.bootlin.com/linux/latest/ident/asm>("bts %2,%1" CC_SET <https://elixir.bootlin.com/linux/latest/ident/CC_SET>(c) : CC_OUT <https://elixir.bootlin.com/linux/latest/ident/CC_OUT>(c) (oldbit), ADDR <https://elixir.bootlin.com/linux/latest/ident/ADDR> : "Ir" (nr <https://elixir.bootlin.com/linux/latest/ident/nr>)); return oldbit;} , which the tool treats as uninitialized, unless we explicitly set it to false before calling asm(). On Fri, Mar 16, 2018 at 11:43 PM Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote:> Could you provide an example where MSan checks an output parameter? > > On Fri, Mar 16, 2018 at 9:53 AM, Alexander Potapenko via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > > > I'm trying to figure out which parameters of a given InlineAsm > instruction > > are its inputs, and which are the outputs (rationale: make sure MSan > > doesn't check the output parameters of an asm() statement). > > > > As far as I understand, this information is only available through the > > ConstraintInfoVector for the InlineAsm. However there's no exact match > > between the constraints and the InlineAsm params. In addition to clobber > > constraints, which should be safe to ignore, there can be multiple > > occurrences of a single parameter having different constraints. Also, > for > > InlineAsm instructions returning non-void values there's one additional > > constraint, but it's unclear whether it always goes first. > > > > My current implementation is quite ad-hoc, so I'm wondering if there's > any > > code that already does what I'm trying to achieve. > > > > Thanks in advance, > > Alexander > > > > -- > > Alexander Potapenko > > Software Engineer > > > > Google Germany GmbH > > Erika-Mann-Straße, 33 > > 80636 München > > > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180319/bd25d825/attachment.html>
Reasonably Related Threads
- Mapping InlineAsm parameters to ConstraintInfoVector elements
- Dead store elimination in the backend for -ftrivial-auto-var-init
- Dead store elimination in the backend for -ftrivial-auto-var-init
- Dead store elimination in the backend for -ftrivial-auto-var-init
- Obtaining the origin function for a local var after inlining