* Re: Unifying the x86 FPU register sets
[not found] ` <199910201347.JAA28369@mescaline.gnu.org>
@ 1999-10-20 10:43 ` Jim Blandy
1999-10-20 11:05 ` Jim Blandy
1 sibling, 0 replies; 2+ messages in thread
From: Jim Blandy @ 1999-10-20 10:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
> 1) Comment no.1:
>
> + #define FIRST_FPU_CTRL_REGNUM 24
> + #define FCTRL_REGNUM 24 /* FPU control word */
> + #define FPC_REGNUM 24 /* old name for FCTRL_REGNUM */
> + #define FSTAT_REGNUM 25 /* FPU status word */
> + #define FTAG_REGNUM 26 /* FPU register tag word */
> + #define FCS_REGNUM 27 /* FPU instruction's code segment selector
>
> Why does this define an old name for the FP control register, but not
> for the rest? If back-compatibility (a Good Idea, IMHO), then let's
> be consistent. tm-go32.h has these:
>
> #define FPCWD_REGNUM FPC_REGNUM
> #define FPSWD_REGNUM 25 /* 80387 status register */
> #define FPTWD_REGNUM 26 /* 80387 tag register */
> #define FPIPO_REGNUM 29 /* 80387 instruction pointer offset reg */
> #define FPIPS_REGNUM 27 /* 80387 instruction pointer selector reg */
> #define FPOOS_REGNUM 30 /* 80387 operand pointer offset reg */
> #define FPOPS_REGNUM 28 /* 80387 operand pointer selector reg */
>
> However, if DJGPP is the only platform which defines anything beyond
> FPC_REGNUM, then we may stop bothering about the rest (DJGPP itself
> doesn't use any of the rest, even though they are defined).
The patch is somewhat deceptive. I didn't _add_ FPC_REGNUM; I
_retained_ it. The old tm-i386.h #defined it too, so deleting it
would break targets for which we have no active maintainers.
Keep in mind that the goal is not to eliminate tm-go32.h and the
others; I expect each target will always need to make some tweaks to
the base definition provided by tm-i386.h.
(Does that answer the question? Not sure...)
> 2) Comment no.2:
>
> ! #define REGISTER_VIRTUAL_TYPE(N) \
> ! (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \
> ! ? lookup_pointer_type (builtin_type_void) \
> ! : IS_FP_REGNUM(N) ? builtin_type_double \
> ! : IS_SSE_REGNUM(N) ? builtin_type_v4sf \
> ! : builtin_type_int)
>
> Why are FP registers treated as type `double'? x87 uses long double,
> not double, and tm-go32.h says this:
>
> #define REGISTER_VIRTUAL_TYPE(N) \
> ((N < FP0_REGNUM) ? builtin_type_int : \
> (N < FPC_REGNUM) ? builtin_type_long_double : builtin_type_int)
>
> i386-tdep.c clearly uses 10 bytes when it initializes
> i386_register_byte[], so I gather that other x86 targets also support
> the full 80-bit width of FP registers, right? Don't we want all the
> 80 bits in "info float"?
The 80-bit floating point format goes all the way back to the
8087, I'm pretty sure. So every target with an FPU uses the 80-bit
floating-point format.
When you're cross-debugging an x86 target, the host may not have long
double, or may not use the same long double format. In this case,
GDB stores the full 80 bits in the register file (that's the "raw"
format), but converts it to a host double when it needs to produce a
`struct value' object. libiberty/floatformat.c has routines for
ripping apart floats and reassembling them, which GDB uses.
The generic `info float' implementation should do the best it can,
without requiring that host == target.
What happens at present is this:
- tm-i386.h provides everything you need to get (lossy) float
handling on any host.
- the more specific i386/tm-*.h files might use further knowledge
about the host to get better behavior, by redefining the
REGISTER_VIRTUAL_TYPE, REGISTER_CONVERTIBLE, etc. macros.
The tm-linux.h header does this now --- look for LD_I387.
Perhaps the ideal solution would be for configure to determine which
floating-point formats the host supports, and #define some symbol like
HOST_X86_EXTENDED_REAL_TYPE. Then, tm-i386.h could use that as the
virtual type for FPU registers.
But this is an issue which can be dealt with separately. For now, I
think it's fine for the more specific i386/tm-*.h files to override
REGISTER_VIRTUAL_TYPE in order to get the full precision.
> 3) Comment no.3:
>
> !
> ! #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
> ! { \
> ! double val; \
> ! i387_to_double ((FROM), (char *)&val); \
> ! store_floating ((TO), TYPE_LENGTH (TYPE), val); \
> ! }
>
> Same here: long double is not supported.
>
> Also, if REGISTER_CONVERTIBLE(REGNUM) is zero, you could simply use
> memcpy, it is faster.
>
> This also applies to REGISTER_CONVERT_TO_RAW.
If REGISTER_CONVERTIBLE(i) is zero, you should never call
REGISTER_CONVERT_TO_VIRTUAL or REGISTER_CONVERT_TO_RAW on the value of
that register. I see that go32-nat.c does this, but that's incorrect.
I'll reply to the other stuff in a separate message.
From jimb@cygnus.com Wed Oct 20 10:50:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 10:50:00 -0000
Message-id: <npr9ipj50y.fsf@zwingli.cygnus.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00071.html
Content-length: 1274
> 4) Several comments to Jim's message and the discussion that ensued:
>
> Jim> Since we're doing our own layout, we have the opportunity to set
> Jim> aside the weird packing used by the FSAVE instruction, and have the
> Jim> registers hold something more meaningful. Thus, I've split out the
> Jim> instruction segment selector and the opcode bits, previously
> Jim> different bitfields of the $fcs register, into two separate
> Jim> registers.
>
> I think we need to discuss this a bit. Please note that the FP
> registers are printed by GDB in two different ways: one is with the
> command "info float", the other with "info all-registers". I agree
> that "info float" should present the information in a manner suitable
> for debugging numerical code, i.e., the opcode should be separated
> from the instruction selector, and its missing 5 bits should be added
> to the printed value; but I think that "info all-registers" should
> print the registers *exactly* as the CPU stores them.
I'm not sure what you mean, here. Do you want "info all-registers" to
print the opcode and the FPU instruction pointer selector as a single
word? Do you want to have a single GDB register which contains both
the opcode and FPU instruction pointer selector?
Why?
From kettenis@wins.uva.nl Wed Oct 20 10:54:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@gnu.org
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 10:54:00 -0000
Message-id: <199910201754.TAA01496@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00072.html
Content-length: 761
Date: Wed, 20 Oct 1999 09:47:00 -0400
From: Eli Zaretskii <eliz@gnu.org>
Mark> What remains to be written is the function that prints the
Mark> output for the "info float" command.
Jim> I'm easy to please here, but Eli Zaretskii had opinions on how
Jim> this ought to work
I suggest to look at the thread we had discussing this back then. If
memory serves, I posted a suggestion for the format of "info float",
based on Bill Metzenthen's code originally written for i387-tdep.c.
I already did :-). I also peeked at print_387_status in go32-nat.c
(which I assume is your work) which contains some useful comments that
I'm trying to take these things into account while writing the generic
version of "info float".
Mark
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Unifying the x86 FPU register sets
[not found] ` <199910201347.JAA28369@mescaline.gnu.org>
1999-10-20 10:43 ` Unifying the x86 FPU register sets Jim Blandy
@ 1999-10-20 11:05 ` Jim Blandy
1 sibling, 0 replies; 2+ messages in thread
From: Jim Blandy @ 1999-10-20 11:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
> Jim> The instruction (code) segment and offset are $fcs and $fcoff.
> Jim> The data operand segment and offset are $fds and $fdoff.
>
> I suggest $fcseg and $fcoff, $fdseg and $fdoff, instead. People who
> work a lot with seg:off pairs will recofnise `seg', but not `s'.
I prefer those names, too. I'm waiting to see what J.T. thinks of
them.
> Jim> We could make the control registers (except $fdoff and $fcoff)
> Jim> sixteen-bit values. But that makes more work for platforms that do
> Jim> use FSAVE's 32-bit format; I assume those are the majority.
>
> AFAIK, FSAVE does use 32 bits to store the control, status and tag
> words, but the high 16 bits are undefined. Isn't it dangerous to copy
> all 32 bits to GDB's structures? The DJGPP version doesn't copy the
> high 16 bits from the buffer stored by FSAVE; if other platforms do
> that as well, we already have, in effect, 16-bit control registers.
>
> Mark> For now, GDB on the Hurd will happily display what's in the
> Mark> reserved bits that follow the control, status, and tag word
> Mark> and the operand pointer segment selector in the data structure
> Mark> used by FSAVE and FRESTOR
>
> I don't think this is right. A user should see only the bits that are
> defined by the CPU spec. For all we know, the rest might be random
> junk.
I agree. After Mark's note, I changed the comment in tm-i386.h to read:
/* All of these control registers are sixteen bits long (at most) in
the FPU, but are zero-extended to thirty-two bits in GDB's register
file. This makes it easier to compute the size of the control
register file, and somewhat easier to convert to and from the FSAVE
instruction's 32-bit format. */
#define FIRST_FPU_CTRL_REGNUM 24
#define FCTRL_REGNUM 24 /* FPU control word */
...
> Jim> [...] the new SSE FXSAVE and FXRSTOR instructions save state in
> Jim> a different format, incompatible with FSAVE and FRSTOR, so
> Jim> either the OS interfaces will be changing, or the old ones will
> Jim> be emulated by code which changes from day to day.
>
> There's another possibility: to use FXSAVE/FXRSTOR only for commands
> that handle the SSE XMMi registers, and leave the current code for the
> rest. That way, we don't need to bother about reconciling the two
> formats.
On most targets, GDB has no control over how the registers are saved.
The OS just gives you whatever it pleases. My point was that the
formats dictated to many of the targets by their kernels are likely to
be changing soon, so it's not worth much energy to tweak GDB's
register file to match any particular format exactly.
> Jim> I'm curious what Linux decides to do with the P-III support.
>
> I'm confused--why is this relevant? Are you talking about changes
> that could affect how ptrace lays out the FP registers? If not, what
> do we care about Linux support of Pentium III?
It was just a personal comment. Linux's behavior should be handled by
the Linux code, so it doesn't have any direct bearing on the present
discussion, but I'm the Linux port maintainer, so I care. At present,
Linux's ptrace doesn't give you any access to the SSE state. Since
GDB is one of ptrace's most important clients, it's plausible that I
might end up writing the kernel patch for it. I'm trying to figure
out how other Unices are dealing with this, so I can avoid introducing
needless diversity.
From jtc@redback.com Wed Oct 20 12:39:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: jimb@cygnus.com, hjl@valinux.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Wed, 20 Oct 1999 12:39:00 -0000
Message-id: <5m3dv56cuz.fsf@jtc.redbacknetworks.com>
References: <19991019182843.E7C093FC1@valinux.com> <npemerjigt.fsf@zwingli.cygnus.com> <199910192343.BAA00273@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00074.html
Content-length: 2545
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> HJ, what else will have to happen with GDB before you will
Mark> consider dropping your special Linux GDB based on 4.17? IMHO we
Mark> should make sure that the Linux community starts doing their GDB
Mark> development based on the current CVS version as soom as
Mark> possible.
I believe that H.J.'s private versions of the GNU toolchain have been
a great disservice to both the GNU/Linux and the larger GNU community.
Whatever short term advantage may be gained by having private versions
is far outweighed by the long term consequences. All the consequences
may not even be evident to the person or organization that created the
splinter branch.
* Users are not adequately informed that they are using a splinter
version, and send bug reports, requests for help, etc. to people
who are unable to help them.
* Users cannot use the most current software when it is released, but
must wait until it is incorporated into the splinter version.
* Users of the official version of the software do not benefit from
the enhancements found only in the splinter version.
* Pontential contributors cannot track the development snapshots,
because support for their (host and/or target) system requires
changes from the splinter version.
* Less time is available for improving the software because more time
is necessary for managing divergence. This is difficult enough when
all of the changes have been written by one person, or from one org-
anization, but the recordkeeping burden is even greater when changes
from many unrelated people (since copyright assignments are required
for any substantial changes).
When divergence is carefully managed, it is relatively "easy" to
isolate individual changes to submit patches.
The problem is that this feeds on itself. If there is no time to
submit changes, refining them when required, etc.; the divergence
grows and it becomes even more difficult. Eventually the threshold
grows so high that it is extremely unlikely that the differences
will ever be resolved.
I don't want to unfairly single out H.J. or his Linux toolchain
branches. I've encountered the same problem, perhaps even to a
greater degree, with a commercial vendor that distributes a modifified
version of the GNU toolchain. But I find it sadly unfortunate that an
open-source project like Linux cannot find it possible to develop
enhancements within the official versions.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Wed Oct 20 13:04:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 13:04:00 -0000
Message-id: <5mpuy94x6e.fsf@jtc.redbacknetworks.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <nppuy9j4b0.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00075.html
Content-length: 1228
>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>>
>> I suggest $fcseg and $fcoff, $fdseg and $fdoff, instead. People
>> who work a lot with seg:off pairs will recofnise `seg', but not
>> `s'.
Jim> I prefer those names, too. I'm waiting to see what J.T. thinks
Jim> of them.
If GDB can easily handle 48 bit registers, I'd prefer just having $fip
and $fop. info float and/or info all-registers could print them in
seg:offset form if desired.
But if they are to be two registers, I've no objection to using 'seg'
over 's'. I have no objection to using $fdseg and $fdoff over $foseg
and $fooff either, since Intel describes that register as FPU Operand
(Data) Pointer. I do have problems with $fcseg and $fcoff, since
there is nothing that describes the FPU Instruction Pointer as the FPU
Code Pointer.
Jim> We could make the control registers (except $fdoff and $fcoff)
Jim> sixteen-bit values. But that makes more work for platforms that
Jim> do use FSAVE's 32-bit format; I assume those are the majority.
Is there any reason that we can't have 'holes' in the byte array that
holds the register values? We could have 16 bit registers separated
by 16 bit holes.
--jtc
--
J.T. Conklin
RedBack Networks
From Peter.Schauer@regent.e-technik.tu-muenchen.de Wed Oct 20 13:23:00 1999
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: capveg@cs.umd.edu (Rob)
Cc: capveg@cs.umd.edu, gdb@sourceware.cygnus.com
Subject: Re: fix to noexec_user_stack on solaris 2.{6,7}
Date: Wed, 20 Oct 1999 13:23:00 -0000
Message-id: <199910202023.WAA19542@reisser.regent.e-technik.tu-muenchen.de>
References: <199910201715.NAA12493@xor.cs.umd.edu>
X-SW-Source: 1999-q4/msg00076.html
Content-length: 1872
No, any call from GDB to a user function returning a struct/union will
fail miserably. Try this:
struct x
{
int a[4];
};
struct x gx;
struct x
sret ()
{
return gx;
}
main ()
{
int i;
for (i = 0; i < 4; i++)
gx.a[i] = i + 1;
gx = sret ();
}
Set a breakpoint at the gx = sret () statement, run to it and issue a
`print sret()'. It will not succed with your approach, and I doubt that
continuing the program will work as well.
For details of the ABI see the Sparc Architecture Manual.
I have Version 8 (Prentice Hall ISBN 0-13-825001-4) and the calling
conventions for functions returning aggregate values are explained
in Appendix D.3.
> In message < 199910200839.KAA17702@reisser.regent.e-technik.tu-muenchen.de >, "Pe
> ter.Schauer" writes:
> >This will break calling of functions that return a structure or union.
> >
> >As per sparc calling conventions the call must looks like this:
> >
> > call fun,0
> > nop
> > unimp <size of returned struct>
> >
> >Setting CALL_DUMMY_LOCATION to AT_ENTRY_POINT doesn't handle this case.
> >
> >When I was looking at the problem a long time ago, I had no idea how to
> >solve it properly.
>
> Just so I am clear on how this breaks:
> gdb successfully makes the call and returns, but if the return type
> is a struct or union, the size is not correctly reported. With an
> incorrect size, you can look into the internals of the struct.
>
> Is that right? If so, I think I am just going to apply the patch to my
> systems, and be done with it. (Read: "users be damned" :)
>
> Does anyone have any good pointers to information on Sparc calling
> conventions?
> I have the "Sparc Assembly Reference Manual" that comes with the big solaris
> documentation set, but I find it relatively useless.
>
> Thanks for the help,
>
> - Rob
--
Peter Schauer pes@regent.e-technik.tu-muenchen.de
From kettenis@wins.uva.nl Wed Oct 20 13:32:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jtc@redback.com
Cc: jimb@cygnus.com, eliz@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 13:32:00 -0000
Message-id: <199910202032.WAA23021@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <nppuy9j4b0.fsf@zwingli.cygnus.com> <5mpuy94x6e.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00077.html
Content-length: 705
From: jtc@redback.com (J.T. Conklin)
Date: 20 Oct 1999 13:03:20 -0700
If GDB can easily handle 48 bit registers, I'd prefer just having $fip
and $fop. info float and/or info all-registers could print them in
seg:offset form if desired.
I don't think having an 48-bit $fip and $fop is a good idea. At least
in 32-bit protected mode they really are segment selector and offset
pairs. The segment selector is used to lookup the linear address of
the segment via the LDT. This is conceptually very different from the
offset. This is probably also the reason why Jim had initially chosen
$fcs and $fds for the segment selector of the instruction pointer and
operand (data) pointer.
Mark
From jtc@redback.com Wed Oct 20 13:37:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 13:37:00 -0000
Message-id: <5miu414vn5.fsf@jtc.redbacknetworks.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npso36hqr3.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00078.html
Content-length: 3115
>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
>> ! #define REGISTER_VIRTUAL_TYPE(N) \
>> ! (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \
>> ! ? lookup_pointer_type (builtin_type_void) \
>> ! : IS_FP_REGNUM(N) ? builtin_type_double \
>> ! : IS_SSE_REGNUM(N) ? builtin_type_v4sf \
>> ! : builtin_type_int)
>>
>> Why are FP registers treated as type `double'? x87 uses long double,
>> not double, and tm-go32.h says this:
>>
>> #define REGISTER_VIRTUAL_TYPE(N) \
>> ((N < FP0_REGNUM) ? builtin_type_int : \
>> (N < FPC_REGNUM) ? builtin_type_long_double : builtin_type_int)
>>
>> i386-tdep.c clearly uses 10 bytes when it initializes
>> i386_register_byte[], so I gather that other x86 targets also support
>> the full 80-bit width of FP registers, right? Don't we want all the
>> 80 bits in "info float"?
Jim> The 80-bit floating point format goes all the way back to the
Jim> 8087, I'm pretty sure. So every target with an FPU uses the
Jim> 80-bit floating-point format.
Jim> When you're cross-debugging an x86 target, the host may not have long
Jim> double, or may not use the same long double format. In this case,
Jim> GDB stores the full 80 bits in the register file (that's the "raw"
Jim> format), but converts it to a host double when it needs to produce a
Jim> `struct value' object. libiberty/floatformat.c has routines for
Jim> ripping apart floats and reassembling them, which GDB uses.
I've had fleeting thoughts about linking GDB with a software FP
library like John Houser's SoftFloat that can handle the extended
precision FP formats found on the X86 and m68k on the theory that
if you're using long double, you're doing it for a reason, and
that 80->64 bit conversion may lose the very information you need
to debug your program.
Jim> The generic `info float' implementation should do the best it can,
Jim> without requiring that host == target.
Agreed.
Jim> What happens at present is this:
Jim> - tm-i386.h provides everything you need to get (lossy) float
Jim> handling on any host.
Jim> - the more specific i386/tm-*.h files might use further knowledge
Jim> about the host to get better behavior, by redefining the
Jim> REGISTER_VIRTUAL_TYPE, REGISTER_CONVERTIBLE, etc. macros.
Jim>
Jim> The tm-linux.h header does this now --- look for LD_I387.
But the test that sets LD_I387 seems risky to me --- just because the
host is an X86 and supports the long double type does not mean long
doubles on that host are 80 bit floats.
Perhaps the best place for these (re-)definitions is in the nm-*.h
headers, since then it is known that the host == target. But that
loses for cross debugging X86 FP code from other hosts with extended
precision long doubles.
Or longer term, perhaps the tm-* files could somehow define the target
FP type(s), while the xm-* files could provide macros how to convert
FP type X to the type supported on the host. Somehow the two taken
together, plus whatever magic would make it work, would be used to
handle FP conversions. Hmmm, needs more thought...
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Wed Oct 20 15:18:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 15:18:00 -0000
Message-id: <5memep4qz4.fsf@jtc.redbacknetworks.com>
References: <199910151716.MAA03441@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00079.html
Content-length: 1382
>>>>> "Jim" == Jim Blandy <jimb@cygnus.com> writes:
Jim> I propose making the register file section of tm-i386.h, from which
Jim> everyone inherits, read as shown below. Given this, we can write an
Jim> i387-tdep.c that actually has some meat to it. Some comments:
Jim> - I have not included support for the MMX or 3DNow! registers. Since
Jim> they're superimposed on the FPU registers, it's not clear how best
Jim> to provide access to them. I want to leave that for a separate
Jim> discussion.
I wanted to discuss this, at least a little bit, before we get too far
ahead of ourselves.
At present, we have contiguous sets of registers that are supersets of
each other. What I mean by this is that the base X86 is 0 through 16;
an X86 with an FPU is 0 through 31; and an X86 with FPU with MMX and
SSE is 0 through 40. But if we're going to support MMX registers as
GDB registers, we may want them placed between the FPU registers and
the SSE registers to keep this property.
I think we want to have the MMX registers be GDB registers, because if
they are only displayed as such with an 'info mmx' some such command
there will be no way to fetch/store the value of them in scripts.
Does anyone have any experience with other X86 debuggers, emulators,
etc. that supports MMX? How do they handle the MMX registers?
--jtc
--
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Wed Oct 20 15:49:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 15:49:00 -0000
Message-id: <nphfjlir5u.fsf@zwingli.cygnus.com>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <nppuy9j4b0.fsf@zwingli.cygnus.com> <5mpuy94x6e.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00080.html
Content-length: 1189
> If GDB can easily handle 48 bit registers, I'd prefer just having $fip
> and $fop. info float and/or info all-registers could print them in
> seg:offset form if desired.
GDB can probably handle 48-bit values. Your host has to have a `long
long' type, though.
But I don't like the idea of concatenating the offset and segment.
They're two distinct components, with different interpretations. If
you were trying to concoct a concrete representation of far pointers,
then a series of six bytes would make sense, but it doesn't seem like
a very good way to think about them, or for GDB to present them.
> Jim> We could make the control registers (except $fdoff and $fcoff)
> Jim> sixteen-bit values. But that makes more work for platforms that
> Jim> do use FSAVE's 32-bit format; I assume those are the majority.
>
> Is there any reason that we can't have 'holes' in the byte array that
> holds the register values? We could have 16 bit registers separated
> by 16 bit holes.
I don't know of any code this would break (aside from the code I just
put in i386-tdep.c to compute reg offsets from sizes, no big deal),
but it feels like we're invoking the wrath of evil spirits. :(
From toddpw@windriver.com Wed Oct 20 17:16:00 1999
From: Todd Whitesel <toddpw@windriver.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 17:16:00 -0000
Message-id: <199910210016.RAA15315@alabama.wrs.com>
References: <5miu414vn5.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00081.html
Content-length: 515
> I've had fleeting thoughts about linking GDB with a software FP
> library like John Houser's SoftFloat that can handle the extended
> precision FP formats found on the X86 and m68k on the theory that
> if you're using long double, you're doing it for a reason, and
> that 80->64 bit conversion may lose the very information you need
> to debug your program.
I would be in favor of it for a completely different reason:
protection against garbage values from target programs.
--
Todd Whitesel
toddpw @ wrs.com
From kettenis@wins.uva.nl Wed Oct 20 18:10:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jtc@redback.com
Cc: jimb@cygnus.com, eliz@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Wed, 20 Oct 1999 18:10:00 -0000
Message-id: <199910210110.DAA25865@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npso36hqr3.fsf@zwingli.cygnus.com> <5miu414vn5.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00082.html
Content-length: 3351
From: jtc@redback.com (J.T. Conklin)
Date: 20 Oct 1999 13:36:30 -0700
Jim> What happens at present is this:
Jim> - tm-i386.h provides everything you need to get (lossy) float
Jim> handling on any host.
Jim> - the more specific i386/tm-*.h files might use further knowledge
Jim> about the host to get better behavior, by redefining the
Jim> REGISTER_VIRTUAL_TYPE, REGISTER_CONVERTIBLE, etc. macros.
Jim>
Jim> The tm-linux.h header does this now --- look for LD_I387.
But the test that sets LD_I387 seems risky to me --- just because the
host is an X86 and supports the long double type does not mean long
doubles on that host are 80 bit floats.
Yep it is! If you take a look at gcc you'll notice that OSF/1 on the
i386 has a 64-bit `long double'. In other words, a `long double' is
the same thing as a `double'. You'll also notice that all the other
i386 ports (including Linux) have a 96-bit `long double'. In other
words `sizeof (long double)' is 12. So there's something really fishy
about those 80-bit floats.
Perhaps the best place for these (re-)definitions is in the nm-*.h
headers, since then it is known that the host == target. But that
loses for cross debugging X86 FP code from other hosts with extended
precision long doubles.
Or longer term, perhaps the tm-* files could somehow define the target
FP type(s), while the xm-* files could provide macros how to convert
FP type X to the type supported on the host. Somehow the two taken
together, plus whatever magic would make it work, would be used to
handle FP conversions. Hmmm, needs more thought...
In principle it should be enough to add
#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
to all `tm-xxx.h' files for targets that have the 80-bit i387 `long
double' type, and add
#define HOST_LONG_DOUBLE_FORMAT &floatformat_i387_ext
to all `xm-xxx.h' files for hosts that have that same type. The i387
registers would be treated as `long doubles' ig the host has `long
double' (thus HAVE_LONG_DOUBLE is defined) and `sizeof (long double)'
matches TARGET_LONG_DOUBLE_BIT. GDB already contains enough code to
convert between the various floating point formats and the
TARGET_{EXTRACT|STORE}_FLOATING hackery in `tm-linux.h' would be
unecessary. However, this doesn't work since `sizeof (long double)'
doesn't match {HOST|TARGET}_LONG_DOUBLE_BIT.
I think this mess can be solved by viewing the i387 extended floating
point type as a 96-bit floating point type. If one looks at
`libiberty/floatformat.c', one sees that this isn't really special
since the m68881, i960, m88110 and arm extended floating point types
are also 80-bit-defined-as-96-bit formats[1].
This means that defining TARGET_LONG_DOUBLE_BIT to 96, has the
additional advantage that examining long double values on those host
with the i386 as a target could become possible.
The only problem is that the FP data registers are only 10 bytes wide,
but this can be taken care of by using REGISTER_CONVERT_TO_* macros.
I have already been experimenting with this setup, and should be able
to provide the necessary patches without too much delay.
Mark
[1] AFAICT the i960 extended floating point type is identical to the
i387 type altough the definitions of `floatformat_i960_ext' differs
from `floatformat_i387_ext'.
From hjl@lucon.org Wed Oct 20 23:06:00 1999
From: hjl@lucon.org (H.J. Lu)
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com (GDB)
Subject: Re: x86 fpu
Date: Wed, 20 Oct 1999 23:06:00 -0000
Message-id: <19991021060600.A00CB1B494@ocean.lucon.org>
References: <5m3dv56cuz.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00083.html
Content-length: 3493
>
> >>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
> Mark> HJ, what else will have to happen with GDB before you will
> Mark> consider dropping your special Linux GDB based on 4.17? IMHO we
> Mark> should make sure that the Linux community starts doing their GDB
> Mark> development based on the current CVS version as soom as
> Mark> possible.
>
> I believe that H.J.'s private versions of the GNU toolchain have been
> a great disservice to both the GNU/Linux and the larger GNU community.
I certainly don't agree :-). It is a pain for me to maintain my
private versions. But I hate to see the Linux people nowhere to
go for help. Do you really honestly believe that a new official
version should be made whenever a serious Linux related bug is
fixed or we have to live with the bug which mainly affects Linux?
>
> Whatever short term advantage may be gained by having private versions
> is far outweighed by the long term consequences. All the consequences
> may not even be evident to the person or organization that created the
> splinter branch.
>
> * Users are not adequately informed that they are using a splinter
> version, and send bug reports, requests for help, etc. to people
> who are unable to help them.
I never misled anyone. Are you really ready to devote your time
to support the Linux community? I screen the Linux bug reports
first and forward them to appropriate people if I cannot help
them myself.
>
> * Users cannot use the most current software when it is released, but
> must wait until it is incorporated into the splinter version.
The offical GNU software is not for Linux only. It may not have
all the Linux related bug fixes and features. Do you want to
delay a release just because of Linux?
>
> * Users of the official version of the software do not benefit from
> the enhancements found only in the splinter version.
I have been sending my patches to the appropriate people. But they
don't work only for Linux. My patches have to wait, but Linux cann't.
It is not that unusual to take a few months or more for my patches
to be installed. What do we do?
>
> * Pontential contributors cannot track the development snapshots,
> because support for their (host and/or target) system requires
> changes from the splinter version.
Please talk to Linux/PPC and Linux/i370 people.
>
> * Less time is available for improving the software because more time
> is necessary for managing divergence. This is difficult enough when
> all of the changes have been written by one person, or from one org-
> anization, but the recordkeeping burden is even greater when changes
> from many unrelated people (since copyright assignments are required
> for any substantial changes).
>
> When divergence is carefully managed, it is relatively "easy" to
> isolate individual changes to submit patches.
>
> The problem is that this feeds on itself. If there is no time to
> submit changes, refining them when required, etc.; the divergence
> grows and it becomes even more difficult. Eventually the threshold
> grows so high that it is extremely unlikely that the differences
> will ever be resolved.
Most of my changes have been sent in. I don't bother to send new
ones since
1. Old ones are still pending.
2. New ones are still changing.
I will work with everyone to merge my changes. But it doesn't mean
I will stop working for the Linux community. We have different
priorities. That is life.
H.J.
From shebs@cygnus.com Wed Oct 20 23:57:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: hjl@lucon.org
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Wed, 20 Oct 1999 23:57:00 -0000
Message-id: <199910210657.XAA08245@andros.cygnus.com>
References: <19991021060600.A00CB1B494@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00084.html
Content-length: 2467
Date: Wed, 20 Oct 1999 23:06:00 -0700 (PDT)
From: hjl@lucon.org (H.J. Lu)
[...] It is a pain for me to maintain my
private versions. But I hate to see the Linux people nowhere to
go for help. Do you really honestly believe that a new official
version should be made whenever a serious Linux related bug is
fixed or we have to live with the bug which mainly affects Linux?
That's not necessarily a bad idea... If one were to look at which
platform has the largest number of GDB-using programmers these days,
it would most likely be GNU/Linux by far. Why can't the GDB release
schedule be adjusted to accommodate the majority of users?
I have been sending my patches to the appropriate people. But they
don't work only for Linux. My patches have to wait, but Linux cann't.
It is not that unusual to take a few months or more for my patches
to be installed. What do we do?
This is the genesis of the situation. Patch submissions should be
acted upon promptly, whether to accept or reject. It's my
responsibility to see that this happens, and if I fail at that,
I'm not going to fault anyone for coming up with workarounds like
splinter versions.
I hope everybody agrees that patch turnaround has improved over the
past several months. It's still not where it should be; if you feel a
worthy patch is being ignored, please send me mail with lots of
capital letters and exclamation points, or call me on the phone at
+1 408 542 9678.
I will work with everyone to merge my changes. But it doesn't mean
I will stop working for the Linux community. We have different
priorities. That is life.
This should not be true however. I used to think this myself, until
RMS pointed out that since Linux is one of the official kernels for
the GNU system, GDB support for it ought to be a higher priority than
support for non-GNU systems. Of course, GDB is still free software
like always, and I still want to encourage people to contribute
improvements for non-GNU systems as well.
Lately, Jim Blandy and Jim Kingdon have stepped up to the task of
making sure the FSF version of GDB is fully functional for GNU/Linux,
and there has been considerable progress, as witness the discussion of
x86 float support. Also, Scott Bambrough has been hard at work on
Netwinder (ARM) support, and Kevin Buettner is on PowerPC. At this
rate, I expect that the upcoming 5.0 release will be the version of
choice for GNU/Linux.
Stan
From eliz@gnu.org Thu Oct 21 04:40:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:40:00 -0000
Message-id: <199910211140.HAA06700@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npso36hqr3.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00085.html
Content-length: 1428
> Keep in mind that the goal is not to eliminate tm-go32.h and the
> others; I expect each target will always need to make some tweaks to
> the base definition provided by tm-i386.h.
>
> (Does that answer the question? Not sure...)
Yes, it does, for me at least. Thanks.
> The tm-linux.h header does this now --- look for LD_I387.
>
> Perhaps the ideal solution would be for configure to determine which
> floating-point formats the host supports, and #define some symbol like
> HOST_X86_EXTENDED_REAL_TYPE. Then, tm-i386.h could use that as the
> virtual type for FPU registers.
>
> But this is an issue which can be dealt with separately. For now, I
> think it's fine for the more specific i386/tm-*.h files to override
> REGISTER_VIRTUAL_TYPE in order to get the full precision.
How about agreeing that every x86 platform uses LD_I387 to signal
support for long double in this context, and then modify tm-i386.h to
convert the FP registers to long double values? Then all that's left
is to arrange for configure to define or undefine LD_I387. Until
configure does that, the platform-specific tm-* files will only have
to define LD_I387.
> If REGISTER_CONVERTIBLE(i) is zero, you should never call
> REGISTER_CONVERT_TO_VIRTUAL or REGISTER_CONVERT_TO_RAW on the value of
> that register. I see that go32-nat.c does this, but that's incorrect.
If go32-nat.c is the only one that does that, then I'll correct it.
From eliz@gnu.org Thu Oct 21 04:41:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:41:00 -0000
Message-id: <199910211141.HAA06784@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npr9ipj50y.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00086.html
Content-length: 212
> I'm not sure what you mean, here. Do you want "info all-registers" to
> print the opcode and the FPU instruction pointer selector as a single
> word?
Yes, I think this is what "info all-registers" should do.
From eliz@gnu.org Thu Oct 21 04:42:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jtc@redback.com
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:42:00 -0000
Message-id: <199910211142.HAA06910@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <nppuy9j4b0.fsf@zwingli.cygnus.com> <5mpuy94x6e.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00088.html
Content-length: 651
> If GDB can easily handle 48 bit registers, I'd prefer just having $fip
> and $fop.
``Easily handle'' in what way? You can have a variable that holds 48
bits if the host supports more than 32 bits (usually, a long long).
But if you want to use it to poke around the address, using 48-bit far
pointer is going to be a system-dependent mess in many environments,
because of the different ways they implement memory protection (and
leave back doors for breaching it ;-).
> I do have problems with $fcseg and $fcoff, since
> there is nothing that describes the FPU Instruction Pointer as the FPU
> Code Pointer.
Will $fiseg and $fioff be okay, then?
From eliz@gnu.org Thu Oct 21 04:42:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: kettenis@wins.uva.nl
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:42:00 -0000
Message-id: <199910211142.HAA06867@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <199910201754.TAA01496@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00087.html
Content-length: 175
> I also peeked at print_387_status in go32-nat.c
> (which I assume is your work)
The current version is my work, but it's based heavily on what Robert
Hoehne did before me.
From eliz@gnu.org Thu Oct 21 04:43:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: kettenis@wins.uva.nl
Cc: jtc@redback.com, jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:43:00 -0000
Message-id: <199910211143.HAA06995@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <nppuy9j4b0.fsf@zwingli.cygnus.com> <5mpuy94x6e.fsf@jtc.redbacknetworks.com> <199910202032.WAA23021@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00089.html
Content-length: 658
> I don't think having an 48-bit $fip and $fop is a good idea. At least
> in 32-bit protected mode they really are segment selector and offset
> pairs. The segment selector is used to lookup the linear address of
> the segment via the LDT. This is conceptually very different from the
> offset. This is probably also the reason why Jim had initially chosen
> $fcs and $fds for the segment selector of the instruction pointer and
> operand (data) pointer.
If we want to be pedantic, it's not a segment selector, but a segment
descriptor selector.
I think it's not important to make the distinction. Many people say
"DS segment" in protected mode also.
From eliz@gnu.org Thu Oct 21 04:44:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: kettenis@wins.uva.nl
Cc: jtc@redback.com, jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 04:44:00 -0000
Message-id: <199910211143.HAA07056@mescaline.gnu.org>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npso36hqr3.fsf@zwingli.cygnus.com> <5miu414vn5.fsf@jtc.redbacknetworks.com> <199910210110.DAA25865@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00090.html
Content-length: 321
> You'll also notice that all the other
> i386 ports (including Linux) have a 96-bit `long double'. In other
> words `sizeof (long double)' is 12.
A `long double' on x86 is always 10 bytes; sizeof reports 12 because
of alignment considerations. The extra 2 bytes are junk and will
never be used by any FP instruction.
From kettenis@wins.uva.nl Thu Oct 21 06:34:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@gnu.org
Cc: jtc@redback.com, jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 06:34:00 -0000
Message-id: <199910211332.PAA00729@delius.kettenis.local>
References: <199910151716.MAA03441@zwingli.cygnus.com> <5m7lkks1wi.fsf@jtc.redbacknetworks.com> <npvh84j7t2.fsf@zwingli.cygnus.com> <5mwvsjoyu0.fsf@jtc.redbacknetworks.com> <199910201347.JAA28369@mescaline.gnu.org> <npso36hqr3.fsf@zwingli.cygnus.com> <5miu414vn5.fsf@jtc.redbacknetworks.com> <199910210110.DAA25865@delius.kettenis.local> <199910211143.HAA07056@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00091.html
Content-length: 1508
Date: Thu, 21 Oct 1999 07:43:54 -0400
From: Eli Zaretskii <eliz@gnu.org>
> You'll also notice that all the other
> i386 ports (including Linux) have a 96-bit `long double'. In other
> words `sizeof (long double)' is 12.
A `long double' on x86 is always 10 bytes; sizeof reports 12 because
of alignment considerations. The extra 2 bytes are junk and will
never be used by any FP instruction.
Indeed. But we're not alone in this respect. The m68881, i960,
m88110 and arm extended floating point types are all 80-bit types that
actually use 96-bits and contain 16 unused bits. By having
#define TARGET_LONG_DOUBLE_BIT 80
as `tm-linux.h' does, we're disabling a lot of the code already
contained in GDB that deals with the `long double' type.
Note that in `tm-go32.h' there is a
#undef TARGET_LONG_DOUBLE_BIT
#define TARGET_LONG_DOUBLE_BIT 96
So DJGPP is already treating the 80-bit extended types as a 96-bit
type.
I'm proposing that all i386 systems that switch to the new common
floating point register layout that somehow support `long double',
shoule have
#define TARGET_LONG_DOUBLE_BIT 96
#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext
in their `tm-xxx.h' file and
#define HOST_LONG_DOUBLE_FORMAT &floatformat_i387_ext
in their `xm-xxx.h' file.
Then it will be very easy to support the i387 data registers as `long
doubles' on hosts that have an equivalent type, without the LD_387
kludge that's now used by DJGPP and Linux/i386.
Mark
From khendricks@admin.ivey.uwo.ca Thu Oct 21 07:13:00 1999
From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>
To: hjl@lucon.org, shebs@cygnus.com
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 07:13:00 -0000
Message-id: <11868.940515225.0@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 1999-q4/msg00092.html
Content-length: 1757
Hi,
Just to add my 2 cents to the fire.
I think that what H.J. Lu does for gdb and Linux definitely has added value in
the past especially for PowerPC.
For example, before Kevin Buettner officially joined gdb, the powerpc camp was
out on its own. Many months ago (a year?) we tried to get gdb to support PPC in
gdb 4.17 by contributing a patch which was rejected since its author (Kevin
Buettner) had not recently signed a copyright assignment (although he had in the
past). We requested the proper forms but nothing ever came from it.
Meanwhile H.J. Lu's gdb included ppc support and even includes linuxthreads
support (which finally made it possible for me to debug native_threads JDK's as
part of the Blackdown effort). If I had waited for "official" support, all
development would have ground to a halt long ago.
Basically, H.J. Lu's tools have simply been a big help.
His tools have filled a need that the GDB effort should have been filling. If
they had, there would have been no need for a splinter in the first place (as I
think Stan pointed out).
Right now, gdb on PowerPC is still not completely stable debugging
shared-libraries (missing symbols, multiple functions mapping to the same
address, etc), but what H.J. Lu has is much better than what we are seeing
officially.
I will use which ever set of tools fixes that problem, splinter or not.
The GDB project has the methods to "fix this splinter issue itself"... eliminate
the need, and the splinter's will go away.
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
^ permalink raw reply [flat|nested] 2+ messages in thread