[LLVMbugs] [Bug 18743] New: llvm produces an invalid Mach-O from a valid IR

[bugzilla-daemon at llvm.org]

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

            Bug ID: 18743
           Summary: llvm produces an invalid Mach-O from a valid IR
           Product: clang
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: glider at google.com, isanbard at gmail.com,
                    kledzik at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The IR

@foo = private constant i32 42

is perfectly valid according to the language reference. It works correctly when
producing ELF and COFF, but when producing MachO llc prints

    .section    __TEXT,__const
L_foo:                                  ## @foo
    .asciz    "abc"

but from the discussion on bug 17976 it is known that putting a L symbol in
__const in invalid. The issue being that the linker depends on seeing all the
symbols in order to split the section into atoms. The invisible constant would
be included in the previous symbol.

Would it OK with the linker to use another section? For example, would this be
OK?:

    .section    __TEXT,__const_no_atom
    .align    2                       ## @foo
L_foo:
    .long    42                      ## 0x2a

If not, the two remaining options I can see are:

* Make private a best effort thing and print

    .section    __TEXT,__const
    .align    2                       ## @foo
l_foo:

* Declare defeat and just reject that IR when targeting MachO, leaving the
responsibility with the FE to produce something else.

-- 
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/20140205/d0519bf1/attachment.html>