llvm dev - Oct 2016 - LTO prevention help

I'm trying to learn about LTO. I have a static variable that I try to give
a non-compile-time-constant value to. With LTO turned off, the sprintf
happens i.e. a breakpoint set on that line does get triggered. With LTO
turned on (either Monolithic or Incremental), the code appears to be
removed/elided/deleted/forgotten/dropped/lost/ignored and the breakpoint is
never tripped.

What can I do to make my code survive through LTO? The variable makes it
through but the sprinf() line doesn't. Can I somehow tell LTO to not apply
to this function or line of code or file of code? (In reality this is
something I am trying to do via Xcode for iOS targets.)

thank you.


   1. static void __attribute__((constructor))_initv1 () {
   2.     static char default_[]   
"0000000000000000000000000000000000000000000000000000000000000000";
   3.     sprintf( default_, "%lu", (unsigned long)5 );
   4. }
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/2aad0472/attachment.html>

> On Oct 12, 2016, at 5:48 PM, Jon Slenk via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I'm trying to learn about LTO. I have a static variable that I try to
give a non-compile-time-constant value to. With LTO turned off, the sprintf
happens i.e. a breakpoint set on that line does get triggered. With LTO turned
on (either Monolithic or Incremental), the code appears to be
removed/elided/deleted/forgotten/dropped/lost/ignored and the breakpoint is
never tripped.
> 
> What can I do to make my code survive through LTO? The variable makes it
through but the sprinf() line doesn't. Can I somehow tell LTO to not apply
to this function or line of code or file of code? (In reality this is something
I am trying to do via Xcode for iOS targets.)
> 
> thank you.
> 
> static void __attribute__((constructor))_initv1 () {  
>     static char default_[] =
"0000000000000000000000000000000000000000000000000000000000000000";
>     sprintf( default_, "%lu", (unsigned long)5 );  
> }

So:

1) I don’t see what prevents us from deleting this code, even without LTO? It is
not doing anything observable.

2) I can’t reproduce: the code is not deleted by LTO on MacOS.

$ clang test.cpp   -O3  -Wl,-save-temps -g -flto
$ lldb -- a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b _initv1
Breakpoint 1: where = a.out`_initv1() + 4 at test.cpp:4, address =
0x0000000100000f64
(lldb) r
Process 15278 launched: '/private/tmp/a.out' (x86_64)
a.out was compiled with optimization - stepping may behave oddly; variables may
not be available.
Process 15278 stopped
* thread #1: tid = 0xb82628, 0x0000000100000f64 a.out`_initv1() + 4 at
test.cpp:4, queue = 'com.apple.main-thread', stop reason = breakpoint
1.1
    frame #0: 0x0000000100000f64 a.out`_initv1() + 4 at test.cpp:4 [opt]
   1   	#include <stdio.h>
   2   	static void __attribute__((constructor))_initv1 () {  
   3   	    static char default_[] =
"0000000000000000000000000000000000000000000000000000000000000000";
-> 4   	    sprintf( default_, "%lu", (unsigned long)5 );  
   5   	}
   6   	int main() {
   7   		
(lldb) 

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161012/792d39c6/attachment.html>

hi,

Thank you for your thoughtful message and for taking the time. I apologize
for not making a better example. The actual repro case I have is more
complex; I was trying to show a more succinct example but I have failed to
make it be a reproducing one. Mea culpa.

Your reply has I think led me to a small epiphany. I had though the code
was elided, but I think I now see that it is instead re-ordered.
Empirically I am seeing that the 2 breakpoints I have are happening A-B
w/out LTO but B-A with LTO.

So I am reading up on that e.g.
http://stackoverflow.com/questions/11106875/attribute-constructor-call-order-confusion

sincerely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161013/e977a40b/attachment.html>