[LLVMbugs] [Bug 19484] New: ARM ELF writer not marking all thumb functions correctly

[bugzilla-daemon at llvm.org]

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

            Bug ID: 19484
           Summary: ARM ELF writer not marking all thumb functions
                    correctly
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: dpeixott at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The integrated assembler is not properly marking all thumb functions. Small
test case:

$ cat A.s
        .text
        .syntax unified
        .globl  A
        .type   A,%function
        .code   16
        .thumb_func
A:
        .fnstart
        bx      lr
        .globl  B
B = A

GCC will mark both A and B as thumb functions, but llvm only marks A as a thumb
function.

$ llvm-mc A.s -triple arm-none-linux -mcpu=cortex-a9 -filetype=obj -o A.o
$ llvm-readobj -symbols A.o
  Symbol {
    Name: A (1)
    Value: 0x1
    Size: 0
    Binding: Global (0x1)
    Type: Function (0x2)
    Other: 0
    Section: .text (0x1)
  }
  Symbol {
    Name: B (8)
    Value: 0x0
    Size: 0
    Binding: Global (0x1)
    Type: Function (0x2)
    Other: 0
    Section: .text (0x1)
  }

We should mark both A and B as thumb functions by setting the least-significant
bit to 1. It is done correctly for A (Value=0x1), but not for B (Value=0x0). 

This worked previously, but was recently broken around 3/20. I suspect it might
be related to this change, but I'm not certain:

  commit 0a70f9b3b9b4a8cb92f187ea0563c1a2ac784e6e
  Author: Rafael Espindola <rafael.espindola at gmail.com>
  Date:   Thu Mar 20 02:12:01 2014 +0000

      Look through variables when computing relocations.

This is causing multiple failures in C++ programs in our test suite because it
generates incorrect code for C++ constructors. Here is a small c++ program that
exhibits the same failure.

class Foo
{
public:
    Foo();
private:
    int x;
};

Foo::Foo()
{
  x = 0;
}

-- 
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/20140419/bbb05e7f/attachment.html>