Function Inlining and Blacklist

[Christian Holler]

Hi all,


I've been recently hitting a problem again with inlining combined with
blacklisting. We got several functions in a header marked as to be
always inlined and the blacklist doesn't trigger on them (I know this
problem from ASan already). However, in a shorter example I wasn't able
to reproduce this so I wanted to ask what the state of blacklisting in
combination with inlining is. Is it supposed to work?

Best,

Chris

[Alexey Samsonov]

Hi Christian!

I've verified that blacklisting doesn't work with always_inline functions -

when the compiler inserts calls into TSan runtime, the function is already inlined,

and this data is lost.

--

Alexey Samsonov, MSK

[Dmitry Vyukov]

On Wed, Mar 6, 2013 at 12:49 PM, Alexey Samsonov <sams...@google.com> wrote:
> Hi Christian!
>
> I've verified that blacklisting doesn't work with always_inline functions -
> when the compiler inserts calls into TSan runtime, the function is already
> inlined,
> and this data is lost.

I believe the data is still somewhere there. Because it is present in
debug info.

[Alexey Samsonov]

Yep, in LLVM IR we may have a function with instructions, whose debug locations

point to another (inlined) function. We can use this, OTOH we wouldn't be able to do

anything if there is no debug info.

 

--
You received this message because you are subscribed to the Google Groups "thread-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thread-sanitiz...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Alexey Samsonov, MSK

[Christian Holler]

I think it would be very helpful to use the debug information here. Building without debug info isn't very useful anyway due to missing trace symbols.

Cheers,

Chris

[Konstantin Serebryany]

Chris,
Bad idea, imho.
The regular compiler modes produce exactly the same code w/ and w/o
-g, so asan should behave like this too.
Before we try to find a better solution, what is your exact problem?
Maybe ignoring the accesses is not the right thing to do anyway?

--kcc

[Dmitry Vyukov]

On Mon, Mar 11, 2013 at 11:44 AM, Konstantin Serebryany
<konstantin....@gmail.com> wrote:
> Chris,
> Bad idea, imho.
> The regular compiler modes produce exactly the same code w/ and w/o
> -g, so asan should behave like this too.

Are you sure debug info is already stripped at that point? There is
some chance that debug info is always present in the compiler, just
not dumped into the output file.

[Konstantin Serebryany]

On Mon, Mar 11, 2013 at 1:49 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Mon, Mar 11, 2013 at 11:44 AM, Konstantin Serebryany
> <konstantin....@gmail.com> wrote:
>> Chris,
>> Bad idea, imho.
>> The regular compiler modes produce exactly the same code w/ and w/o
>> -g, so asan should behave like this too.
>
> Are you sure debug info is already stripped at that point? There is
> some chance that debug info is always present in the compiler, just
> not dumped into the output file.

Pretty sure.

>
>
>> Before we try to find a better solution, what is your exact problem?
>> Maybe ignoring the accesses is not the right thing to do anyway?
>

[Alexey Samsonov]

On Mon, Mar 11, 2013 at 1:50 PM, Konstantin Serebryany <konstantin....@gmail.com> wrote:

On Mon, Mar 11, 2013 at 1:49 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Mon, Mar 11, 2013 at 11:44 AM, Konstantin Serebryany
> <konstantin....@gmail.com> wrote:
>> Chris,
>> Bad idea, imho.
>> The regular compiler modes produce exactly the same code w/ and w/o
>> -g, so asan should behave like this too.
>
> Are you sure debug info is already stripped at that point? There is
> some chance that debug info is always present in the compiler, just
> not dumped into the output file.

Pretty sure.

+1

 

>
>
>> Before we try to find a better solution, what is your exact problem?
>> Maybe ignoring the accesses is not the right thing to do anyway?
>
> --
> You received this message because you are subscribed to the Google Groups "thread-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to thread-sanitiz...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "thread-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thread-sanitiz...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Alexey Samsonov, MSK