[LLVMbugs] [Bug 15448] New: -fasynchronous-unwind-tables different result .c -> .so versus .c -> .s -> .so

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15448
           Summary: -fasynchronous-unwind-tables different result .c ->
                    .so versus .c -> .s -> .so
           Product: clang
           Version: 3.2
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: tijl at coosemans.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Starting with the following C code test.c:

----
int func( void ) {
  return( 0 );
}
----

Create libtest-1.so:

clang -o libtest-1.so test.c -shared -fasynchronous-unwind-tables -fPIC

Create libtest-2.so:

clang -S test.c -fasynchronous-unwind-tables -fPIC
clang -o libtest-2.so test.s -shared

These two libraries are different. Moreover libtest-2.so contains text
relocations (DF_TEXTREL).

Running the same commands with gcc 4.7 results in two identical libraries.

When comparing the object files test-1.o and test-2.o there's a difference in
the .rel.eh_frame section:
clang -o test-1.o -c test.c -fasynchronous-unwind-tables -fPIC
clang -o test-2.o -c test.s

readelf -r test-1.o

Relocation section '.rel.eh_frame' at offset 0x2e0 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000020  00000202 R_386_PC32        00000000   .text

readelf -r test-2.o

Relocation section '.rel.eh_frame' at offset 0x364 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000020  00000201 R_386_32          00000000   .text

With gcc the type of the relocation is R_386_PC32 in both cases.

OS: FreeBSD 10.0 x86

-- 
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/20130305/d56fd7d5/attachment.html>