Hello Óscar, The problem with that idea is that they require a pointer to a FILE structure. This file structure is included from stdio.h which has macros and conditional compilation all over the place. There are no constructors in these libraries to call and, as such, they are platform dependent. Is there any way to link in an external type definition to an opaque type? We'd need to include some equivalent of stdio.h into the bitcode. Thanks for trying, --Sam ----- Original Message ----> From: Óscar Fuentes <ofv at wanadoo.es> > To: llvmdev at cs.uiuc.edu > Sent: Fri, February 12, 2010 9:45:32 AM > Subject: Re: [LLVMdev] Portable I/O > > "Michael Ness" writes: > > > I'm attempting to use file I/O across platforms from LLVM assembly > > using the standard GNU C library: fprintf(), stdin/stdout, etc. > > Ideally I'd like to simply provide a single bitcode file that could be > > compiled on each platform, but because the internals of the I/O on > > each platform is different, this is not currently workable. > > Why not library calls? > > [snip] > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Feb 12, 2010, at 8:45 AM, Samuel Crow wrote:> Hello Óscar, > > The problem with that idea is that they require a pointer to a FILE structure. This file structure is included from stdio.h which has macros and conditional compilation all over the place. There are no constructors in these libraries to call and, as such, they are platform dependent. Is there any way to link in an external type definition to an opaque type? We'd need to include some equivalent of stdio.h into the bitcode.I think that the point is that you can define your own standard runtime interfaces: void *myopen(const char*path) { return fopen(path, ...); } That way you're not exposed to libc differences, you have a standard interface that you define. -Chris
On 02/12/2010 09:51 AM, Chris Lattner wrote:> I think that the point is that you can define your own standard runtime interfaces: > > void *myopen(const char*path) { > return fopen(path, ...); > }Maybe my experience hand-coding LLVM will actually be of some help. What I did for this case is what I think Chris is suggesting--I have a .c file with functions that return whatever FILE* I need as a void* (I think--could have been a char), and a .ll file that declares the function as returning an i8*. Perhaps there is a more sophisticated way, but that seems to work just fine. Basically anything that is not guaranteed to be a symbol the linker can see gets a wrapper function written in C. I think I also did this for some of libc's many types (ptrdiff_t and size_t, for example) that I shouldn't technically assume anything about. I didn't *need* portability, but I tried to work in that direction anyway. I have some other tricks, but they depend on the fact that I actually run LLVM code through CPP, which I assume most people have too much good taste to do. 7x57