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: i386: Are we settled?



> Jim> Are we settled on the essential contents of tm-i386.h?  
> 
> I think so.  

Great.  So, which tm-*.h file do you guys actually use?  Which regset
can we delete?  My guess would be tm-i386v.h.  A lot of other tm.h
files #include that, but all but tm-vxworks.h and tm-i386sco5.h just
override them.

> On the embedded side, we'll eventually need a mechanism to set the
> processor type instead of using the HAVE_I387_REGS, etc. macros to
> define the register set at compile time.

Right --- and this is exactly what Andrew Cagney's gdbarch is for.
One of my next ambitions is to multi-arch the i386.

> Also, an embedded target may have need to get at the control and
> debug registers (cr0, cr2, cr3, cr4, dr0-dr7) and the global, local,
> and interrupt descriptor table registers while these may not be
> available to user programs on other systems.

That's a good point.  We can allocate spaces for those registers at
the end, I think, and have them be "" for specific targets that don't
have access to them.  GDB knows not to use those.  That's the way we
handle this on the MIPS.


> Jim> Essentially, I see two outstanding questions remaining:
> Jim>
> Jim> - How should i386 targets handle the x86 FPU's 80-bit float type?
> Jim>   How can we make sure that hosts capable of handling it properly
> Jim>   don't perform lossy conversions?
> 
> I may have mentioned this before, but I believe that in the longer
> term we should move away from lossy conversions on all hosts, even
> those without 80/96 bit FP support by integrating a software FP
> engine/library (This might be useful for simulators as well, since
> we'd be able to handle exceptional conditions, rounding flags, etc.
> more precisely).  The library I'm familiar with is John Hauser's
> SoftFloat:
>     http://HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html

I think everyone's in agreement on this.  And apparently the
simulators already contain an IEEE implementation.  It's just a Simple
Matter Of Programming.

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