LLVM_LIB_SEARCH_PATH

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?

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.

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

Chris Lattner wrote:

That is an excellent point, one which I had not fully considered.

One way to deal with this (properly even), would be to have the 'gcc' compiler driver pass in a -L option that indicates the location of the bytecode-libs directory. It already passes in -L options for "lib/gcc/<target>/3.4-llvm/" and others, so this should be pretty easy.

-Chris

Chris Lattner wrote:

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).

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.

That is an excellent point, one which I had not fully considered.

One way to deal with this (properly even), would be to have the 'gcc' compiler driver pass in a -L option that indicates the location of the bytecode-libs directory. It already passes in -L options for "lib/gcc/<target>/3.4-llvm/" and others, so this should be pretty easy.

I agree that this is the right way to go; it's been on my mind for some time, but I've never explored the possibility.

I think LLVM_LIB_SEARCH_PATH should still exist, sort of as a parallell to LD_LIBRARY_PATH, but the compiler driver should be able to pass the -L option to gccld/llvm-ld/whatever to include the compiler runtime libraries.

Speaking of which, is there a reason not to install the libraries inside of LLVMGCCDIR/lib? That's where libstdc++ lives, and it's already in the llvm-gcc's search path?

-- John T.

That is an excellent point, I don't think there is any reason not to just install them into gcc/lib.

-Chris

My either. I've long wondered why we have the special "bytecode-libs"
directory.

Reid.

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

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