Re: x86 FPU support: "info float" and `long double'

Re: x86 FPU support: "info float" and `long double'

[Eli Zaretskii]

> My current gdb has
> 
> (gdb) info float
>      st0: 0x3ffed6d6d6d6d6d6d800  Empty Normal 0.8392156862745098200307
>      st1: 0x00000000000000000000  Empty Zero   0

"st0", "st1" etc. implies stack-relative order of the registers.
IMHO, this is wrong: it doesn't present the registers as a stack, and
with each push/pop operation, the entire picture moves up/down, which
is very confusing.  If this format is adopted (I hope not), it won't
make sense to print the TOS pointer (that arrow => shown by Mark in
his example), since the TOS is always st0.

In the physical order, like what go32-nat.c does, the registers cannot
be designated st0, st1, etc., because that's not true.  If 0, 1,
etc. is somehow not good enough, we should use R0, R1, etc., like
Intel does.
From shebs@cygnus.com Thu Oct 21 10:43:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: khendricks@admin.ivey.uwo.ca
Cc: hjl@lucon.org, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 10:43:00 -0000
Message-id: <199910211743.KAA08509@andros.cygnus.com>
References: <199910211413.HAA06667@cygnus.com>
X-SW-Source: 1999-q4/msg00100.html
Content-length: 1974

   Date: Thu, 21 Oct 1999 10:11:22 -0400 (EDT)
   From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>

   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.

Actually, all that did happen a while back - it ended up requiring
some negotiation between Metrowerks' president and RMS (amusing to
think about), since Kevin B was working for MW at the time.  I think
we're all glad that MW, which might someday come to regard GDB as a
competitor on LinuxPPC, does not have a legal way to interfere with
its development...

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?

   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).

It's never going to be possible for FSF GDB to have the latest version
of every code bit that is under development.  If nothing else, most of
the Linux folks take a rather cavalier attitude towards copyright
ownership, and FSF policy does not allow us to do that for GDB.
(complaints to rms@gnu.org)  However, we should always be trying to
stay as current as possible.


								Stan

Re: x86 FPU support: "info float" and `long double'

[H.J. Lu]

> 
> > My current gdb has
> > 
> > (gdb) info float
> >      st0: 0x3ffed6d6d6d6d6d6d800  Empty Normal 0.8392156862745098200307
> >      st1: 0x00000000000000000000  Empty Zero   0
> 
> "st0", "st1" etc. implies stack-relative order of the registers.
> IMHO, this is wrong: it doesn't present the registers as a stack, and
> with each push/pop operation, the entire picture moves up/down, which
> is very confusing.  If this format is adopted (I hope not), it won't
> make sense to print the TOS pointer (that arrow => shown by Mark in
> his example), since the TOS is always st0.
> 
> In the physical order, like what go32-nat.c does, the registers cannot
> be designated st0, st1, etc., because that's not true.  If 0, 1,
> etc. is somehow not good enough, we should use R0, R1, etc., like
> Intel does.
> 

That is a good point. I am used to check

fstat:     0x0000 flags 0000; top 0;

for where the real st0 is.


-- 
H.J. Lu (hjl@gnu.org)
From kevinb@cygnus.com Thu Oct 21 11:19:00 1999
From: Kevin Buettner <kevinb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>, khendricks@admin.ivey.uwo.ca
Cc: hjl@lucon.org, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 11:19:00 -0000
Message-id: <991021181855.ZM3563@ocotillo.lan>
References: <199910211743.KAA08509@andros.cygnus.com> <shebs@cygnus.com>
X-SW-Source: 1999-q4/msg00102.html
Content-length: 2848

On Oct 21, 10:43am, Stan Shebs wrote:

>    Date: Thu, 21 Oct 1999 10:11:22 -0400 (EDT)
>    From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>
> 
>    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.
> 
> Actually, all that did happen a while back - it ended up requiring
> some negotiation between Metrowerks' president and RMS (amusing to
> think about), since Kevin B was working for MW at the time.  I think
> we're all glad that MW, which might someday come to regard GDB as a
> competitor on LinuxPPC, does not have a legal way to interfere with
> its development...
> 
> 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?

I got my patches working with the head of the development tree several
weeks ago.  (Actually, Gary Thomas deserves a lot of the credit.)
However there are a great many similarities between rs6000-tdep.c and
the ppclinux-tdep.c.  I would really like to make the common parts
truly common as well as revamp it so that it uses the gdbarch
machinery, but this'll take more time than I have at the moment.  So
it might be better for me to commit what I have so that linux/ppc is
supported in the Cygnus tree.  Also, the longer I let my stuff sit,
the more likely it is that certain global changes will break what I
have working already.  (Because these global changes won't have
happened to the linux/ppc stuff.)

>    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).

I'll take this opportunity to agree with Kevin Hendricks regarding
HJ's Linux tools.  Even on Linux/x86 where there was some existing gdb
support in the FSF tree, HJ's splinter version of gdb made it possible
to debug multi-threaded programs on Linux.  When I was developing
Linux applications at Metrowerks, we appreciated this greatly and
would probably not have been able to complete our product in a timely
fashion without his splinter version.

Kevin
From khendricks@admin.ivey.uwo.ca Thu Oct 21 11:21:00 1999
From: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>
To: khendricks@admin.ivey.uwo.ca, shebs@cygnus.com
Cc: hjl@lucon.org, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: x86 fpu
Date: Thu, 21 Oct 1999 11:21:00 -0000
Message-id: <11999.940530080.0@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 1999-q4/msg00103.html
Content-length: 1177

Hi,

>It's never going to be possible for FSF GDB to have the latest version
>of every code bit that is under development. 

It is just that your "code bit" is our complete world. Gdb is the *only* 
debugger that exists for Linux PPC.  We have nothing else to fall back on.   

>If nothing else, most of
>the Linux folks take a rather cavalier attitude towards copyright
>ownership, and FSF policy does not allow us to do that for GDB.
>(complaints to rms@gnu.org)  

Yes, that is very true. I could not understand why it took so much just to get 
ppc support in  (I didn't know RMS and MW president had to get involved.) 

>However, we should always be trying to
>stay as current as possible.

Sounds good to me.  After how quickly Kevin Buettner got JDK 1.1.X working under 
Linux PPC (when only working part time on the porting team), I am sure he will 
have us (LinuxPPC) in good shape with gdb in no time at all! 

Thanks,

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

Difference between *_filtered and *_unfiltered

[Mark Kettenis]

   Date: Fri, 22 Oct 1999 10:06:02 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Totally off topic.

So I removed a few people from CC:

   The existing i387-tdep.c has:

   >                 puts_unfiltered (...);

   It should be using ``..._filtered''.  Good time to tweek that as well
   :-)

Could you explain what the difference between the _filtered and
_unfiltered variants is, and under what circumstances one uses the one
or the other?  I couldn't find this information in the documentation.

Thanks,

Mark

Re: Difference between *_filtered and *_unfiltered

[Andrew Cagney]

Mark Kettenis wrote:
> 
>    Date: Fri, 22 Oct 1999 10:06:02 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    Totally off topic.
> 
> So I removed a few people from CC:
[Er, yes. Oops, Thanks :-)]

> 
>    The existing i387-tdep.c has:
> 
>    >                 puts_unfiltered (...);
> 
>    It should be using ``..._filtered''.  Good time to tweek that as well
>    :-)
> 
> Could you explain what the difference between the _filtered and
> _unfiltered variants is, and under what circumstances one uses the one
> or the other?  I couldn't find this information in the documentation.

Good question.  Filtered output goes through a builtin pager (that q for
quit or return for more prompt seen when printing a backtrace). 
Unfiltered output goes straight to the screen.

As a rule?

All normal output from GDB (display registers, backtrace) should be
filtered. A user on an 80x24 terminal doesn't want that register info
disappearing off the top of the screen.  A user with a large xterminal
can use ``(gdb) set height 0''.

Output from the target and debug/trace messages generated by gdb's
internals should not be filtered.  Having gdb prompt for a continue
every 24 lines as a result of a ``(gdb) set targetdebug 1'' command will
drive the user batty, such output can be captured using other mechanisms
such as ``script''.

Longer term, the problem will go away.  The ..._filtered() and
..._unfiltered() are going to be eliminated.  GDB will direct each
output to the applicable stream (gdb_stdout, gdb_stdlog, ...) and that
stream can then be configured to impose its own paging policy.

	enjoy,
		Andrew
From eliz@gnu.org Fri Oct 22 05:00:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com
Subject: Re: Hardware watchpoints
Date: Fri, 22 Oct 1999 05:00:00 -0000
Message-id: <199910221200.IAA24556@mescaline.gnu.org>
References: <np3dv6k64w.fsf@zwingli.cygnus.com> <19991019235249.917DC1B494@ocean.lucon.org> <199910201401.KAA28719@mescaline.gnu.org> <npvh82htxn.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00128.html
Content-length: 1411

> > > Evaluating the expression foo.x, I think, produces two values: one for
> > > 'foo', which is lazy, and a second for the '.x' member of the first
> > > value, which is no longer lazy.
> > 
> > The question is: what happens for foo->x.  Since foo can changein this
> > case, GDB has to watch both foo and foo->x.  But it does NOT have to
> > watch *foo.
> 
> Evaluating foo->x, I believe the values on the chain would be foo (not
> lazy), and foo->x (not lazy).  So that would work correctly.
> 
> Even evaluating (*foo).x, I believe you'd get foo (not lazy), *foo
> (lazy), and (*foo).x (not lazy).  So that would work too.
> 
> 
> >Could you suggest a quick hack to test whether this works?  If so, I
> >could try to see if that solvces the problem (and whether it introduces
> >new ones ;-).
> 
> Here's an untested patch:

Unfortunately, this doesn't work.  The effect of this change is that
hardware watchpoints aren't inserted at all.

I've poked around a little, and it seems that the lazy flag is set on
all members of the struct, not only on the struct itself.  It could be
that the reason is because value_primitive_field says something like
this (in more than one place):

      if (VALUE_LAZY (arg1))
	VALUE_LAZY (v) = 1;

I admit that I don't have enough insight into how the lazy flag is
used in GDB to suggest a solution.  But if you have further ideas for
testing, I will try them.

Thanks.
From Grant.Edwards@comtrol.com Fri Oct 22 06:52:00 1999
From: Grant.Edwards@comtrol.com
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Scott Bambrough <scottb@netwinder.org>, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Fri, 22 Oct 1999 06:52:00 -0000
Message-id: <19991022085150.A26689@comtrol.com>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com>
X-SW-Source: 1999-q4/msg00129.html
Content-length: 686

On Fri, Oct 22, 1999 at 10:34:04AM +1000, Andrew Cagney wrote:


> I think everyone has agreed that that isn't the problem that is occuring
> here.

I'm pretty sure that <netinet/in.h> is getting confused by one
of the include files in the rdi-remote directory, since that
directory is searched first for include files before
/usr/include.

> 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.

-- 
Grant Edwards
Grant.Edwards@comtrol.com
From muller@cerbere.u-strasbg.fr Fri Oct 22 07:24:00 1999
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: gdb@sourceware.cygnus.com
Subject: Pascal extensions for GDB
Date: Fri, 22 Oct 1999 07:24:00 -0000
Message-id: <199910221437.QAA09979@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00130.html
Content-length: 1505

  I would like to submit a big patch for GDB adding
support for pascal language !

  I am one of the codeveloppers of Free Pascal 
(a non GNU freeware pascal compiler)
for the need of our compiler we (Peter Vreman and myself)
wrote pascal extensions to GDB.
  Our current patch applies quite easily to
official GDB 4.18 for djgpp cygwin and i386 linux
(I never tried another CPU as at the moment only the i386 part of Free
Pascal is 
being developed intensively and
as I have no other CPU available anyway,
but the patch has almost nothing processor specific !)


  Brief description of added features :
Features include :
- pascal expression parser (maybe incomplete)
- case unsensitive regexp patches
- language automatic for .p .pp .pas and .inc extensions
- support for pascal sets
- pascal string (FPC specific, with also printout of values of pointers to
pascal strings
as for C *char)
 
  I sent quite a long time ago a preliminary version of this patch to GPC
maintainers but got no 
feedback, if some GPC developpers are in that list I would like to hear
from them !

  This patch is approx 750k long 
so I do not send it directly now !

  Please give me some advices about what I should do !

  PS :
   FPC supports long double in 10 bytes instead of 12 like in C !
Is that supported with your current FPU patches ??



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From scottb@netwinder.org Fri Oct 22 07:49:00 1999
From: Scott Bambrough <scottb@netwinder.org>
To: Grant.Edwards@comtrol.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Fri, 22 Oct 1999 07:49:00 -0000
Message-id: <3810789A.EE0C01AC@netwinder.org>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com> <19991022085150.A26689@comtrol.com>
X-SW-Source: 1999-q4/msg00131.html
Content-length: 1021

Grant.Edwards@comtrol.com wrote:

> I'm pretty sure that <netinet/in.h> is getting confused by one
> of the include files in the rdi-remote directory, since that
> directory is searched first for include files before
> /usr/include.

My ARM and i386 systems are GLIBC2 based (RedHat 6.x).

On my system htons(x) resolves to:

  (x) 		if __OPTIMIZE__ and __BYTE_ORDER = __BIG_ENDIAN
  __bswap_16(x)	if __OPTIMIZE__ and __BYTE_ORDER = __LITTLE_ENDIAN

On my system __BYTE_ORDER is set in <bits/endian.h>

on ARM:
__BYTE_ORDER == __BIG_ENDIAN if __ARMEB__ is defined
__BYTE_ORDER == __LITTLE_ENDIAN otherwise

on i386:
__BYTE_ORDER == __LITTLE_ENDIAN always

In the preprocessed output of etherdrv.c with optimization on is
htons(x) reduced to (x) or a call to __bswap_16(x)?  The answer to this
should tell you if __BYTE_ORDER == __BIG_ENDIAN or __LITTLE_ENDIAN.

After that you will need to find out why either __BIG_ENDIAN is defined
or __bswap_16(x) fails.  Of course this assumes you have a GLIBC2 based
system.

Scott
From grante@visi.com Fri Oct 22 07:55:00 1999
From: Grant Edwards <grante@visi.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: Grant.Edwards@comtrol.com, gdb@sourceware.cygnus.com
Subject: Re: wrong htons() used?
Date: Fri, 22 Oct 1999 07:55:00 -0000
Message-id: <19991022095507.A4048@visi.com>
References: <19991021151610.A3919@comtrol.com> <380F80F1.394F7493@netwinder.org> <19991021162144.A15266@comtrol.com> <380FB0FC.A5CE946F@cygnus.com> <19991022085150.A26689@comtrol.com> <3810789A.EE0C01AC@netwinder.org>
X-SW-Source: 1999-q4/msg00132.html
Content-length: 1323

On Fri, Oct 22, 1999 at 10:45:46AM -0400, Scott Bambrough wrote:
> 
> > I'm pretty sure that <netinet/in.h> is getting confused by one
> > of the include files in the rdi-remote directory, since that
> > directory is searched first for include files before
> > /usr/include.
> 
> My ARM and i386 systems are GLIBC2 based (RedHat 6.x).
>
> On my system htons(x) resolves to:
> 
>   (x) 		if __OPTIMIZE__ and __BYTE_ORDER = __BIG_ENDIAN
>   __bswap_16(x)	if __OPTIMIZE__ and __BYTE_ORDER = __LITTLE_ENDIAN
> 
> On my system __BYTE_ORDER is set in <bits/endian.h>
> 
> on ARM:
> __BYTE_ORDER == __BIG_ENDIAN if __ARMEB__ is defined
> __BYTE_ORDER == __LITTLE_ENDIAN otherwise
> 
> on i386:
> __BYTE_ORDER == __LITTLE_ENDIAN always
> 
> In the preprocessed output of etherdrv.c with optimization on is
> htons(x) reduced to (x) or a call to __bswap_16(x)?  

htons(x) with optimization on  reduces to (x)
htons(x) with optimization off reduces to htons(x)

> The answer to this should tell you if __BYTE_ORDER == __BIG_ENDIAN
> or __LITTLE_ENDIAN.

Apparently it is __BIG_ENDIAN.  Which is wrong, since it's a 386.

> After that you will need to find out why either __BIG_ENDIAN is defined
> or __bswap_16(x) fails.  Of course this assumes you have a GLIBC2 based
> system.

I do.  (RH6.0)

--
Grant Edwards
grante@visi.com

Re: x86 FPU support: "info float" and `long double'

[J.T. Conklin]

>>>>> "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