[LLVMbugs] [Bug 21811] New: "global constructors keyed to..." function does not respect frame pointer settings

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=21811

            Bug ID: 21811
           Summary: "global constructors keyed to..." function does not
                    respect frame pointer settings
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dario.domizioli at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 13452
  --> http://llvm.org/bugs/attachment.cgi?id=13452&action=edit
Reproducible - see description for how to compile and detect the issue

I have found an instance where the global initializers function for the
compilation unit (the "global constructors keyed to..." function) does not
respect the settings for whether to eliminate the frame pointer.

For example, compile the attached code with:
    clang -S -emit-llvm -O2 -fno-frame-pointer-elim <file>

I am using the "x86_64-unknown-linux" triple, and clang r223927 (but as far as
I can tell, Clang 3.4 and 3.5 show the same behaviour).

If you look at the .ll file, you should notice that main() is marked with
attributes #0 which include settings for the frame pointer elimination; however
the global constructors function is just created with attributes #2 which do
NOT include said settings.

I think this causes the global constructors function to be compiled with
different settings than the ones provided by the user. Specifically, the frame
pointer will be eliminated. On x86_64 this is detectable from looking at the
usage of %rbp.

If a lot of constructors are inlined, the register pressure will cause the
frame pointer register to be reused as a general purpose register. It will then
be stomped and (if there are later calls to constructors with a deep call tree)
what appears to be the initial frame can potentially be a value that has
nothing to do with frames.

Strangely, if we pass both -fno-frame-pointer-elim and
-mno-omit-leaf-frame-pointer then the global construtors function does have a
frame pointer. However, that function is not a leaf because it definitely calls
__cxa_atexit() to register the array dtors, so this shouldn't make a
difference.

So there may even be two issues here...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141210/a0670908/attachment.html>