Re: Difference between *_filtered and *_unfiltered

[Andrew Cagney <ac131313@cygnus.com>]

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