This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MIPS_STABS_ELF is now broken


On Tue, Jun 11, 2002 at 08:54:50AM -0700, H . J . Lu wrote:
> 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?

See the difference between those two?  The first one is '.file "foo"',
not '.file 1 "foo"'.  Unfortunately MIPS uses a '.file 1 "f.c"' for
this.  I suppose we could document and tolerate this, however it is not
enough.  GCC is still wrong.  Witness:

int func(int baz)
{
  return baz;
}

#include "small1.cc"

int func(int bar, int baq)
{
  return bar + baq;
}

#include "small2.cc"

int main()
{
  int a = 0, b = 0;
  a = func(1);
  b = func(2, 3);
}

        .file   1 "includes.cc"
        .file 1 "includes.cc"
        .file 2 "small1.cc"
        .file   2 "small1.cc"
        .file   3 "includes.cc"
        .file 3 "small2.cc"
        .file   4 "small2.cc"
        .file   5 "includes.cc"

See how much is wrong there?  GCC needs to be fixed.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]