Re: MIPS_STABS_ELF is now broken

["H . J . Lu" <hjl at lucon dot org>]

On Tue, Jun 11, 2002 at 11:38:52AM -0400, Daniel Jacobowitz wrote:
> On Tue, Jun 11, 2002 at 08:31:42AM -0700, H . J . Lu wrote:
> > On Mon, Jun 10, 2002 at 11:59:06PM -0700, Eric Christopher wrote:
> > > 
> > > > 2002-06-10  H.J. Lu <hjl@gnu.org>
> > > > 
> > > > 	* config/tc-mips.c (s_mips_file): Never pass the first .file
> > > > 	directive to dwarf.
> > > > 
> > > 
> > > Daniel solved this a different way, by adjusting the file directives
> > > that come out of gcc. See the patch he posted to gcc-local and I was
> > > meaning to test a few days ago.
> > > 
> > 
> > How does it work with gcc 2.96? I don't want to modify gcc 2.96 for that.
> > The fact is before that change, everything works fine. I don't believe
> > modifying gcc is the solution. Are you going to offer the new gcc binary
> > for each different version of Linux/mips gcc? In any case, I will fix it
> > in my Linux binutils if you plan not to support the existing Linux/mips
> > gcc binary.
> 
> HJ, the debug information being emitted by GCC is obviously in error. 
> If you ignore the first .file directive, you will then not accept
> _VALID_ DWARF-2 debug information.  You can't have it both ways.  This
> is not the first time recently that an advance in GCC or binutils for
> Linux/MIPS has required a corresponding advance in the other.
> 
> Eric, if you think this sort of compatibility is important we could
> accept HJ's patch to ignore the first .file directive, and modify GCC
> to emit '.file "dummy"' or the like to make the situation clear.  I
> think this will just hurt our interactions with other assemblers,
> though.  We should probably talk about this.

On x86, gcc 3.1 emits

        .file   "f.c"
        .file 1 "f.c"
        .section        .debug_abbrev,"",@progbits
.Ldebug_abbrev0:

for dwarf. Can't mips take 2 .file directives?


H.J.