Message-Id: <199610211755.NAA09522@delorie.com>
From: "Troy D. Van Horn" <trvanhor AT UCollege DOT edu>
Subject: Re: V2.01 AS.EXE (2.7) puts local labels in obj. file
To: eliz AT is DOT elta DOT co DOT il
Date: Mon, 21 Oct 1996 12:55:17 CDT
Cc: trvanhor AT SNOOPY DOT UCollege DOT edu, djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.961021175938.2800E-100000@is>; from "Eli Zaretskii" at Oct 21, 96 6:02 pm

> 
> 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...