RE: MIPS stack tracing

[Don Bowman <don@sandvine.com>]

> > 
> > Upon examination of gas, the .pdr section is only emitted if
> > MIPS_STABS_ELF is defined.  Am I to assume that if I'm using
> > DWARF2 this won't occur? The code which actually emits it
> > seems to be in ecoff.c.
> 
> No.  It should be emitted unless we are emitting .mdebug, which we
> don't do any more for mips-*-linux.

The code in gas is wrapped in #ifdef MIPS_STABS_ELF.

There's also some curious jiggery-pokery with strcmp(target, "elf")
for not emitting the .reginfo... I'm thinking maybe I can make that
a runtime option since I really hate that reginfo section with
an absolute passion. It has on and off broken all of the mips
targets I've worked on for the past 10 years :)

> 
> > This doesn't seem right to me, if I dump my .pdr section I get:
> > Contents of section .pdr:
> >  0000 00400080 00000000 00000000 00000000  .@..............
> >  0010 00000000 00000000 00000000 00000000  ................
> >  0020 74430080 00000000 00000000 00000000  tC..............
> >  0030 00000000 00000000 00000000 00000000  ................
> >  0040 b8430080 00000000 00000000 00000000  .C..............
> >  ...
> > 
> > But all of my addresses start @ 0x80000000.
> 
> Careful, it has relocations if you look at it in an object.  Also
> careful, you have a host-target endian mismatch.  That first word is
> 0x80000400.

If I run objdump -r, there are no relocations, my image is fully
located.

Interestingly, my host is little endian, my target is little endian.
Any guess on why those addresses whould show up as big endian?
Also, from gas, it appears a .pdr record is 7 words long, but the
.pdr shows an 8-word recurrence of the address. I assume it aligns?

So should the endianess be swapped here [ie reverse of both my host
and target]? Or do I have a bug in gas to fix first :) Is PDR a
standard of any sort, or is it just a gas invention?

--don