[LLVMdev] stdio.h implemented as a late-binding driver

Samuel Crow samuraileumas at yahoo.com
Sun Jun 20 17:43:11 PDT 2010


Hello LLVM Devs,

I've written a wrapper for stdio.h that allows LibC functions and constants to be converted into a late-binding driver.  The purpose for this is to allow bitcode files written with this wrapper to access files portably cross-platform.  Since the driver is intended to be included with a generic program installer for each supported platform, I'm interested in knowing how well the link-time-optimization and final code generation perform when dealing with "getter functions".

Since the constants recognized by stdio.h are implemented portably only at the source level in conventional C headers I've replaced those constants with functions that return the constants.  Since these functions are external references they can be resolved at link time, I need to know that LTO converts these simple functions with an inline linkage to their return value.

If this experiment proves successful it may be possible to wrap other libraries and headers in a portable way.  If this interests anyone, please say so on the mailing list here.  I'd especially like to hear if some Linux package makers or Mac installer techs would be interested in helping me implement portable bitcode files for static-compiled virtual machine use.

I know I've posted the link here before when looking for testers but for those who may be interested either in expanding this project or constructive criticisms of the architecture I've made.  The only known bug at this point is that it contains support for deprecated functions that can be dangerous if used (tmpfile, for example).  The project page is http://sourceforge.net/projects/llvmlibc/ and the newly updated instructions are on the Wiki page at http://sourceforge.net/apps/mediawiki/llvmlibc/ .  Also, let me know if anyone would be interested in adding this to the standard Clang headers since it would allow whole-program bitcodes to potentially be made using Clang.

I'm sorry about the long post.  Please let me know what you think, good or bad.

--Sam



      



More information about the llvm-dev mailing list