[fwd] Re: [LLVMdev] Hash Bang

[Chris Lattner]

On Sat, 1 Oct 2005, Misha Brukman wrote:
> Karl, I think you meant to cc the llvmdev list on this.
>
> Thank you for a more detailed explanation, it's much clearer to me now.

That does make more sense to me too.

> I agree that making the execution of .bc files more transparent would
> make it more useable as a stand-alone binary format on Unix-like systems
> and adding programmable support to changing the #! line would prevent
> much of user error involved in modifying the run line.

Sure, I can see this as useful on unix systems.

> One issue is that the limit of 256 chars for the run line might not be
> enough due to libraries.  For example, let's pretend we have a program
> foo.c which uses several libraries and we compile it as follows:
>
> % llvm-gcc foo.c -o foo
>
> This will produce the bytecode file 'foo.bc' and a shell script 'foo'
> which you can use to run the program via the JIT (lli).  The way LLI
> loads external libraries is via the -load=[full path to library] flags,
> and theoretically, there isn't a limit as to how many libraries a
> program might use, so a hard-coded limit in the run line would certainly
> be problematic.

I agree with Misha, this is an issue.

Another issue that I have is that this is a very unix-centric solution.  I 
guess that there isn't any good solution to this though.

In principle, making the bc reader read your specially annotated .bc files 
shouldn't be an issue: it currently looks for a magic number for llvm/llvc 
files, and could check for a #! line as well.  Instead of hard coding a 
fixed 256 byte offset, I don't see any reason the .bc reader couldn't skip 
ahead until it passes the first newline in the file.  After the 
newline(s), it would start checking for llvm bc form.

Does this make sense?  Given this, you could modify gccld (only) to emit 
.bc files with the #! lines (it has the path to lli to use).

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/