[fwd] Re: [LLVMdev] Hash Bang

[Karl Magdsick]

On 10/4/05, Chris Lattner <sabre at nondot.org> wrote:
> On Sat, 1 Oct 2005, Misha Brukman wrote:
[snip]
> > 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.

Well, it sounds like maybe I should first look into listing the
required libraries
in the bytecode, as this would also allow misc binaries to work properly, and
would make for simpler and more elegant shell scripts emitted by llvm-gcc.

Does this make sense?

> 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.

Yea, I wish knew of a more clean solution.

> 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.

IMHO, misc binaries are the most elegant solution I've seen.
I'm not aware of a way to specify misc binary magic number rules
without constant offsets, which would lead to an infinite number of
rules if there are an infinite number of legal offsets for the magic
number.  I'd rather not break the more elegant solution if at all
possible.

So, does it make sense for me to first look into getting all of the
dependencies into the bytecode file?



-Karl