This is the mail archive of the gdb-patches@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: [eliz@is.elta.co.il: GDB: fine print in 387 info]



> To summarize: these patches seem to convert i387-tdep.c, which until
> now was largely platform-independent and could be used by any
> x87-based target, into a Linux-specific code.  Is that really the
> intent here?  I would expect the new code to unify different platforms
> that use x87, not to segregate them.

I've fixed some of the problems you mention, but there are others I
hadn't noticed.  We certainly don't want to make i387-tdep.c
Linux-specific.  I did the changes for a Linux-specific project, but
haven't cleaned them up for general consumption yet.

My knowledge of i386/7-based systems other than Linux is limited, so I
definitely appreciate you looking this stuff over.  I'd appreciate
any help you and D.J. could provide.  I'll ask questions here.

> Assuming that the new i387_float_info is indeed meant to serve all
> x87-based targets, and the above problems will be solved to allow
> platforms other than Linux to use it, I have a few general remarks on
> the format used by i387_float_info and its subroutines:
> 
>   - I'm not sure it is a good idea to print the 8 FP data registers in
>     the top-relative order.  This produces a display where the stack
>     top seems to be always in the same place, which might confuse
>     users.  In particular, top-relative order makes the printed top
>     pointer confusing, since e.g. "top: 5" doesn't mean that st5 is
>     the top of stack.
> 
>     In contrast, all platform-specific source files in GDB 4.18 print
>     the x87 registers in their physical order, from R7 down to R0, and
>     mark the top of stack with "=>", which produces stack-like
>     behavior whereby the stack top moves down and up as operands are
>     pushed and popped.  I think this way of presenting the registers
>     is better.

Well, the current behavior is closer to the way the compiler and
assembly code see the stack: all references are relative to the
current stack pointer.

But I tend to agree with you.  I think I'd rather have registers stay
put, and keep in mind the way the assembly code will see the stack,
than have registers sliding around as values are pushed and popped.

>   - I would also suggest to separate the code segment from the opcode
>     byte in the printed representation, and maybe even print the
>     mnemonic of the opcode.
> 
>   - Perhaps the 4 condition code flags should be also printed in the
>     same style like exception flags, especially since C3 is disjoint.

Those sound like good changes.  I'll finish cleaning up the FP
changes, and I'll try to address the problems you pointed out.  Then
either you or I can make these changes.

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