On Apr 29, 12:30am, Jonathan Stone wrote:
> >The debugging of the core dumps did not give me any usable information
> >as to what causes the fault. gdb did not gave me any useful information
> >as to what happened, or where the code was. Maybe I could have found it
> >if I used a couple more evenings, but my time is limited. I got the
> >impression that gdb on pmax/MIPS is somewhat weak...
> 
> It's quite good for static binaries, less so for dynamically-linked
> binaries.  I think Michael Hitch has patches for that. (if memory
> serves, they put some functionality that was ifdef'ed out for ELF on
> mips, but I could easily be wrong). Maybe we could get them in the
> tree and pulled up for 1.3.2, since its a frequent complaint.
> 
> Michael? Care to comment?

  Gdb and ld don't agree on mips shared libraries (ld loads them at
0x5ffe0000, and gdb expects them at 0x00000000).  The gdb configuration
has a specific shared library support for Irix, which is what the mips
ld seems to try to be compatible with.  The mips ELF "support" in the
standard SVR4 shared library support requires a definition of DT_MIPS_RLD_MAP
which is mips-specific, but doesn't exist in link.h as gdb expects.

  I've hacked the shared library support to explicitly define the
DT_MIPS_RLD_MAP symbol and to "adjust" the shared library address relocation
to deal with the shared library being loaded at 0x5ffe0000.  I wouldn't
want to put those changes into the tree.

  I thought I had done the ld.elf_so changes to be compatible with the
existing ld.so, but gdb acted diffently between the two, and I think I
had two different sets of patches to gdb.  I haven't had a chance to look
at what the differences were yet.

Michael

-- 
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA