Date:	Wed, 23 Oct 1996 18:15:05 +0000
From:	Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject:	Re: V2.01 AS.EXE (2.7) puts local labels in obj. file
To:	"Troy D. Van Horn" <trvanhor AT UCollege DOT edu>
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
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

- Raw text -