On Jul 18, 2007, at 8:06 AM, Holger Schurig wrote:> Seems like the memory-hog status is related to debug info, e.g. to -g.Perhaps this is related to the binutils bug discussed on the list recently (in certain versions of 2.17, I believe) that causes the native linker to behave very poorly when linking with debug symbols? http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-June/009391.html -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070718/e5a78139/attachment.html>
> > Seems like the memory-hog status is related to debug info, e.g. > > to -g.> Perhaps this is related to the binutils bug discussed on the list > recently (in certain versions of 2.17, I believe) that causes the > native linker to behave very poorly when linking with debug symbols?I don't think so. The *.o files where in binary bitcode format, and AFAIK llvm-ld reads them and runs various optimization stages on this. I can hardly see how this can have anything to do with binutils. Before the main.bc file got written, I terminated the run of llvm-ld. Also, I'm not absolutely sure if it was because of "-g" or because I did not specify any "-O" while compiling the c/c++ files into bitcode.
On Wed, 2007-07-18 at 21:48 +0200, Holger Schurig wrote:> > > Seems like the memory-hog status is related to debug info, e.g. > > > to -g. > > > Perhaps this is related to the binutils bug discussed on the list > > recently (in certain versions of 2.17, I believe) that causes the > > native linker to behave very poorly when linking with debug symbols? > > I don't think so. The *.o files where in binary bitcode format, and > AFAIK llvm-ld reads them and runs various optimization stages on this. > I can hardly see how this can have anything to do with binutils. Before > the main.bc file got written, I terminated the run of llvm-ld.That's correct, llvm-ld does nothing with binutils. If its linking natively, it invokes gcc in a separate process which does use binutils, but the memory wouldn't be attributed to llvm-ld in that case.> Also, I'm not absolutely sure if it was because of "-g" or because I did > not specify any "-O" while compiling the c/c++ files into bitcode.Either way the output from llvm-gcc is much more verbose than a run without -g or with -Ox Reid.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev