[LLVMdev] Binutils and LLVM - gathering information

[Greg Fitzgerald]

> llvm-readobj outputs the same format as readelf.

For which of readelf's options?  I didn't get too far on OS X:

bin $ echo "void a(){}" | ./clang -xc -c - -o tmp.o
bin $ ./llvm-readobj tmp.o
File Format : Mach-O 64-bit x86-64
Arch        : x86_64
Address Size: 64 bits
LLVM ERROR: get_load_name() unimplemented in MachOObjectFile

-Greg


On Tue, Nov 6, 2012 at 3:18 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:

> On Tue, Nov 6, 2012 at 2:19 PM, Marshall Clow <mclow.lists at gmail.com>
> wrote:
> > 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/>
> >
> > ==============
> >
> > * ld (linker) -- lld is under active development
> >
> > * as (assembler) -- There is llvm-as, but it appears to be an assembler
> for LLVM bitcode.
> >
> > * addr2line (Converts addresses into filenames and line numbers) -- ????
> >
> > * ar (creates, modifies and extracts from archives) -- llvm-ar <
> http://llvm.org/docs/CommandGuide/llvm-ar.html> appears to do this for
> bitcode, object and archive files.
>
> This will need major changes to handle integrating ranlib.
>
> >
> > * c++filt (demangles encoded C++ symbols) -- this facility is built into
> libcxxabi, but I don't know of a tool that brings this out to the
> command-line.
> >
> > * dlltool (Creates files for building and using DLLs) -- ????
> >
> > * gprof (Displays profiling information) -- ????
> >
> > * nlmconv (Converts object code into an Netware Loadable Module) -- ????
>
> I really don't think we care about this.
>
> >
> > * nm (Lists symbols from object files) -- llvm-nm does this for bitcode,
> object and archive files.
> >
> > * objcopy (Copies and translates object files) -- ???
>
> This one is hard, as translating object files between formats doesn't
> really make sense with modern formats. I believe the main
> functionality people use is converting object files to flat binaries.
>
> >
> > * objdump (Displays information from object files) -- llvm-objdump
> appears to do this for bitcode, object and archive files.
> >
> > * ranlib (Generates an index to the contents of an archive) -- There is
> an llvm-ranlib, but the docs at  <
> http://llvm.org/docs/CommandGuide/llvm-ranlib.html> say that it only
> indexes bitcode files.
>
> Yep, needs object support.
>
> >
> > * readelf (Displays information from any ELF format object file) -- ????
>
> llvm-readobj outputs the same format as readelf.
>
> >
> > * size (Lists the section sizes of an object or archive file) --
> llvm-size does this for bitcode, object and archive files.
> >
> > * strings (Lists printable strings from files) -- I have written a
> program named llvm-strings that does this, and will be submitting it as a
> patch shortly.
> >
> > * strip (discards symbols) -- ????
> >
> > * windmc (A Windows compatible message compiler) -- ????
> >
> > * windres (A compiler for Windows resource files) -- ????
>
> These two aren't high priority, but they are needed for a lot of MFC GUI
> code.
>
> >
> > I'd appreciate if people with more knowledge than myself could chime in
> with updates to this list.
> >
> > Thanks!
> >
> > -- Marshall
>
> So far we have solved naming collisions by making the tool work with
> multiple formats, however I don't feel that is the right solution for
> llvm-as. llvm-as/llvm-dis are very simple core tools 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121107/7ac2f99c/attachment.html>