One of the things that I don't understand well about LLVM is what code is in what object files or library archives. It would be very useful if there was a map of the dependencies between the files (e.g. if you link X.o you need Y.a and Z.o). Trying to figure out the link lines by trial and error is a bit frustrating. To assist myself with understanding this, I've started to write a document (ObjectFiles.html, attached) that will (eventually) explain all this. Right now its pretty much just a list of the various files produced by building LLVM and a cursory statement of what the file contains. The most significant need in the document is for a section on the dependencies between the various files. Some more "rules of thumb" about how to link against LLVM would be good too. Could someone please add this file to the LLVM docs directory so I can submit patches against it? I'll continue to work on this as my understanding improves. HOWEVER, feel free to embellish. This isn't a document I need to _write_, its a document I need to _read_! Thanks, Reid. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040227/dc3f12be/attachment.html> -------------- 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/20040227/dc3f12be/attachment.sig>
On Thu, 26 Feb 2004, Reid Spencer wrote:> One of the things that I don't understand well about LLVM is what code > is in what object files or library archives. It would be very useful if > there was a map of the dependencies between the files (e.g. if you link > X.o you need Y.a and Z.o). Trying to figure out the link lines by trial > and error is a bit frustrating.No kidding. We were just talking about how it would be nice to have some sort of automatic library dependency manager (perhaps hacked together with nm), but came to the conclusion that it would be more trouble than it's worth.> To assist myself with understanding this, I've started to write a > document (ObjectFiles.html, attached) that will (eventually) explain all > this. Right now its pretty much just a list of the various files > produced by building LLVM and a cursory statement of what the file > contains. The most significant need in the document is for a section > on the dependencies between the various files. Some more "rules of > thumb" about how to link against LLVM would be good too.Sounds good.> Could someone please add this file to the LLVM docs directory so I can > submit patches against it?Done.> I'll continue to work on this as my understanding improves. HOWEVER, > feel free to embellish. This isn't a document I need to _write_, its a > document I need to _read_!Sounds good. I'm concerned that this document might be hard to keep up-to-date, but it's clearly something that is needed. :) Thanks! -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Fri, 27 Feb 2004, Chris Lattner wrote:> > Could someone please add this file to the LLVM docs directory so I can > > submit patches against it?BTW, here's some hints for it: libtransforms.a -> contains only the level raise pass libtarget.a -> contains code generator support for describing target architectures libanalysis.a -> intraprocedural analyses libipa.a -> interprocedural analyses libinstrument.a -> instrumentation (e.g. profiling) transformations libtransformutils.a -> common code shared by various xforms libregalloc.a -> sparc register allocator sched.o -> sparc instruction scheduler select.o -> sparc instruction selector support libevar.o -> live variable analysis for the sparc selectiondag.o -> start of aggressive instruction selector for DAGs profpaths.o -> path profiling instrumentation Basically, libraries are built in two forms: .a files and .o files. .o files are built/used when client programs want to link in _everything_ in a library. .a files are used when a client program wants to use some of the stuff in a library, based on what symbols are referenced. The difference is important for things like 'opt' which wants to link in _ALL_ optimizations no matter what, and 'gccas' which only wants to link optimizations in that are referenced by the gccas tool explictly. For libraries that .a files don't make sense, we don't provide them. It's impossible to link in half an x86 backend for example. :) Overall, this looks really useful, especially when the dependency information is built. Perhaps this should eventually be integrated into the programmers manual though? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Thu, 2004-02-26 at 22:30, Chris Lattner wrote:> No kidding. We were just talking about how it would be nice to have some > sort of automatic library dependency manager (perhaps hacked together with > nm), but came to the conclusion that it would be more trouble than it's > worth.Perhaps, but its a good idea and would eliminate the need to manually update the document. I could probably hack something together with perl + nm pretty quickly. Wouldn't be fast, wouldn't be pretty but at least it would figure out the maze of dependencies. It could even output in html to be included in the document. I'll see what I can hack together. Don't hold your breath though, I'm in the middle of moving to WA state on Monday! Reid. -------------- 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/20040227/a1211b4f/attachment.sig>