[LLVMbugs] [Bug 263] NEW: Target Triples and Shared Libraries

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=263

           Summary: Target Triples and Shared Libraries
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


The LLVM Bytecode format, AsmParser, and Module class need to be extended to
support robust target identification and a list of needed shared libraries.

Currently we use endianness and pointer-size to auto-select a code generator to
use with a bytecode file.  This is obviously really limited (ie, we can't
distinguish between i386 and i686, or PPC and SparcV8, for example), and not
complete enough.  Instead, we should allow the front-end to encode a standard
GNU style "target-triple" in the .s file, and propagate it through to the
compilation and optimizations steps.  From this target triple, we can robustly
identify a code generator or TargetMachine to use

Even when target-triple support is added though, we should still keep the
endianness/pointer size bits around, as they are useful for extracting
information about unknown targets.  Also, if a front-end generates portable
code, it should obviously leave the target triple blank, indicating it works
with any target.

While this is being added, it would also make sense to add support for
remembering the shared libraries that a module depends on.  Currently when
'gccld' links a program, it statically links in any libraries in LLVM form, then
forgets the rest.  This requires the "user" to remember which libraries must be
used when compiling to a exe file or running with the JIT.

To fix this, a module should be able to depend on external "libraries" of code,
either in LLVM form or in native form.  This would allow us to "dynamically
link" libstdc++, for example, to C++ programs.  When the JIT start doing
off-line caching and neat stuff like that, it could just load the native code
for a library that is already compiled, instead of JIT compiling the whole
library every time an app uses it.

Though it would be nice to have this before 1.2, it looks unlikely that this
will happen.  I'm just adding this bug so it doesn't get forgotten.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.