Re: Questions about GCC MIPS R5900's mdebug section

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

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