* Re: x86 FPU support: "info float" and `long double'
[not found] <199910211634.SAA03952@delius.kettenis.local>
@ 1999-10-21 11:26 ` J.T. Conklin
0 siblings, 0 replies; 3+ messages in thread
From: J.T. Conklin @ 1999-10-21 11:26 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb, gdb-patches
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> Anyway, the output looks like:
Mark> status 0x3800: flags 0000; top 7;
Mark> control 0x37f: 64 bit; NEAR; mask INVAL DENOR DIVZ OVERF UNDER LOS;
Mark> last FP instruction: opcode 0xdd05; pc 0x23:0x8048495; operand 0x2b:0x8048f04
Mark> regno tag msb lsb value
Mark> => 7: valid 4000c90fdaa22168c000 3.141592653589793116
Mark> 6: empty 3ff7d100000000000000 0.006378173828125
Mark> 5: empty 40098000000000000000 1024
Mark> 4: empty 3fff8000000000000000 1
Mark> 3: empty 3fff8000000000000000 1
Mark> 2: empty 3ffb9d8909ff2e48e8c0 0.076921537494659423997
Mark> 1: empty 3ffbdaf3e93361992eb3 0.10691053569844352396
Mark> 0: empty 00000000000000000000 0
Mark> Suggestions for improvement are welcome!
The CAD-UL XDB386 front end we have for our emulator has the following
output (this example is from the user's manual, it's not connected to
a system with a FPU at the moment):
ST0 <zero> <valid>
ST1 1e+00 <valid>
ST2 1e+02 <valid>
ST3 1e+03 <valid>
ST4 1e+04 <valid>
ST5 1e+05 <valid>
ST6 1e+06 <valid>
ST7 1e+07 <valid>
FIP 0x000000000000 sel = GDT(0) rpl = 0 off=0x00000000
FDP 0x000000000000 sel = GDT(0) rpl = 0 off=0x00000000
FSW 0x0000 by/c3 c2 c1 c0/T0/es/sf/pe/sf/pe/ue/oe/ze/de/ie
FCW 0x037f i/NE/EP/PM/UM/OM/ZM/DM/IM
FTW 0x0000 0:VA/1:VA/2:VA/3:VA/4:VA/5:VA/6:VA/7:VA
I'm not suggesting that it be used, but it does have some aspects that
I prefer over your proposed output:
* A column-oriented format is used for all fields. I especially find
it difficult to determine the value of the control and status words.
A little white space makes all the difference.
* The exeception bits are listed for both the mask in the control word
and the sticky bits in the status word.
* The values of the registers are output before the tag. For the most
part, the value is more important that the tag.
* Personal preference, but I don't think the column header is useful
or necessary.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Oct 21 12:54:00 1999
From: jtc@redback.com (J.T. Conklin)
To: hjl@lucon.org (H.J. Lu)
Cc: gdb@sourceware.cygnus.com (GDB)
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 12:54:00 -0000
Message-id: <5myacwmqwr.fsf@jtc.redbacknetworks.com>
References: <19991021060600.A00CB1B494@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00105.html
Content-length: 3211
>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
>> 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.
H.J.> I certainly don't agree :-). It is a pain for me to maintain my
H.J.> private versions. But I hate to see the Linux people nowhere to
H.J.> go for help. Do you really honestly believe that a new official
H.J.> version should be made whenever a serious Linux related bug is
H.J.> fixed or we have to live with the bug which mainly affects Linux?
No, I don't think that there needs to be a new official version when a
serious bug is fixed; nor do I think that Linux users should live with
bugs (Linux specific or not) until the next official release.
I do think development snapshots could be made to serve the purpose of
your private versions, or in the very worst case your private versions
could would contain minimal changes over the most recent snapshot.
I believe this because in my experience it is extremely quick and easy
get a well written patch to fix a bug into GDB, or any other toolchain
component. While not instantaneous, the week or two between the time
a patch is submitted and the time it shows up in a snapshot is usually
not unacceptable. In those rare cases, I check the patch into our
production repository at the same time I submit the patch; with full
knowledge that I'll be responsible for tracking that divergence until
the bug is fixed in the repository.
It takes longer for contributions from people who do not have active
copyright assignments, new features, or poorly written or thought out
patches; but not enough to justify a splinter branch. If there is a
problem causing significant delays, that is a problem that needs to be
fixed.
When I came to RedBack, it took about a week after I had mailed my new
copyright assignments to the FSF before the FSF secretary had e-mailed
notification of the assignment to the mailing lists. If there is a
delay processing these forms, complain to RMS.
I know that there were problems getting Linux thread support into the
main sources. I can only assume that some aspects of the changes made
them not acceptable "as-is", but I don't know the details. I believe
what should have happened is the changes should have been reviewed
promptly; the contributor told what modifications were required to be
made before the patch can be accepted; the contributor making those
changes; perhaps a few iterations of that and the the patch integrated
into the official sources.
I don't know where the process broke down, but by the time I became
aware of it, it appeared to me that one side believed that the code
was not ready, the other that the other was being obstinate and not
integrating code, and that nothing was being done to reconcile the
problem because the splinter version was available.
There have been messages from many Linux users that appreciate your
version. But nothing will convince me otherwise that both GDB as a
whole and GDB on Linux would have been better off had there not been
a splinter version.
If you think the process is still broken, complain to Stan.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Oct 21 13:01:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 13:01:00 -0000
Message-id: <5mu2nkmqko.fsf@jtc.redbacknetworks.com>
References: <199910211743.KAA08509@andros.cygnus.com> <991021181855.ZM3563@ocotillo.lan>
X-SW-Source: 1999-q4/msg00106.html
Content-length: 1110
>>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes:
>> I must confess I'm not up on the technical state of LinuxPPC patches
>> however; I remember Kevin B wanting to make some further changes
>> before incorporating. Kevin?
Kevin> I got my patches working with the head of the development tree several
Kevin> weeks ago. (Actually, Gary Thomas deserves a lot of the credit.)
Kevin> However there are a great many similarities between rs6000-tdep.c and
Kevin> the ppclinux-tdep.c. I would really like to make the common parts
Kevin> truly common as well as revamp it so that it uses the gdbarch
Kevin> machinery, but this'll take more time than I have at the moment. So
Kevin> it might be better for me to commit what I have so that linux/ppc is
Kevin> supported in the Cygnus tree.
I truly hope that you can find/make time to do this right.
It seems that every time GDB's standards have been relaxed to allow
code to be integrated before it is really ready, regardless of the
good intentions of the author/contributor, it is never revisited.
--jtc
--
J.T. Conklin
RedBack Networks
From Grant.Edwards@comtrol.com Thu Oct 21 13:16:00 1999
From: Grant.Edwards@comtrol.com
To: gdb@sourceware.cygnus.com
Subject: wrong htons() used?
Date: Thu, 21 Oct 1999 13:16:00 -0000
Message-id: <19991021151610.A3919@comtrol.com>
X-SW-Source: 1999-q4/msg00107.html
Content-length: 499
When gdb is built for target arm-elf on a linux i386, it uses
the wrong htons() definition when building stuff in the
rdi-share directory. The proper behavior of htons() on a i386
system is to swap the two bytes. In arm-elf-gdb, it doesn't.
I assume that what is happening is that it's using the htons()
that would be applicible if gdb was going to execute on an
big-endian ARM architecture, but I can't figure out where this
happens...
Any pointers?
--
Grant Edwards
Grant.Edwards@comtrol.com
From kettenis@wins.uva.nl Thu Oct 21 13:42:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jtc@redback.com
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 13:42:00 -0000
Message-id: <199910212042.WAA01389@delius.kettenis.local>
References: <19991021060600.A00CB1B494@ocean.lucon.org> <5myacwmqwr.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00108.html
Content-length: 2606
From: jtc@redback.com (J.T. Conklin)
Date: 21 Oct 1999 12:53:40 -0700
>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
>> 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.
H.J.> I certainly don't agree :-). It is a pain for me to maintain my
H.J.> private versions. But I hate to see the Linux people nowhere to
H.J.> go for help. Do you really honestly believe that a new official
H.J.> version should be made whenever a serious Linux related bug is
H.J.> fixed or we have to live with the bug which mainly affects Linux?
No, I don't think that there needs to be a new official version when a
serious bug is fixed; nor do I think that Linux users should live with
bugs (Linux specific or not) until the next official release.
I do think development snapshots could be made to serve the purpose of
your private versions, or in the very worst case your private versions
could would contain minimal changes over the most recent snapshot.
Yes! The GDB maintainers and the Linux community (including HJ)
should make a serious effort to make this possible again. That was
why I asked HJ what would need to happen before he would consider
dropping his 4.17 based fork.
I believe this because in my experience it is extremely quick and easy
get a well written patch to fix a bug into GDB, or any other toolchain
component. While not instantaneous, the week or two between the time
a patch is submitted and the time it shows up in a snapshot is usually
not unacceptable. In those rare cases, I check the patch into our
production repository at the same time I submit the patch; with full
knowledge that I'll be responsible for tracking that divergence until
the bug is fixed in the repository.
While this may be the situation right now, this has not always been
the case. In the period after the official realease of gdb 4.17
development was pretty closed, snapshots were only available in a
"secret" directory on the cygnus ftp server and appeared very
irregualar.
While I agree with a lot of points you make in your message, I don't
think spelling them out again and again is a very constructive
approach. Instead we should be writing code and see if we can get a
few more people from the Linux community to contribute to the
official GDB version, possibly by looking at the differences between
HJ's version and the current CVS version, breaking them up in tiny
patches, do some cleaning up and feeding them to the maintainers.
Mark
From jtc@redback.com Thu Oct 21 13:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Grant.Edwards@comtrol.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 13:49:00 -0000
Message-id: <5mpuy8moc9.fsf@jtc.redbacknetworks.com>
References: <19991021151610.A3919@comtrol.com>
X-SW-Source: 1999-q4/msg00109.html
Content-length: 858
>>>>> "Grant" == Grant Edwards <Grant.Edwards@comtrol.com> writes:
Grant> I assume that what is happening is that it's using the htons()
Grant> that would be applicible if gdb was going to execute on an
Grant> big-endian ARM architecture, but I can't figure out where this
Grant> happens...
This is quite odd, since htons() should be a function provided by your
host system. I can't find any htons() implementation or other config-
ury that would override that.
When trying to track down problems like this, I often examine the pre-
processed output of the sources to see if I find something unexpected.
You can do this by grabbing the line make invokes, replacing -c with
-E, and removing the -o etherdrv.o).
If that doesn't pan out, link with the -Map option to determine where
it's pulling in htons.o
--jtc
--
J.T. Conklin
RedBack Networks
From scottb@netwinder.org Thu Oct 21 14:13:00 1999
From: Scott Bambrough <scottb@netwinder.org>
To: egcs@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 14:13:00 -0000
Message-id: <380F80F1.394F7493@netwinder.org>
References: <19991021151610.A3919@comtrol.com>
X-SW-Source: 1999-q4/msg00110.html
Content-length: 1010
The problem is in tm-arm.h. It defines TARGET_BYTE_ORDER_SELECTABLE.
The compatibility code in gdbarch.c
defaults to big endian (see line 2777). Add the following to tm-arm.h:
#define TARGET_BYTE_ORDER_DEFAULT LITTLE_ENDIAN
I think this will fix your problem. I have fixed this while merging my
target code for Linux with the current ARM target code. I have
defaulted the embedded targets to LITTLE_ENDIAN. Any objections.
Scott
Grant.Edwards@comtrol.com wrote:
>
> When gdb is built for target arm-elf on a linux i386, it uses
> the wrong htons() definition when building stuff in the
> rdi-share directory. The proper behavior of htons() on a i386
> system is to swap the two bytes. In arm-elf-gdb, it doesn't.
>
> I assume that what is happening is that it's using the htons()
> that would be applicible if gdb was going to execute on an
> big-endian ARM architecture, but I can't figure out where this
> happens...
>
> Any pointers?
>
> --
> Grant Edwards
> Grant.Edwards@comtrol.com
From Grant.Edwards@comtrol.com Thu Oct 21 14:21:00 1999
From: Grant.Edwards@comtrol.com
To: Scott Bambrough <scottb@netwinder.org>
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 14:21:00 -0000
Message-id: <19991021162144.A15266@comtrol.com>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org>
X-SW-Source: 1999-q4/msg00111.html
Content-length: 687
On Thu, Oct 21, 1999 at 05:09:05PM -0400, Scott Bambrough wrote:
> The problem is in tm-arm.h. It defines TARGET_BYTE_ORDER_SELECTABLE.
> The compatibility code in gdbarch.c
> defaults to big endian (see line 2777). Add the following to tm-arm.h:
>
> #define TARGET_BYTE_ORDER_DEFAULT LITTLE_ENDIAN
>
> I think this will fix your problem. I have fixed this while merging my
> target code for Linux with the current ARM target code. I have
> defaulted the embedded targets to LITTLE_ENDIAN. Any objections.
I'm not sure I understand the fix -- will this require that the
target ARM processor be running in little-endian mode?
--
Grant Edwards
Grant.Edwards@comtrol.com
From jimb@cygnus.com Thu Oct 21 14:40:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 14:40:00 -0000
Message-id: <npogdsgzpb.fsf@zwingli.cygnus.com>
References: <19991019182843.E7C093FC1@valinux.com> <npemerjigt.fsf@zwingli.cygnus.com> <199910192343.BAA00273@delius.kettenis.local> <5m3dv56cuz.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00112.html
Content-length: 1818
> 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 don't really agree. I think there are several problems with the way
they've been handled, by various parties, but in principle I think
they're an okay thing.
The proper role of a patch set series is to allow some slack between
Linux and the standard GDB distribution. Linux users don't have to
wait until the next GDB release to get a bug fixed. For the GDB
maintainers, the patch set can also serve as a guide to what needs to
get fixed --- it's a screened list of bug reports.
However, H.J.'s patch sets have been pushed to meet demands beyond
what they can do well. This happened for various reasons:
- For a while, GDB releases were not frequent enough. Under such
conditions, patch sets will inevitably get uncomfortably large. The
situation is improving, here.
- For a while, the GDB maintainers did not spend much time trying to
incorporate fixes from the net, or working with contributors to get
things in. I hope this has changed. I know a lot of us at Cygnus
have worked to improve this.
- If I were to fault H. J. at all, I might wish that he were more
sympathetic to maintainer's objections to patches. It's appropriate
for a maintainer to push back on the submitter of a patch to clean
it up, but sometimes I've felt as if H. J. were saying, "Well, it
works for me --- take it or leave it."
The rules for patch sets should be:
- The GDB maintainers spend time incorporating patches, and make frequent
releases, so the patch set can stay small.
- The patch set maintainer works to adapt patches to maintainers'
concerns, again, so the patch set can stay small.
If handled that way, I think they're a healthy thing.
From Grant.Edwards@comtrol.com Thu Oct 21 14:57:00 1999
From: Grant.Edwards@comtrol.com
To: "J.T. Conklin" <jtc@redback.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 14:57:00 -0000
Message-id: <19991021165702.A25314@comtrol.com>
References: <19991021151610.A3919@comtrol.com> <5mpuy8moc9.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00113.html
Content-length: 1445
On Thu, Oct 21, 1999 at 01:49:10PM -0700, J.T. Conklin wrote:
> Grant> I assume that what is happening is that it's using the htons()
> Grant> that would be applicible if gdb was going to execute on an
> Grant> big-endian ARM architecture, but I can't figure out where this
> Grant> happens...
>
> This is quite odd, since htons() should be a function provided by your
> host system. I can't find any htons() implementation or other config-
> ury that would override that.
>
> When trying to track down problems like this, I often examine the pre-
> processed output of the sources to see if I find something unexpected.
> You can do this by grabbing the line make invokes, replacing -c with
> -E, and removing the -o etherdrv.o).
>
> If that doesn't pan out, link with the -Map option to determine where
> it's pulling in htons.o
I'm confused. I ran the source file through gcc -E, and all
looked well. There was an extern decl for htons, and calls
to htons in the right places.
I built it with -Wl,-Map,gdb.map and htons shows up in the map
file, and everything works.
I don't know what I did to fix it, so I take out
-Wl,-Map,gdb.map and rebuild it without generating the map
file, and it doesn't work.
I put the -Wl,-Map,gdb.map back in, and this time htons
_doesn't_ show up in the map file and the binary doesn't work.
I can't figure out what I did to make it work that one time...
--
Grant Edwards
Grant.Edwards@comtrol.com
From scottb@netwinder.org Thu Oct 21 15:10:00 1999
From: Scott Bambrough <scottb@netwinder.org>
To: Grant.Edwards@comtrol.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 15:10:00 -0000
Message-id: <380F8E73.68E849EE@netwinder.org>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com>
X-SW-Source: 1999-q4/msg00114.html
Content-length: 530
Grant.Edwards@comtrol.com wrote:
>
> I'm not sure I understand the fix -- will this require that the
> target ARM processor be running in little-endian mode?
>
Yes.
When I read your message I thought the problem you were having was
getting a target built for a little endian ARM machine. The code as it
stands now, defaults to big endian for the target. AFAIK, the
endianness of the code on the host is controlled by HOST_BYTE_ORDER in
xm-arm.h. This is defined as LITTLE_ENDIAN which should be good for
i386 Linux.
Scott
From Grant.Edwards@comtrol.com Thu Oct 21 15:15:00 1999
From: Grant.Edwards@comtrol.com
To: "J.T. Conklin" <jtc@redback.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 15:15:00 -0000
Message-id: <19991021171517.A25480@comtrol.com>
References: <19991021151610.A3919@comtrol.com> <5mpuy8moc9.fsf@jtc.redbacknetworks.com> <19991021165702.A25314@comtrol.com>
X-SW-Source: 1999-q4/msg00115.html
Content-length: 678
On Thu, Oct 21, 1999 at 04:57:02PM -0500, Grant.Edwards@comtrol.com wrote:
> I don't know what I did to fix it, so I take out
> -Wl,-Map,gdb.map and rebuild it without generating the map
> file, and it doesn't work.
OK, this is wierd. Running gcc -E -O2 produces source with an
external declaration for htons() but no calls. Running gcc -E
without -O2 generates source with calls to htons().
I didn't know that -O altered the pre-processor's behavior.
That doesn't sound too kosher.
The object files produced with and without -O2 differ
similarly, so the binary works if that particular file is
compiled with optimization off.
--
Grant Edwards
Grant.Edwards@comtrol.com
From kettenis@wins.uva.nl Thu Oct 21 15:18:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: Grant.Edwards@comtrol.com
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 15:18:00 -0000
Message-id: <199910212218.AAA00212@delius.kettenis.local>
References: <19991021151610.A3919@comtrol.com> <5mpuy8moc9.fsf@jtc.redbacknetworks.com> <19991021165702.A25314@comtrol.com>
X-SW-Source: 1999-q4/msg00116.html
Content-length: 1233
Date: Thu, 21 Oct 1999 16:57:02 -0500
From: Grant.Edwards@comtrol.com
I'm confused. I ran the source file through gcc -E, and all
looked well. There was an extern decl for htons, and calls
to htons in the right places.
I built it with -Wl,-Map,gdb.map and htons shows up in the map
file, and everything works.
I don't know what I did to fix it, so I take out
-Wl,-Map,gdb.map and rebuild it without generating the map
file, and it doesn't work.
I put the -Wl,-Map,gdb.map back in, and this time htons
_doesn't_ show up in the map file and the binary doesn't work.
I can't figure out what I did to make it work that one time...
You probably disabled optimization, and renabled it later on. On my
system, which uses glibc-2.1, if you compile with optimization htons
is an optimizing macro that uses inline assembly to do the conversion (see
/usr/include/netinet/in.h and /usr/include/bits/byteswap.h). Somehow
you are using ARM headers to compile i386 code or the other way
around. As a workaround you could try to compile without
optimization, but that doesn't really solve your problem. If you're
using GCC you could use the `-v' compiler option to see what headers
are used.
Mark
From Grant.Edwards@comtrol.com Thu Oct 21 15:22:00 1999
From: Grant.Edwards@comtrol.com
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 15:22:00 -0000
Message-id: <19991021172238.A25707@comtrol.com>
References: <19991021151610.A3919@comtrol.com> <5mpuy8moc9.fsf@jtc.redbacknetworks.com> <19991021165702.A25314@comtrol.com> <199910212218.AAA00212@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00117.html
Content-length: 550
On Fri, Oct 22, 1999 at 12:18:18AM +0200, Mark Kettenis wrote:
> You probably disabled optimization, and renabled it later on.
Yup, just discovered that.
> Somehow
> you are using ARM headers to compile i386 code or the other way
> around.
That's what I suspected was going on -- something in netinet/in.h
is getting fooled by something that was defined for the target.
> If you're using GCC you could use the `-v' compiler option to
> see what headers are used.
Good idea. I'll try that next.
--
Grant Edwards
Grant.Edwards@comtrol.com
From jtc@redback.com Thu Oct 21 15:58:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Grant.Edwards@comtrol.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 15:58:00 -0000
Message-id: <5m6700mid7.fsf@jtc.redbacknetworks.com>
References: <19991021151610.A3919@comtrol.com> <5mpuy8moc9.fsf@jtc.redbacknetworks.com> <19991021165702.A25314@comtrol.com> <19991021171517.A25480@comtrol.com>
X-SW-Source: 1999-q4/msg00118.html
Content-length: 566
>>>>> "Grant" == Grant Edwards <Grant.Edwards@comtrol.com> writes:
Grant> OK, this is wierd. Running gcc -E -O2 produces source with an
Grant> external declaration for htons() but no calls. Running gcc -E
Grant> without -O2 generates source with calls to htons().
Grant> I didn't know that -O altered the pre-processor's behavior.
Grant> That doesn't sound too kosher.
I think that with -O, gcc passes -D__OPTIMIZE__ to the preprocessor.
So preprocessing can be effected by optimization if __OPTIMIZE__ is
used.
--jtc
--
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Thu Oct 21 16:51:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 16:51:00 -0000
Message-id: <npn1tcgtmq.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> <npso36hqr3.fsf@zwingli.cygnus.com> <5miu414vn5.fsf@jtc.redbacknetworks.com> <199910210110.DAA25865@delius.kettenis.local>
X-SW-Source: 1999-q4/msg00119.html
Content-length: 3541
I agree that the floating-point stuff in tm-linux.h is not the way it
should be. Yes, the way LD_I387 and the conversion stuff are defined
isn't correct. But for now, we should focus on getting tm-i386.h the
way we all want it. If we do that right, then tm-linux.h will be
straightforward to fix.
I'm having a hard time following a lot of the discussion about
floating-point formats. Here is my present understanding of
how things work; please correct me if I say something wrong.
There are three forms floating-point values can take on as they pass
through GDB:
- the register file form
- the `struct value' form
- the host DOUBLEST form
The register file form should be bit-for-bit identical with the way
the processor stores them, because the register file's role is to be a
direct reflection of the processor's state. The REGISTER_RAW_SIZE
macro gives the number of bytes a floating-point value occupies in
this form. GDB has no macro describing the types of registers in the
register file.
GDB uses the `struct value' form for variable values, intermediate
values in expression evaluation, and so on. REGISTER_VIRTUAL_TYPE
gives the type of this form; REGISTER_CONVERTIBLE,
REGISTER_CONVERT_TO_VIRTUAL, and REGISTER_CONVERT_TO_RAW control the
conversion between the register file form and this form, done by
value_of_register, value_from_register, and value_assign.
GDB converts a `struct value' to the host DOUBLEST form whenever it
actually wants to operate on a floating-point value. This conversion
is controlled by {TARGET,HOST}_LONG_DOUBLE_FORMAT and
TARGET_{EXTRACT,STORE}_FLOATING, and carried out by functions like
value_as_double, unpack_double, extract_floating, and store_floating.
(This last conversion is controversial, since it loses information;
ideally, GDB would perform the operations in the target's format,
using some software implementation of IEEE floating point arithmetic.)
It's worth noting that the first conversions, to and from the `struct
value' form, never need to be lossy, because `struct value' can hold
the value in raw target format. REGISTER_VIRTUAL_TYPE just needs to
correctly describe the registers.
So, here's my understanding of folks' suggestions about tm-i386.h:
- REGISTER_VIRTUAL_TYPE should be some type from tm-i387.c, dedicated
to describing FPU registers. That way, it's not dependent on today's
compiler's interpretation of `long double'.
- REGISTER_VIRTUAL_TYPE should be 12 bytes long, and
REGISTER_CONVERT_TO_{VIRTUAL,RAW} should simply account for the
position of the 10-byte value within the 12-byte space.
It makes me a little uncomfortable to have REGISTER_VIRTUAL_TYPE
specify a 12-byte size, while floatformat_i387_ext is a ten-byte
format, but I think it should work fine.
- {TARGET,HOST}_LONG_DOUBLE_{FORMAT,BITS} should be defined as
appropriate in the right tm-*.h and xm-*.h files, not in tm-i386.h.
The latter doesn't know what compiler you're using, and so can't say
how long its types are.
The implications carry on to Linux as follows:
- Once those definitions are corrected in tm-linux.h, the
TARGET_{EXTRACT,STORE}_FLOATING macros will never be used, because
the earlier clauses in extract_floating and store_floating will
apply, so we can delete the TARGET_{EXTRACT,STORE}_FLOATING
definitions from tm-linux.h.
- But tm-linux.h is the only target in GDB that defines them, so we
can remove all references to them from GDB completely.
It looks like Mark's patch has already done this. I'll take a look.
From ac131313@cygnus.com Thu Oct 21 17:07:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: "H.J. Lu" <hjl@lucon.org>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com, jtc@redback.com, jimb@cygnus.com, eliz@gnu.org, gdb-patches@sourceware.cygnus.com
Subject: Re: x86 FPU support: "info float" and `long double'
Date: Thu, 21 Oct 1999 17:07:00 -0000
Message-id: <380FAA6A.8BEE418C@cygnus.com>
References: <19991021171307.87FEC1B493@ocean.lucon.org>
X-SW-Source: 1999-q4/msg00120.html
Content-length: 176
Totally off topic.
The existing i387-tdep.c has:
> puts_unfiltered (...);
It should be using ``..._filtered''. Good time to tweek that as well
:-)
Andrew
From jimb@cygnus.com Thu Oct 21 17:08: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: Thu, 21 Oct 1999 17:08:00 -0000
Message-id: <npln8wgstr.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> <npr9ipj50y.fsf@zwingli.cygnus.com> <199910211141.HAA06784@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00121.html
Content-length: 911
> > 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.
Why? Because FSAVE stores them in the same 32-bit word?
In real-address mode, FSAVE stores them differently. I don't think
the protected-mode FSAVE format reveals anything deep and profound
about the architecture.
Reading the manual gives one the impression that the FPU instruction
pointer, the FPU operand pointer, and the last instruction opcode are
three distinct registers. The only place that associates the
instruction segment with the opcode at all is that diagram. Since
a real-address FSAVE arranges it differently, I think it's only an
artifact of the packing that the two are placed together at all.
So I think the opcode and code segment should be separate registers.
From ac131313@cygnus.com Thu Oct 21 17:35:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant.Edwards@comtrol.com
Cc: Scott Bambrough <scottb@netwinder.org>, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Thu, 21 Oct 1999 17:35:00 -0000
Message-id: <380FB0FC.A5CE946F@cygnus.com>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com>
X-SW-Source: 1999-q4/msg00122.html
Content-length: 1367
Grant.Edwards@comtrol.com wrote:
>
> On Thu, Oct 21, 1999 at 05:09:05PM -0400, Scott Bambrough wrote:
>
> > The problem is in tm-arm.h. It defines TARGET_BYTE_ORDER_SELECTABLE.
> > The compatibility code in gdbarch.c
> > defaults to big endian (see line 2777). Add the following to tm-arm.h:
> >
> > #define TARGET_BYTE_ORDER_DEFAULT LITTLE_ENDIAN
> >
> > I think this will fix your problem. I have fixed this while merging my
> > target code for Linux with the current ARM target code. I have
> > defaulted the embedded targets to LITTLE_ENDIAN. Any objections.
>
> I'm not sure I understand the fix -- will this require that the
> target ARM processor be running in little-endian mode?
FYI, the endianess of the target can be configured dynamically using:
(gdb) set endian {big,little,auto}
the default is somewhat arbitrary. When set to auto it _should_ pick up
the endianess of the target using information in the header file. Check
it with:
(gdb) show endian
I think everyone has agreed that that isn't the problem that is occuring
here.
--
Returning to your problem. I think treating the ``tuned/untuned''
hton*() as the prime suspects is correct. Posibbly tripped by some name
space polution problem. Tried a 3 line program on them? Also, the file
sim/common/sim-endian.c (which I know works :-) might be a useful
reference.
Andrew
From ac131313@cygnus.com Thu Oct 21 17:54:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 17:54:00 -0000
Message-id: <380FB5B8.D8594C68@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> <npso36hqr3.fsf@zwingli.cygnus.com> <5miu414vn5.fsf@jtc.redbacknetworks.com> <199910210110.DAA25865@delius.kettenis.local> <npn1tcgtmq.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00123.html
Content-length: 1931
Jim Blandy wrote:
> (This last conversion is controversial, since it loses information;
> ideally, GDB would perform the operations in the target's format,
> using some software implementation of IEEE floating point arithmetic.)
(accessed using alu methods added to struct value or struct type :-)
> So, here's my understanding of folks' suggestions about tm-i386.h:
>
> - REGISTER_VIRTUAL_TYPE should be some type from tm-i387.c, dedicated
> to describing FPU registers. That way, it's not dependent on today's
> compiler's interpretation of `long double'.
Check config/mips/tm-mips.h. It is doing similar for the integer
registers. They are defined in terms of builtin_type_uint32 et.al.
(uint32 comes straight from C9X).
Extending gdb's type system to include explicitly sized FP types makes
good sense.
> - REGISTER_VIRTUAL_TYPE should be 12 bytes long, and
> REGISTER_CONVERT_TO_{VIRTUAL,RAW} should simply account for the
> position of the 10-byte value within the 12-byte space.
>
> It makes me a little uncomfortable to have REGISTER_VIRTUAL_TYPE
> specify a 12-byte size, while floatformat_i387_ext is a ten-byte
> format, but I think it should work fine.
>
> - {TARGET,HOST}_LONG_DOUBLE_{FORMAT,BITS} should be defined as
> appropriate in the right tm-*.h and xm-*.h files, not in tm-i386.h.
> The latter doesn't know what compiler you're using, and so can't say
> how long its types are.
>
> The implications carry on to Linux as follows:
>
> - Once those definitions are corrected in tm-linux.h, the
> TARGET_{EXTRACT,STORE}_FLOATING macros will never be used, because
> the earlier clauses in extract_floating and store_floating will
> apply, so we can delete the TARGET_{EXTRACT,STORE}_FLOATING
> definitions from tm-linux.h.
>
> - But tm-linux.h is the only target in GDB that defines them, so we
> can remove all references to them from GDB completely.
Ya!!!
Andrew
From kettenis@wins.uva.nl Thu Oct 21 18:03:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 18:03:00 -0000
Message-id: <199910220103.DAA11146@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> <npn1tcgtmq.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00124.html
Content-length: 6810
From: Jim Blandy <jimb@cygnus.com>
Date: 21 Oct 1999 18:51:25 -0500
I agree that the floating-point stuff in tm-linux.h is not the way it
should be. Yes, the way LD_I387 and the conversion stuff are defined
isn't correct. But for now, we should focus on getting tm-i386.h the
way we all want it. If we do that right, then tm-linux.h will be
straightforward to fix.
Indeed. As my patch shows almost all FP definitions can be removed :-).
I'm having a hard time following a lot of the discussion about
floating-point formats. Here is my present understanding of
how things work; please correct me if I say something wrong.
You're not the only one. Took me a little while to figure it out and
it looks as if almost no maintainer of a specific port has managed to
figure it out. I hope my comments here will help though.
There are three forms floating-point values can take on as they pass
through GDB:
- the register file form
- the `struct value' form
- the host DOUBLEST form
There also is the host `double' which comes into play if the host
HAS_LONG_DOUBLE, but not PRINTF_HAS_LONG_DOUBLE. Such a host will
convert a DOUBLEST to `double' before printing.
The register file form should be bit-for-bit identical with the way
the processor stores them, because the register file's role is to be a
direct reflection of the processor's state. The REGISTER_RAW_SIZE
macro gives the number of bytes a floating-point value occupies in
this form. GDB has no macro describing the types of registers in the
register file.
Indeed. REGISTER_RAW_SIZE is all that matters and should be 10 for
the FP data registers on all x86 targets.
GDB uses the `struct value' form for variable values, intermediate
values in expression evaluation, and so on. REGISTER_VIRTUAL_TYPE
gives the type of this form; REGISTER_CONVERTIBLE,
REGISTER_CONVERT_TO_VIRTUAL, and REGISTER_CONVERT_TO_RAW control the
conversion between the register file form and this form, done by
value_of_register, value_from_register, and value_assign.
GDB converts a `struct value' to the host DOUBLEST form whenever it
actually wants to operate on a floating-point value. This conversion
is controlled by {TARGET,HOST}_LONG_DOUBLE_FORMAT and
TARGET_{EXTRACT,STORE}_FLOATING, and carried out by functions like
value_as_double, unpack_double, extract_floating, and
store_floating.
TARGET_{EXTRACT,STORE}_FLOATING were introduced as part of the
premature Linux/x86 floating point merge. They are only used by the Linux
code, for which they are unnecessary, and I believe they are the wrong
approach. Once the Linux/x86 port has been fixed we should remove all
traces of these macros.
There are some other quantities that are relevant:
TARGET_LONG_DOUBLE_BIT and `sizeof (long double)'. Basically GDB
assumes that it can do an accurate conversion if
TARGET_LONG_DOUBLE_BIT matches `sizeof (long double)'. If in addition
TARGET_LONG_DOUBLE_FORMAT == HOST_LONG_DOUBLE_FORMAT, it simply copies
bytes. Otherwise the function you mention are used.
(This last conversion is controversial, since it loses information;
ideally, GDB would perform the operations in the target's format,
using some software implementation of IEEE floating point arithmetic.)
I believe that GDB will simply fail if DOUBLEST is not equivalent with
the target `long double'. The only lossy conversion seems to happen
when the host cannot print its own `long double'.
It's worth noting that the first conversions, to and from the `struct
value' form, never need to be lossy, because `struct value' can hold
the value in raw target format. REGISTER_VIRTUAL_TYPE just needs to
correctly describe the registers.
So, here's my understanding of folks' suggestions about tm-i386.h:
- REGISTER_VIRTUAL_TYPE should be some type from tm-i387.c, dedicated
to describing FPU registers. That way, it's not dependent on today's
compiler's interpretation of `long double'.
Although introducing a new type looks like a good idea, there are some
problems. The way extract_floating and store_floating work right now,
only the size of the type use used to sitinguish floating point
types. If the size of our new type matches `sizeof (DOUBLEST)' only
conversion from/to TARGET_LONG_DOUBLE_FORMAT is tried which might not
be the right thing.
- REGISTER_VIRTUAL_TYPE should be 12 bytes long, and
REGISTER_CONVERT_TO_{VIRTUAL,RAW} should simply account for the
position of the 10-byte value within the 12-byte space.
This is what my patch does, except that if the host doesn't have an
adequate `long double' type I convert to TARGET_DOUBLE_FORMAT. I
think this is useful since `long double' isn't widely used and for
ordinary `double' arithmetic on the x86 this conversion is exactly
what happens if you pop a value from the FP stack.
It makes me a little uncomfortable to have REGISTER_VIRTUAL_TYPE
specify a 12-byte size, while floatformat_i387_ext is a ten-byte
format, but I think it should work fine.
I think you could define floatformat_i387_ext as a 12-byte format.
The padding is at the end, and never touched by the floatformat
functions. You would probably end up with floatformat_i960_ext (I
didn't verify this).
- {TARGET,HOST}_LONG_DOUBLE_{FORMAT,BITS} should be defined as
appropriate in the right tm-*.h and xm-*.h files, not in tm-i386.h.
The latter doesn't know what compiler you're using, and so can't say
how long its types are.
You never know what the target compiler is. You can only hope that
all compilers on the target have the same idea of a `long double'. I
looked at GCC and it seems that on all x86 ports `long double' is the
i387 extended floating point format and `sizeof (long double)' is 12,
with the exception of OSF/1 (where `long double' is the same as
`double'). That's why I put TARGET_LONG_DOUBLE_{BIT,FORMAT} into
tm-i386.h.
There is no HOST_LONG_DOUBLE_BIT(S). Defining HOST_LONG_DOUBLE_FORMAT
where appropriate is probably a good idea, but AFAICT it is only used
to bypass conversion.
The implications carry on to Linux as follows:
- Once those definitions are corrected in tm-linux.h, the
TARGET_{EXTRACT,STORE}_FLOATING macros will never be used, because
the earlier clauses in extract_floating and store_floating will
apply, so we can delete the TARGET_{EXTRACT,STORE}_FLOATING
definitions from tm-linux.h.
- But tm-linux.h is the only target in GDB that defines them, so we
can remove all references to them from GDB completely.
It looks like Mark's patch has already done this. I'll take a look.
It doesn't remove the traces of TARGET_{EXTRACT,STORE}_FLOATING from
the generic GDB code yet.
Mark
From kettenis@wins.uva.nl Thu Oct 21 18:09:00 1999
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: eliz@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: Unifying the x86 FPU register sets
Date: Thu, 21 Oct 1999 18:09:00 -0000
Message-id: <199910220109.DAA11160@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> <npr9ipj50y.fsf@zwingli.cygnus.com> <199910211141.HAA06784@mescaline.gnu.org> <npln8wgstr.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00125.html
Content-length: 296
From: Jim Blandy <jimb@cygnus.com>
Date: 21 Oct 1999 19:08:48 -0500
So I think the opcode and code segment should be separate registers.
Definitely! If we want to allow people to modify those registers, it
would be really inconvenient if the wouldn't be separate registers.
Mark
^ permalink raw reply [flat|nested] 3+ messages in thread