Date: Wed, 23 Oct 1996 18:15:05 +0000 From: Bill Currie Subject: Re: V2.01 AS.EXE (2.7) puts local labels in obj. file To: "Troy D. Van Horn" Cc: eliz AT is DOT elta DOT co DOT il, trvanhor AT SNOOPY DOT UCollege DOT edu, djgpp AT delorie DOT com Message-id: <326E60A9.1A57@blackmagic.tait.co.nz> Organization: Tait Electronics NZ MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit References: <199610211755 DOT NAA09522 AT delorie DOT com> Troy D. Van Horn wrote: > > > > > If the binary doesn't have this bloat, then where's the efficiency aspect > > here? > > > > The inefficiency is in the size of library files. It's not much, and I'm not > trying to make a big deal out of this, but this is why unstripped programs and > library files are larger in V2.01 than they were in V2.0. > > > How else would you look for buggy code produced by the compiler? > > I would bet that most work with DJGPP does not involve looking for buggy code > from the compiler. > > > And how > > in the world can Gas know whether a file it gets as input is a > > hand-written assembly source or was produced by cc1/cc1plus from a C/C++ > > source? > > > > GAS doesn't need to know the source of the source file. The way it is supposed > to work, though, you could always invoke GAS with -L to force to leave the local > labels in the symbol table. Remember this only concerns local labels the > compiler produces to implement loops and jumping. Symbols from the source C > program always have an underline (_) attached so they are not affected. > > Troy... I found the problem(?). gcc is configured so that local labels are 'L...' but gas thinks they are '.L' (note the leading .). After looking through the various files, I found it easiest to reconfig gcc (I had to rebuild it anyway to handle __attribute__((section)) ). If anyone is interrested in my mod, let me know (it will also include the attribute fix). I will be sending the patches to the FSF (I hope they get accepted). Bill