From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: Daniel Berlin Cc: jhaller@lucent.com, jtc@redback.com, cgf@redhat.com, gdb@sources.redhat.com, binutils@sources.redhat.com Subject: Re: stabs vs. dwarf-2 for C programs Date: Fri, 13 Apr 2001 20:22:00 -0000 Message-id: References: <5mwv8pzgvt.fsf@jtc.redback.com> <20010412221742.A22383@redhat.com> <5mg0fdzg2t.fsf@jtc.redback.com> <3AD70931.CF488A07@lucent.com> X-SW-Source: 2001-04/msg00103.html Daniel Berlin writes: > With things like dwarf2 dupe elimination implemented in compilers > using linkonce sections, and relocations on debug info in object > files, leaving the debugging info in the object files, is simply > impossible. It's a hack. Nothing more or less. Huh? Leaving the debugging information in object files is clearly not impossible. You need a minimal amount of debugging information in the executable: enough for it to determine which object file to check for information about a particular address range. That is not impossible. The debugger needs to process relocations at debug time. That is not impossible. Do you have a valid reason to reject this approach? I honestly don't know why you are so critical. This is doable, and it would help. > Why don't we try actually optimizing the reading/writing of files in > ld? > > Other linkers are tons faster on the same size executables, without > doing what he proposes. > > I suspect there is a reason for this. Yes, if that's true, I'm sure there are reasons, and as the single person most responsible for the present GNU linker code, it's quite possible that any such reasons can be traced directly to me. But I hope you don't think that nobody has ever tried to optimize the linker. In fact, I've spent months on it. At one time, around 1995 or 1996, the speed of the linker was within 50% of the speed of cat (on SunOS, for a.out). However, the addition of shared library support has definitely slowed the linker down, as in the current regime ELF relocations are processed twice--once to build the PLT and GOT, and once to actually perform the relocations. At the time I implemented it, I couldn't figure out an alternate approach. Perhaps we can do so, with much more knowledge and familiarity with the requirements. Actually, as I've said before, I think the correct approach right now is to write an ELF specific linker. The current linker is very flexible, which is good, but that flexibility slows it down for the most common uses. Ian