Hi,
I've recently ported Pure (http://purelang.bitbucket.org/) to LLVM
3.4, and I've run into a problem. I'm using LLVM on a Linux x86_64
system (Arch). In previous releases llc would automatically mangle
identifiers in LLVM assembler source code so that the result could be
assembled with the system assembler of the target platform. E.g., if I
have LLVM assembler (.ll) code like:
define void @"$(foo)"() {
ret void
}
Then the llc from LLVM 3.3 turns the identifier "$(foo)" into
$_28_foo_29_ in the assembler output code (.s), which is fine.
But in LLVM 3.4 this isn't the case any more, instead the "$(foo)"
identifier goes through unchanged. It goes without saying that the
system assembler chokes on this, so I get a bunch of error messages
when trying to assemble the resulting file.
This breaks Pure's batch compiler which assumes that llc does all the
necessary name mangling.
Was this change intentional? Is it a bug? Is there a way I can get the
name mangling back in LLVM 3.4? Any help appreciated.
Thanks,
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: aggraef at gmail.com
WWW: https://plus.google.com/+AlbertGraef
On 2 February 2014 15:21, Albert Graef <aggraef at gmail.com> wrote:> Hi, > > I've recently ported Pure (http://purelang.bitbucket.org/) to LLVM > 3.4, and I've run into a problem. I'm using LLVM on a Linux x86_64 > system (Arch). In previous releases llc would automatically mangle > identifiers in LLVM assembler source code so that the result could be > assembled with the system assembler of the target platform. E.g., if I > have LLVM assembler (.ll) code like: > > define void @"$(foo)"() { > ret void > } > > Then the llc from LLVM 3.3 turns the identifier "$(foo)" into > $_28_foo_29_ in the assembler output code (.s), which is fine.This change was intentional. The rationale being that there is nothing in the object format that prevents a symbol name of "$(foo)".> But in LLVM 3.4 this isn't the case any more, instead the "$(foo)" > identifier goes through unchanged. It goes without saying that the > system assembler chokes on this, so I get a bunch of error messages > when trying to assemble the resulting file.This is a bug. The asm printer should be adding escapes so that you would get a symbol named "$(foo)". What is the target triple?> > This breaks Pure's batch compiler which assumes that llc does all the > necessary name mangling. > > Was this change intentional? Is it a bug? Is there a way I can get the > name mangling back in LLVM 3.4? Any help appreciated. > > Thanks, > AlbertCheers, Rafael
On Mon, Feb 3, 2014 at 11:55 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> This is a bug. The asm printer should be adding escapes so that you > would get a symbol named "$(foo)". What is the target triple?x86_64-unknown-linux-gnu I've attached a simple test case: source test.ll file and the .s output files produced with llc from LLVM 3.3 and 3.4, respectively (running llc test.ll). Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: aggraef at gmail.com WWW: https://plus.google.com/+AlbertGraef -------------- next part -------------- A non-text attachment was scrubbed... Name: test.ll Type: application/octet-stream Size: 39 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140204/50c065ee/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: test-3.3.s Type: text/x-asm Size: 283 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140204/50c065ee/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: test-3.4.s Type: text/x-asm Size: 267 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140204/50c065ee/attachment-0001.bin>