Hello LLVM list, I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time. Here's the build process currently: 1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully. 2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link. 3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link. 4. Opt is invoked on it for LTO. 5. LLC converts the code to Assembly source. 6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in. 7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason. As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :-) Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target? Links: http://sourceforge.net/projects/llvmpeg/ is the project page for LLVM-PEG. (Code is in SVN repository. Click develop tab to access the SVN browser.) http://sourceforge.net/projects/llvmlibc/ is the project page for LLVM-LibC wrapper. (Code is in SVN repository.) Thanks for your time, --Sam Crow
On May 2, 2010, at 10:45 AM, Samuel Crow wrote:> Hello LLVM list, > > I'm working on a wrapper for LibC and I think it would work a whole lot better for what I'm trying to do if I wasn't forced to use a specific endianness. I'm trying to make it work in such a way that the compiler can generate code for a generic LLVM target such that the bitcodes won't need to have the alignment information or endianness until the final link stage at install time. > > Here's the build process currently: > > 1. The parser is built using LLVM-PEG parser generator which doesn't specify a target. It exports bitcode successfully. > > 2. The linker library used by the parser code and the main code completes the compiler bitcode thus creating a nearly complete compiler using LLVM-Link. > > 3. At install time system specific LibC wrapper written in C and compiled with Clang is linked to the incoming bitcode file with LLVM-Link. > > 4. Opt is invoked on it for LTO. > > 5. LLC converts the code to Assembly source. > > 6. The source is now assembled and linked to the real LibC calls contained in the LibC wrapper and the GLibC++ calls to satisfy the linker library are also linked in.What is GLibC++?> > 7. Execution reveals a core-dump due to a file handle being converted to a NULL for some reason.Have you looked at the resulting IR? If it's just libc wrappers and hello world, it ought to be fairly easy to visually inspect.> > As for step 7, I'd prefer that execution would reveal a "hello world" output to indicate that our code was working. :-) > > Since the LibC wrapper is such simple code I doubt that it's truly to blame so I'm left at a loss to explain it except that the endianness and aligment characteristics of the linker library written using LLVM-C++ are embedded in the bitcode files too soon to allow generic linking. The goal is to produce an endian-agnostic alignment-neutral bitcode in steps 1 and 2. How far away is this in the LLVM side and what can be done to help with a generic target?A fair amount of work was done to support "target-independent" IR in LLVM 2.7. If you omit TargetData, the optimizer conservatively avoids making any transformations which make memory layout assumptions. I don't know how widely used it is, but it works quite well for the things I've seen it used for. If you're just now trying hello world, it seems more likely that there's a problem in the wrappers or the main program than an optimization making memory layout assumptions. Dan
Reply inlined. ----- Original Message ----> From: Dan Gohman <gohman at apple.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Mon, May 3, 2010 3:34:55 PM > Subject: Re: [LLVMdev] Generic target? > >On May 2, 2010, at 10:45 AM, Samuel Crow wrote:> Hello LLVM > list, > > I'm working on a wrapper for LibC and I think it would > work a whole lot better for what I'm trying to do if I wasn't forced to use a > specific endianness. I'm trying to make it work in such a way that the > compiler can generate code for a generic LLVM target such that the bitcodes > won't need to have the alignment information or endianness until the final link > stage at install time. > > Here's the build process > currently: >--snip--> > 6. The source is now assembled and > linked to the real LibC calls contained in the LibC wrapper and the GLibC++ > calls to satisfy the linker library are also linked in.What is> GLibC++?Sorry, I meant LibStdC++.> > 7. Execution reveals a core-dump due to a > file handle being converted to a NULL for some reason.Have you looked at> the resulting IR? If it's just libc wrappers andhello world, it ought to be> fairly easy to visually inspect.The problem is that a pointer to a FILE structure is bitcasted to an i8 * and when it is read back it is null for some unkown reason. Then I end up with an exception that's the result of our compiled code.> > As for step 7, I'd prefer > that execution would reveal a "hello world" output to indicate that our code was > working. :-) > > Since the LibC wrapper is such simple code I > doubt that it's truly to blame so I'm left at a loss to explain it except that > the endianness and aligment characteristics of the linker library written using > LLVM-C++ are embedded in the bitcode files too soon to allow generic > linking. The goal is to produce an endian-agnostic alignment-neutral > bitcode in steps 1 and 2. How far away is this in the LLVM side and what > can be done to help with a generic target?A fair amount of work was done> to support "target-independent" IRin LLVM 2.7. If you omit TargetData, the> optimizer conservativelyavoids making any transformations which make memory> layoutassumptions. I don't know how widely used it is, but it works> quitewell for the things I've seen it used for. If you're just now> trying hello world, it seems more likely thatthere's a problem in the> wrappers or the main program than anoptimization making memory layout> assumptions.After having written the message you replied to, I figured the problem was probably with the fact that the linker library was written in C++ and compiled with LLVM-G++. Since GCC is known to make optimizations involving inlining and endianness independently of the LLVM optimizer, I think that is the culprit. Also, we were using LLVM 2.6 so we could avoid chasing our tails around with SVN head being in a semi-tested somewhat stable state only. I'll try updating the code to use 2.7 and see if that helps. Thanks for your response Dan, --Sam