Hello, I need to solicit your opinion about something. I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right now the linkers will use this environment variable if it specifies a single directory. It will look in that directory to find libraries when things like -lc or -lcrtend are specified on the command line. Right now, the only known place this is useful to set to is the CFE's install/bytecode-libs directory. However, the configure script can make that path available to us already because LLVM requires configuring with --with-llvmgccdir=... So, it is my understanding that current usage of LLVM_LIB_SEARCH_PATH is redundant with already available information from the configure script. Does anyone put anything *other* than CFE/install/bytecode-libs in their LLVM_LIB_SEARCH_PATH? Does anyone expect it to actually be a colon separated list of path names to be searched (its not interpreted that way currently)? I see two options: 1. Get rid of LLVM_LIB_SEARCH_PATH and just have the linker "know" about the bytecode-libs directory if --with-llvmgccdir was specified to configure. 2. Fully support LLVM_LIB_SEARCH_PATH as a colon separated path list to search for bytecode archives and files. In this case their would be no need to specify the bytecode-libs directory, it would be included already. Which do you like? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041212/7edc7c16/attachment.sig>
I'm very much in favor of option 1. In general, I think we should avoid the need for users to set special environment variables for running llvm tools -- it creates a non-obvious, hidden dependence that's often a pain to track down. Specifically in this case, it seems to me that the env. variable is unnecessary anyway since llvm-link already takes path choices on the command line. These could be used if a user wants to specify locations other than any default ones inferred at configuration time. Incidentally, I don't think we should assume that users configure with --with-llvmgccdir. Some users may not want to use or install llvm-gcc. On Dec 12, 2004, at 4:54 PM, Reid Spencer wrote:> Hello, > > I need to solicit your opinion about something. > > I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right > now the linkers will use this environment variable if it specifies a > single directory. It will look in that directory to find libraries when > things like -lc or -lcrtend are specified on the command line. Right > now, the only known place this is useful to set to is the CFE's > install/bytecode-libs directory. However, the configure script can make > that path available to us already because LLVM requires configuring > with > --with-llvmgccdir=... So, it is my understanding that current usage of > LLVM_LIB_SEARCH_PATH is redundant with already available information > from the configure script. > > Does anyone put anything *other* than CFE/install/bytecode-libs in > their > LLVM_LIB_SEARCH_PATH? Does anyone expect it to actually be a colon > separated list of path names to be searched (its not interpreted that > way currently)? > > I see two options: > > 1. Get rid of LLVM_LIB_SEARCH_PATH and just have the linker "know" > about the bytecode-libs directory if --with-llvmgccdir was > specified to configure. > > 2. Fully support LLVM_LIB_SEARCH_PATH as a colon separated path list > to search for bytecode archives and files. In this case their would > be no need to specify the bytecode-libs directory, it would be > included already. > > Which do you like? > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
Chris Lattner wrote:> On Sun, 12 Dec 2004, Reid Spencer wrote: > >> Hello, >> >> I need to solicit your opinion about something. >> >> I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right >> now the linkers will use this environment variable if it specifies a >> single directory. It will look in that directory to find libraries when >> things like -lc or -lcrtend are specified on the command line. Right >> now, the only known place this is useful to set to is the CFE's >> install/bytecode-libs directory. However, the configure script can make >> that path available to us already because LLVM requires configuring with >> --with-llvmgccdir=... > > > Actually, LLVM does *not* require the C frontend, but the only tools > that use the environment variable are those that are only used by the > CFE. > >> So, it is my understanding that current usage of >> LLVM_LIB_SEARCH_PATH is redundant with already available information >> from the configure script. >> >> Does anyone put anything *other* than CFE/install/bytecode-libs in their >> LLVM_LIB_SEARCH_PATH? Does anyone expect it to actually be a colon >> separated list of path names to be searched (its not interpreted that >> way currently)? >> >> I see two options: >> >> 1. Get rid of LLVM_LIB_SEARCH_PATH and just have the linker "know" >> about the bytecode-libs directory if --with-llvmgccdir was >> specified to configure. >> >> 2. Fully support LLVM_LIB_SEARCH_PATH as a colon separated path list >> to search for bytecode archives and files. In this case their would >> be no need to specify the bytecode-libs directory, it would be >> included already. > > > I definitely prefer #1. The only concern I have with it is that this > makes it impossible to move the llvmgcc install directory once it is > built (tools would not look in the correct directories). > > -Chris >This is a very big concern. Users of LLVM generally do not build llvmgcc -- are actively discouraged from building it -- and therefore would have no option as to where it must be installed on their system.
On Sun, 12 Dec 2004, Reid Spencer wrote:> Hello, > > I need to solicit your opinion about something. > > I'm toying with the idea of getting rid of LLVM_LIB_SEARCH_PATH. Right > now the linkers will use this environment variable if it specifies a > single directory. It will look in that directory to find libraries when > things like -lc or -lcrtend are specified on the command line. Right > now, the only known place this is useful to set to is the CFE's > install/bytecode-libs directory. However, the configure script can make > that path available to us already because LLVM requires configuring with > --with-llvmgccdir=...Actually, LLVM does *not* require the C frontend, but the only tools that use the environment variable are those that are only used by the CFE.> So, it is my understanding that current usage of > LLVM_LIB_SEARCH_PATH is redundant with already available information > from the configure script. > > Does anyone put anything *other* than CFE/install/bytecode-libs in their > LLVM_LIB_SEARCH_PATH? Does anyone expect it to actually be a colon > separated list of path names to be searched (its not interpreted that > way currently)? > > I see two options: > > 1. Get rid of LLVM_LIB_SEARCH_PATH and just have the linker "know" > about the bytecode-libs directory if --with-llvmgccdir was > specified to configure. > > 2. Fully support LLVM_LIB_SEARCH_PATH as a colon separated path list > to search for bytecode archives and files. In this case their would > be no need to specify the bytecode-libs directory, it would be > included already.I definitely prefer #1. The only concern I have with it is that this makes it impossible to move the llvmgcc install directory once it is built (tools would not look in the correct directories). -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Hello, I have been trying to randomize the basic blocks of a program in memory and disk , keeping the control flow intact. Is there any easy way provided in llvm to achieve that? any other suggestions? Thanks Tanu __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041214/78846369/attachment.html>
On Tue, 14 Dec 2004, Tanu Sharma wrote:> > Hello, > > I have been trying to randomize the basic blocks of a program in memory > and disk , keeping the control flow intact. > > Is there any easy way provided in llvm to achieve that?This is really trivial to do with LLVM, as the CFG is always intact and you don't have to worry about fall through edges or the like. The only thing you have to worry about is making sure that the entry block stays first in the linked list of basic blocks. To move blocks, you use standard remove/insert or splice operations on the list of basic blocks, accessible via Function::getBasicBlockList(). If you look at lib/Transforms/Scalar/BasicBlockPlacement.cpp, you'll see some code that moves blocks around. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/