search for: subtool

...cture of the existing symbolizer makes it cumbersome to support inline frames. * The architecture of the existing symbolizer is sequential which prevents performing batched symbolication of stack frames. # Tools The proposed tools would be a sub-tools of a new llvm-xsan tool. E.g. llvm-xsan <subtool> Sub-tools will support nesting of sub-tools to allow building ergonomic tools. E.g.: llvm-xsan asan <asan subtool> * The tools would be part of compiler-rt and will optionally ship with this project. * The tools will be considered experimental while being incrementally developed on the...

...; * The architecture of the existing symbolizer is sequential which >> prevents performing batched symbolication of stack frames. >> >> # Tools >> >> The proposed tools would be a sub-tools of a new llvm-xsan tool. >> >> E.g. >> >> llvm-xsan <subtool> >> >> Sub-tools will support nesting of sub-tools to allow building >> ergonomic tools. E.g.: >> >> llvm-xsan asan <asan subtool> >> >> * The tools would be part of compiler-rt and will optionally ship with >> this project. >> * The to...

...for converting between ir formats. Extending this to object code assembly feels wrong. I think the solution to this is to move the llvm developer only tools (llc, lli, opt, as, dis, bugpoint, bcanalyzer, diff, extract, link) to the llvm tool. This would have a git like interface for accessing the subtools. The other tools remain as user tools and still support bitcode. - Michael Spencer

Tanya Lattner wrote: > You can set the program-prefix to be "llvm-". We actually recommend > this and its in the README.llvm. We do not require it though. > > -Tanya > Hello Tanya. Yes, I'm aware of this, but one of the programs that got installed for me, like i686-apple-darwin8.10.1-gcc-4.0.1, was not getting the program prefix, and was getting used by gcc.

...ch should not be added to your $PATH. Since they aren't in your path, the system GCC doesn't pick them up. To get llvm-gcc into my path, I then add symlinks from /usr/local/bin/ llvm-gcc to /usr/local/llvm-gcc/bin/llvm-gcc (likewise g++). This adds the driver to the path but not the subtools. This works like a charm for me (though it is gross and hackish). If your patch eliminates the need for this and doesn't break anything else, I'd love to see it in llvm 2.2. One of our plans for 2.1 that I hope will work out is to provide a "universal" binary for the m...

Binutils and LLVM As part of "owning our own toolchain", various people have expressed an interest and have been working on creating various tools that duplicate the functionality of tools available on other systems. As a start, I'd like to summarize the current status, and ask people for help updating the list. List taken from <http://www.gnu.org/software/binutils/>

On Sep 18, 2007, at 9:28 PM, Erick Tryzelaar wrote: > Tanya Lattner wrote: >> LLVMers, >> >> The 2.1 pre-release (version 1) is available for testing: >> http://llvm.org/prereleases/2.1/version1/ > > A couple months ago, I had a problem packaging llvm-gcc for macports > because one of the binaries from llvm-gcc was somehow getting used by > Apple's gcc

On Fri, 2005-04-22 at 11:39 -0500, Misha Brukman wrote: > On Fri, Apr 22, 2005 at 08:54:07AM -0700, Reid Spencer wrote: > > There has been some debate about the default value. I tend to agree > > with Chris on this. The default should be "all" so that everything > > gets tested by default. More sophisticated users can limit the targets > > that are built by

Not sure I follow how this would work. "llvm" is an executable, and "opt" is a symlink to "llvm"? How does llvm then detect that it needs to use the opt set of commands? That said, in principle sure you could have "llvm opt <opt-specific command syntax>" or "llvm llc <llc options>". At some point you'd probably need to extend

Hi all, please, is there some utility/command/... to list all installed kernel modules ? Peter Rosa