search for: elftoolchain

...lves, refactoring built-ins into > > a distinct library is a great place to start. > > Before anyone starts refactoring binutils - if you're really zealous > or have some strong logical reason against it - there is the BSD elf > tools project > > http://sourceforge.net/p/elftoolchain/wiki/Home/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/d63e53c9/attachment.html>

...ngled string. This provides a >> significant performance improvement and also make the demangler somewhat >> more clean. > How does it far in terms of code size? One of the big problems with the > libcxxabi demangler is its size. It's at least twice as large as the one > in elftoolchain, even ignoring some possible feature differences. Looks pretty good, I'm guessing this is because all the string operations aren't getting inlined into the parser anymore. Before this patch: __TEXT __DATA __OBJC others dec hex 247293 0 0 1248 248541 3ca...

On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at gmail.com> wrote: > Just as a point for building the builtins shouldn't we just need llvm-ar ? Thanks for pointing this out and I hope llvm-ar is up to the task. Even if targets must still port binutils, each step toward LLVM self-reliance is a step in the right direction. Without getting too far ahead of ourselves,

...tools this is a problem due to licensing. It’s also a bit of a blemish on LLVM because LLVM could be made more self sufficient if there was an llvm version of objcopy. Additionally Chromium is one of the popular benchmarks for LLVM so it would be nice if Chromium didn’t have to use binutils. Using [elftoolchain](https://sourceforge.net/p/elftoolchain/wiki/Home/) solves the licensing issue for Fuchsia but is elf specific and only solves the issue for Fuchsia. I propose implementing llvm-objcopy to be a minimum viable replacement for objcopy. I’ve gone though the sources of LLVM, Clang, Chromium, and Fuchs...

...into >> > a distinct library is a great place to start. >> >> Before anyone starts refactoring binutils - if you're really zealous >> or have some strong logical reason against it - there is the BSD elf >> tools project >> >> http://sourceforge.net/p/elftoolchain/wiki/Home/ >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/777ae780/attachment.html>

...the -s option has been specified. I'm not aware of other BSDs having this though, and supporting a collection of command options and environment settings on various platforms seems like it would be rather awkward. However, FreeBSD will likely soon migrate to strip, nm, size and such from the elftoolchain project, and those tools are natively cross-arch so strip should just work for this case.

Trying to do a "make install" on a mips box . llvm[2]: Installing Release+Asserts Archive Library /home/rkotler/caviumllvmwclang/install/lib/libLLVMLineEditor.a make[2]: Leaving directory `/home/rkotler/caviumllvmwclang/build/lib/LineEditor' make[1]: Leaving directory `/home/rkotler/caviumllvmwclang/build/lib' make[1]: Entering directory

Hello all, The itanium demangler in libcxxabi (and also, llvm/lib/Demangle) is really slow. This is largely because the textual representation of the symbol that is being demangled is held in a std::string, and manipulations done during parsing are done on that string. The demangler is always concatenating strings and inserting into the middle of strings, which is terrible. The fact that the