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