Questions about GCC MIPS R5900's mdebug section

Questions about GCC MIPS R5900's mdebug section

[Thomas Peng]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

We are using GCC MIPS R5900 for SonyÂ’s Play Station 2 on Linux/NT. We have
ELF executables with  a .mdebug section using stabs-in-ecoff. 

1. Is there
a way to force the GCC MIPS compiler to emit the .stab and .stabstr
sections instead of the .mdebug section? Based on my knowledge, it looks
like GCC is emitting stabs and the assembler is transforming that into
.mdebug section. Shall we build GAS for MIPS with or without .mdebug stabs
conversion disabled? if possible, many thanks for your suggestions in
advance! 

2. If the GCC MIPS compiler can't generate the .stab and
.stabstr sections, is there any documentation or source file or dump tool
that descibles the .mdebug section in detail? 

Any help on this is
appreciated.

Thomas Peng
email:tpeng@metrowerks.com

Re: Questions about GCC MIPS R5900's mdebug section

[Ian Lance Taylor]

   Date: Thu, 18 Nov 1999 16:25:42 +0000
   From: Thomas Peng <tpeng@metrowerks.com>

   1. Is there
   a way to force the GCC MIPS compiler to emit the .stab and .stabstr
   sections instead of the .mdebug section? Based on my knowledge, it looks
   like GCC is emitting stabs and the assembler is transforming that into
   .mdebug section. Shall we build GAS for MIPS with or without .mdebug stabs
   conversion disabled? if possible, many thanks for your suggestions in
   advance! 

It's pretty easy to convert the assembler to .stab/.stabstr.  However,
I think that gcc by default then generates stabs entries which don't
quite work, although that might be easy to fix.  I don't remember the
details, unfortunately.

   2. If the GCC MIPS compiler can't generate the .stab and
   .stabstr sections, is there any documentation or source file or dump tool
   that descibles the .mdebug section in detail? 

I don't know of any documentation on stabs smuggled in ECOFF.

Fortunately, when using stabs debugging, you don't really have to know
the .mdebug section in detail.  For an example of reading stabs in
.mdebug, see _bfd_mips_elf_find_nearest_line in bfd/elf32-mips.c,
which calls _bfd_ecoff_locate_line and lookup_line in
bfd/ecofflink.c.  Ignore the !stabs case in lookup_line.  The stabs
entries you find, marked with ECOFF_IS_STAB, are more or less normal.

Ian

Re: Questions about GCC MIPS R5900's mdebug section

[David B Anderson]

>2. If the GCC MIPS compiler can't generate the .stab and
>.stabstr sections, is there any documentation or source file or dump tool
>that descibles the .mdebug section in detail? 

I hope there is better documentation, somewhere, but there is a
(rather old) description of mdebug  I wrote long ago on:

   http://reality.sgi.com/davea/objectinfo.html

Maybe it will help.  Maybe not.  Take a look.

   Shift click on the 'here' in 
   "one part of the old 32bit ABI for MIPS is the 
   mdebug debugging information 
   A postscript file with the only currently available
   description of this data is here (119Kbytes)."

The document says nothing about the stuff defined by SGI for
C++ (which I presume that gcc sort of follows: I did not
check).  Basically the idea there was to follow  a normal
stStruct stEnd is followed immediately
by stTag and the c++ set of things
followed by stEnd. So the C++ classes are described
twice (yuck).


Corrections/ flames to:
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.

Re: Questions about GCC MIPS R5900's mdebug section

[Bob Zulawnik]

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.

When unwinding stack (or on other occasions) find_proc_desc()
will be called with a particular PC value. It will first
attempt to do it 'in a scientific way' by calling
non_heuristic_proc_desc() (both defined in mips-tdep.c).
non_heuristic_proc_desc() will look for a block that
that particular PC values falls into (block_for_pc(pc))
and then it will attempt to find a particular symbol
for than block :

    sym = lookup_symbol (MIPS_EFI_SYMBOL_NAME, b,
                         LABEL_NAMESPACE, 0, NULL);

where MIPS_EFI_SYMBOL_NAME is defined this way in
config/mips/tm-mips.h :

    #define MIPS_EFI_SYMBOL_NAME "__GDB_EFI_INFO__"


This particular symbol ("__GDB_EFI_INFO__") will not
be found for the files with stabs debug info (ECOFF/stabs,
ELF/stabs), as it is only created when reading in
debug info from an ECOFF/mdebug executable. It is
built based upon info in PDRs (Procedure Description
Records) that live in .mdebug section. From mdebugread.c :

/* Parse a procedure descriptor record PR.  Note that the procedure
   is parsed _after_ the local symbols, now we just insert the extra
   information we need into a MIPS_EFI_SYMBOL_NAME symbol
   that has already been placed in the procedure's main block. ...
   ...
    parse_symbol (..) {
    ...
    /* Make up special symbol to contain procedure specific
       info */
     s = new_symbol (MIPS_EFI_SYMBOL_NAME);

The problem as I understand it is that these symbols
(__GDB_EFI_INFO__) are not created when reading in stabs
because stabs sections simply do not contain all that info
(gathered in one record, no less) that a PDR has (e.g. things like
frame size, register mask etc).

What happens next is that find_proc_desc() reverts to
heuristics :

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

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 ?

Regards,
Bob Zulawnik

Re: Questions about GCC MIPS R5900's mdebug section

[Stan Shebs]

   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