Re: dwarf2read problem

[Jim Blandy <jimb@cygnus.com>]

> Any chance of getting this fixed soon?  There's a simple testcase (source
> and Linux/x86/glibc 2.1 executable) at
> 
>   http://www.cygnus.com/~jason/ref.tar.gz

Sure.  I need to finish working on the alpha Linux thread support, but
once that's done...
From shebs@cygnus.com Fri Nov 19 13:57:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: bob.zulawnik@cportcorp.com
Cc: tpeng@metrowerks.com, gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, bob.zulawnik@cportcorp.com
Subject: Re: Questions about GCC MIPS R5900's mdebug section
Date: Fri, 19 Nov 1999 13:57:00 -0000
Message-id: <199911192157.NAA18675@andros.cygnus.com>
References: <38357724.BF944599@cportcorp.com>
X-SW-Source: 1999-q4/msg00292.html
Content-length: 2099

   Date: Fri, 19 Nov 1999 11:13:25 -0500
   From: Bob Zulawnik <bob.zulawnik@cportcorp.com>

   Here is what appears to be a problem when running gdb
   on MIPS executables that use stabs for debug info (e.g.
   ECOFF/stabs or ELF/stabs), rather than 'original'
   ECOFF/mdebug format. If somebody could confirm/refute
   this, it would be very helpful indeed.

You wrote a nice description of a nasty process.  In case it's not
obvious to everybody, the reason to go to all this trouble is that the
basic MIPS calling convention doesn't include a frame pointer.  In his
very useful book See MIPS Run, Dominic Sweetman observes that
(probably referring to GDB :-) )

 "Some debuggers are quite heroic and will even interpret the first
 few instructions of a function to find out how large the stack frame
 is and to locate the stored return address." (p. 279)

       proc_desc =
	   heuristic_proc_desc (startaddr, pc, next_frame);

   which means that it starts reading function prologue
   (i.e. it reads instructions from inferior's memory) and it
   attempts to figure out information about it that way.
   While inelegant, it might work OK in native configurations
   (i.e. when gdb and inferior are running on the same host).
   However, the biggest problem will occur in remote configurations,
   where those memory reads have go through remote link. (A hack
   would make gdb read the executable file on the host side,
   rather than inferior's memory in a situation like that, just
   for speed's sake).

Beware of self-modifying and scribbled-upon code though - it would be
very confusing if the prologue analysis went perfectly, but variable
values and stepping behavior were nutso because the actual code on the
target was quite different.  Correctness is more important than speed.

   As mips-tdep.c contains MIPS target-dependent code, regardless
   of the particulars of debug info scheme in use, I would guess
   that the same problem should affect MIPS ELF/Dwarf files ? Or
   am I totally confused here ?

Yes, the issue is independent of specific debug format.

								Stan