[llvm-bugs] [Bug 38271] New: Inline assembler might need better errors for section mismatches

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38271

            Bug ID: 38271
           Summary: Inline assembler might need better errors for section
                    mismatches
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MC
          Assignee: unassignedbugs at nondot.org
          Reporter: CFSworks at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20587
  --> https://bugs.llvm.org/attachment.cgi?id=20587&action=edit
"Compile test" file from a project, which cannot be compiled with clang -flto
or clang -ffunction-sections

I just spent way too much time digging into something that turned out to be
pretty simple:

I was compiling a small C program with inline assembly. The inline assembly
switches to the data section (with '.data'), defines some data, then switches
back (with '.text'). It was compiling fine with Clang, except when enabling
-flto. This is because the LLVMgold plugin now enables -function-sections by
default, and so the inline assembly is supposed to switch back to '.text.main'
instead of '.text', which was switching to a different section altogether, and
so the size of the 'main' function couldn't be calculated.

The above isn't LLVM's fault; nothing LLVM can really do about user mistakes
like that.

However, LLVM's error message in response to this situation was:
<unknown>:0: error: Cannot represent a difference across sections
LLVM ERROR: Size expression must be absolute.

This really did not help me understand that:
a) LLVMgold was turning on -function-sections in the code generator in secret,
which was why it only broke with LTO and not otherwise.
b) The inline assembly wasn't switching back to the correct section: .text was
the wrong thing to use.
c) The "difference" it was complaining about wasn't even the one that appeared
in the inline assembly, but rather the size computation added by LLVM itself.

For comparison, this is how GCC reacts under the same circumstances:
/tmp/cc9bEh8L.s: Assembler messages:
/tmp/cc9bEh8L.s:21: Error: CFI instruction used without previous .cfi_startproc
/tmp/cc9bEh8L.s:23: Error: .cfi_endproc without corresponding .cfi_startproc
/tmp/cc9bEh8L.s: Error: open CFI at the end of file; missing .cfi_endproc
directive
/tmp/cc9bEh8L.s: Error: .size expression for main does not evaluate to a
constant

This is a _little_ bit better, and is more likely to prompt a user to look at
the assembler output - at the very least, it points the user in the direction
of investigating the input, rather than the compiler. ;)

I felt this should be an issue, because the error messages probably are more
vague than intended, and because this bug does cause a fatal error under Clang
when using -ffunction-sections.

-- 
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/20180723/7da826e3/attachment-0001.html>