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
Thanks everyone, a set of wrapper routines it will be then. Dustin, are the routines you wrote open source or do you know if there is already a project that provides such a portable interface to libc for LLVM? If not, I'll write my own routines, but if there is a way to adopt a common standard or avoid reinventing the wheel I'm all for it. Mike -------------------------------------------------- From: "Dustin Laurence" <dllaurence at dslextreme.com> Sent: Friday, February 12, 2010 12:10 PM To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] Portable I/O> 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 02/12/2010 02:02 PM, Michael Ness wrote:> Dustin, are the routines you wrote open source or do you know if there > is already a project that provides such a portable interface to libc for > LLVM? If not, I'll write my own routines, but if there is a way to adopt > a common standard or avoid reinventing the wheel I'm all for it.I know of no project for this sort of thing--I just solved my own problems as I went, and only did what I needed (or what I thought I needed at the time) for my experiment. I put it under the GPL3 just so I didn't release code in the wild with ambiguous terms, so you're entitled to use it without my permission; the public GIT repo is on github: http://github.com/dllaurence/Nil and while documentation wasn't a big priority the README should at least tell you which files are what. You want to look at system_c.c for the little C wrapper functions and system.llh for the llvm declarations--keep in mind that I'm using CPP though. c_defs.c is how I import type definitions and the like--it writes an llvm header with the correct LLVM definitions for whatever the local machine uses for stuff like size_t, ptrdiff_t, and the like. If you want to know what sort of mad project it is, the developer's blog is at http://github.com/dllaurence/Nil I hope to get back to it and put in the last bits to make it Turing complete next week (basically it needs user-defined symbols and lambda expressions). Feel free to contact me about it if it isn't making sense or you want to know why I did some crazy thing. Dustin