This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: IA32: printing FP register variables



> > See what 'z' looks like in the debug records.  It might be helpful to include
> > the entire assembly file since we'll also need to verify that 'z' ended up in
> > an FP reg.
> 
> I feel I'd be doing you a disservice in trying to interpret these
> since I know nothing about floating point and nothing about debugging
> records.  I'll report the results from any tests that you find useful,
> though.  I'm also not afraid to drag SCO's compiler dudes into private
> conversations for things like this but they've promised to kill me if I
> mention their names in the public lists. :-)  
> 
> I fed that snippet into the pertinent compilers that I had ready access
> to.  I've attached a tarball of the resulting .s files.  Here's the
> secret spy decoder ring.  The last one is dwarf-2 and should match
> what's shipped as the UDK and SVR5 (i.e. UnixWare 7) . The ELF ones are
> dwarf-1.
> 
>         icc -bcoff -S -g j.c ; mv j.s icc_coff.s
>         icc -belf -S -g j.c ; mv j.s icc_elf.s
>         /bin/cc -bcoff -S -g j.c ; mv j.s cc_coff.s
>         /bin/cc -belf -S -g j.c ; mv j.s cc_elf.s
>         /udk/usr/ccs/bin/cc -S -g j.c ; mv j.s svr5_elf.s
> 
> Stir in a few native GCC chains, the ancient Microsoft/XENIX tools, and
> some MIPS-cross stuff that I have laying around and you see that I live
> in an embarrassment of compiler poverty. :-)

That's a nice menagerie you've got there.

Unfortunately, these files don't contain enough information to tell
exactly how those compilers assign numbers to FP registers, or how the
debugger actually finds the value.

Could you ask your compiler/debugger guys how their compilers number
the IA32 FP registers?  If they assign a fixed register number to each
ST(i), could you ask them how the debugger finds the right ST(i) for a
given variable while the stack is being pushed and popped?  That is, a
variable which lives in ST(4) at one point will find itself in ST(6)
after two FLD instructions, and in ST(5) after an FADDP.  How would
the debugger find the variable at each point?  Or does the debugger
just lose when there are intermediate values on the FP stack?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]