On May 16, Chris Lattner wrote:> I'm concerned that this leaks the buffer created for the file, can you > verify that it doesn't?I can verify that the functionality doesn't change. If the buffer was leaked before, it'll be leaked now. However, in 'Lexer.l', you have the following code: <<EOF>> { /* Make sure to free the internal buffers for flex when we are * done reading our input! */ yy_delete_buffer(YY_CURRENT_BUFFER); return EOF; } Which should take care of it.> > I havn't tested parsing strings yet. My code is extremely simple and > > *should* work, but we know where that line of thinking leads. Should I > > submit a test case (it would have to be a C file that links in the > > parser)? > > Sure, that sounds good. I'd definitely prefer that it be tested before it > goes into CVS. Perhaps adding something to llvm/examples would be a good > way to go.I made a 'FibInC' example that uses my little c-wrapper (which in turn uses this). I can submit all of those when they are cleaned up (and linking correctly - more on that later).> One suggestion, you might change the API to be something like this: > > ParseAsmString(const char *, Module *) > > Where the function parses the string and appends it into the specified > module. This would make self-extending code simpler (no need to parse > into one module then link into the preexisting one).This seems reasonable, but what happens to the users of the module if it were to be updated - for example, if I load said module in the jit, and then add something to it. About the linking. Is it possible (within the current makefile framework) to create a shared library that (statically) contains some set of llvm libraries (including the JIT, which currenlty only works if building a tool). I wish to be able to do the following, assuming that I named that library LLVM_C gcc -lc -lLLVM_C c_file_using_llvm.c -I<stuff> -L<stuff> I *could* build everything as a shared library, and include everything on the command line that way, but that seems a bit errorprone, not to mention the fact that building everything with PIC takes ~3x longer. -- -Alex
On May 16, Chris Lattner wrote:> > This seems reasonable, but what happens to the users of the module if > > it were to be updated - for example, if I load said module in the jit, > > and then add something to it. > > This should be fine. The JIT won't touch a function until it is called.What if you read in a function with the same signature? Will it just replace it?> > About the linking. Is it possible (within the current makefile > > framework) to create a shared library that (statically) contains some > > set of llvm libraries (including the JIT, which currenlty only works > > if building a tool). > > I don't know. It seems possible: each library can be built as a .so file > individually. Each directory can also be relinked into a single .o file. > It seems logical that you could take these .o files and make a .so file :) > > > I wish to be able to do the following, assuming that I named that > > library LLVM_C > > > > gcc -lc -lLLVM_C c_file_using_llvm.c -I<stuff> -L<stuff> > > > > I *could* build everything as a shared library, and include everything > > on the command line that way, but that seems a bit errorprone, not to > > mention the fact that building everything with PIC takes ~3x longer. > > This should be possible, though our current makefile system is not going > to do this automatically right now.Can I add submit a patch to do something like this (if it doesn't disturb the makefile system that much)? Maybe if one is building a library and sets a "LINK_IN_LIBS" flag or something? I am guessing there might be other people that want something like this - ie, anybody building a shared library that they want to use in another application. -- -Alex
On Mon, 16 May 2005, Alexander Friedman wrote:> On May 16, Chris Lattner wrote: >> I'm concerned that this leaks the buffer created for the file, can you >> verify that it doesn't? > > I can verify that the functionality doesn't change. If the buffer was > leaked before, it'll be leaked now. > > However, in 'Lexer.l', you have the following code: > > > <<EOF>> { > /* Make sure to free the internal buffers for flex when we are > * done reading our input! > */ > yy_delete_buffer(YY_CURRENT_BUFFER); > return EOF; > } > > Which should take care of it.Ok, that makes sense.> I made a 'FibInC' example that uses my little c-wrapper (which in turn > uses this). I can submit all of those when they are cleaned up (and > linking correctly - more on that later).cool, ok.>> One suggestion, you might change the API to be something like this: >> >> ParseAsmString(const char *, Module *) >> >> Where the function parses the string and appends it into the specified >> module. This would make self-extending code simpler (no need to parse >> into one module then link into the preexisting one). > > This seems reasonable, but what happens to the users of the module if > it were to be updated - for example, if I load said module in the jit, > and then add something to it.This should be fine. The JIT won't touch a function until it is called.> About the linking. Is it possible (within the current makefile > framework) to create a shared library that (statically) contains some > set of llvm libraries (including the JIT, which currenlty only works > if building a tool).I don't know. It seems possible: each library can be built as a .so file individually. Each directory can also be relinked into a single .o file. It seems logical that you could take these .o files and make a .so file :)> I wish to be able to do the following, assuming that I named that > library LLVM_C > > gcc -lc -lLLVM_C c_file_using_llvm.c -I<stuff> -L<stuff> > > I *could* build everything as a shared library, and include everything > on the command line that way, but that seems a bit errorprone, not to > mention the fact that building everything with PIC takes ~3x longer.This should be possible, though our current makefile system is not going to do this automatically right now. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/