Re: RDI target broken in 000215 snapshot

[Fernando Nasser <fnasser@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 49606 bytes --]

Grant Edwards wrote:
> 
> Another interesting bit of info.  The new snapshot is apparently not
> detecting the endianness of the target (both the sessions below were
> with a Samsung SNDS evel board (big-endian):
> 

I guess you got it.

Can you set the endianess and do the load after that?

Please let me know if it worked.

In the meanwhile I will check for differences (my build is still going on :-)

Thanks,
Fernando





> $ arm-elf-gdb
> GNU gdb 4.18
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently big endian)
> 
> 
> $ ~/gdb-000222/gdb/gdb
> GNU gdb 000222
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently little endian)
> 
> --
> Grant

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From grante@visi.com Thu Feb 24 12:16:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 12:16:00 -0000
Message-id: <20000224141648.A1896@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B58DAE.9CAA0A59@cygnus.com>
X-SW-Source: 2000-02/msg00011.html
Content-length: 385

>
> > Another interesting bit of info.  The new snapshot is apparently not
> > detecting the endianness of the target (both the sessions below were
> > with a Samsung SNDS evel board (big-endian):
>
> 
> I guess you got it.
> 
> Can you set the endianess and do the load after that?

Yes.  If I set endian to big, then code gets downloaded properly.

-- 
Grant Edwards
grante@visi.com
From fnasser@cygnus.com Thu Feb 24 13:06:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:06:00 -0000
Message-id: <38B59CE1.4CFA7F1E@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com>
X-SW-Source: 2000-02/msg00012.html
Content-length: 2553

> >
> > > Another interesting bit of info.  The new snapshot is apparently not
> > > detecting the endianness of the target (both the sessions below were
> > > with a Samsung SNDS evel board (big-endian):
> >
> > 
> > I guess you got it.
> > 
> > Can you set the endianess and do the load after that?
>
> Yes.  If I set endian to big, then code gets downloaded properly.
>
> -- 
> Grant Edwards
> grante@visi.com

At least you have a way to work now.  Just add a .gdbinit with the set endian command on your project directory (the one
you want to be big endian).

We can now, with less pressure, discuss what is going on.

The default for arm targets is "selectable" and "little endian".
This is introduced in december by Stan, who checked in a patch from Scott.
The ChangeLog fails to mention this change!!!  But cvs diff never lies... ;-)

I believe the ideal scenario would be to have this thing set in a "smart" way.
The current RDI code just ignores the endianess indication returned by the target.
Maybe we could use that to set the endianess (only if "auto" is selected, please) of the target.
I don't know if this will work, but I can try when I get back.

Of course, you can try that yourself and submit a patch :-)
The interesting line is in remote-rdi.c:279

Cheers,
Fernando


Grant Edwards wrote:
> 
> Another interesting bit of info.  The new snapshot is apparently not
> detecting the endianness of the target (both the sessions below were
> with a Samsung SNDS evel board (big-endian):
> 
> $ arm-elf-gdb
> GNU gdb 4.18
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently big endian)
> 
> 
> $ ~/gdb-000222/gdb/gdb
> GNU gdb 000222
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently little endian)
> 
> --
> Grant

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From grante@visi.com Thu Feb 24 13:27:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:27:00 -0000
Message-id: <20000224152638.A2092@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com>
X-SW-Source: 2000-02/msg00013.html
Content-length: 1248

On Thu, Feb 24, 2000 at 04:04:33PM -0500, Fernando Nasser wrote:

> > > > Another interesting bit of info.  The new snapshot is apparently not
> > > > detecting the endianness of the target (both the sessions below were
> > > > with a Samsung SNDS evel board (big-endian):
> > > 
> > > I guess you got it.
> 
> The default for arm targets is "selectable" and "little endian".
> This is introduced in december by Stan, who checked in a patch from Scott.
> The ChangeLog fails to mention this change!!!  But cvs diff never lies... ;-)

Nope.

> I believe the ideal scenario would be to have this thing set in
> a "smart" way. The current RDI code just ignores the endianess
> indication returned by the target. Maybe we could use that to
> set the endianess (only if "auto" is selected, please) of the
> target. I don't know if this will work, but I can try when I
> get back.

I had assumed that gdb was detecting the endianness of the
target already (before today, I didn't know it was user
selectable).  I'll take a look at make the "auto" mode pay
attention to the target hardware indication.  One could then
generate a warning if the endiannes of the target and the
endianness of a file being loaded disagree.

-- 
Grant Edwards
grante@visi.com
From fnasser@cygnus.com Thu Feb 24 13:44:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 13:44:00 -0000
Message-id: <38B5A5D1.B2C0EB96@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00014.html
Content-length: 786

Grant Edwards wrote:
> 
> I had assumed that gdb was detecting the endianness of the
> target already (before today, I didn't know it was user
> selectable).  I'll take a look at make the "auto" mode pay
> attention to the target hardware indication.  One could then
> generate a warning if the endiannes of the target and the
> endianness of a file being loaded disagree.
> 
Good idea.  If the endianess is set to auto, then you set it appropriately.
If not, and it differs from the target, a warning is in order.
You got no indication at all that something was wrong.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From grante@visi.com Thu Feb 24 14:18:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 14:18:00 -0000
Message-id: <20000224161811.A2505@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00015.html
Content-length: 617

On Thu, Feb 24, 2000 at 03:26:38PM -0600, Grant Edwards wrote:

> I had assumed that gdb was detecting the endianness of the
> target already (before today, I didn't know it was user
> selectable).  I'll take a look at makeing the "auto" mode pay
> attention to the target hardware indication.

Does the Angel monitor report the current hardware status
correctly?  The EPI Jeeni correctly reports my target is
big-endian, but the ARM EmbeddedICE reports that it is little.

Unless most targets correctly report correct endian status,
it's probably not worth paying attention to it.

-- 
Grant Edwards
grante@visi.com
From bgat@usa.net Thu Feb 24 14:44:00 2000
From: William A.Gatliff <bgat@usa.net>
To: gdb@sourceware.cygnus.com
Subject: gdb configure core dumps
Date: Thu, 24 Feb 2000 14:44:00 -0000
Message-id: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net>
X-SW-Source: 2000-02/msg00016.html
Content-length: 474

Guys:

I'm trying to configure gdb-4.18 on a fresh install of RH6.1, and it isn't
working.

It seems as though no matter what I supply for arguments to configure
(including no arguments at all), I always get back the same thing as if I had
typed --help, and a core file appears in the directory.

Any ideas?  I'm stumped...

b.g.


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
From echristo@cygnus.com Thu Feb 24 15:24:00 2000
From: Eric Christopher <echristo@cygnus.com>
To: "William A.Gatliff" <bgat@usa.net>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb configure core dumps
Date: Thu, 24 Feb 2000 15:24:00 -0000
Message-id: <38B5BDDF.6E73AEF4@cygnus.com>
References: <20000224224408.2947.qmail@nwcst283.netaddress.usa.net>
X-SW-Source: 2000-02/msg00017.html
Content-length: 286

> It seems as though no matter what I supply for arguments to configure
> (including no arguments at all), I always get back the same thing as if I had
> typed --help, and a core file appears in the directory.
> 

What does 'file core' say?  Perhaps there is some issue with sh?

-eric
From hanymorcos@yahoo.com Thu Feb 24 15:27:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: gdb@sourceware.cygnus.com
Subject: Debugging a constructor
Date: Thu, 24 Feb 2000 15:27:00 -0000
Message-id: <20000224232705.13750.qmail@web3207.mail.yahoo.com>
X-SW-Source: 2000-02/msg00018.html
Content-length: 431

How do I print the variable values inside
a constructor?

I can't use this... Because doesn't exist yet..
The object hasn't been constructed...

Then how do I print the value of x??

class y{

    public: 
      y(int* x) {x =
coreDumpAndGenerateManyHeadaches(); // print x inside
gdb } ;
};


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From hanymorcos@yahoo.com Thu Feb 24 16:31:00 2000
From: Hany Morcos <hanymorcos@yahoo.com>
To: Hany Morcos <hanymorcos@yahoo.com>, gdb@sourceware.cygnus.com
Subject: Re: Debugging a constructor
Date: Thu, 24 Feb 2000 16:31:00 -0000
Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com>
X-SW-Source: 2000-02/msg00019.html
Content-length: 686

Got it 
thank you

--- Hany Morcos <hanymorcos@yahoo.com> wrote:
> 
> 
> How do I print the variable values inside
> a constructor?
> 
> I can't use this... Because doesn't exist yet..
> The object hasn't been constructed...
> 
> Then how do I print the value of x??
> 
> class y{
> 
>     public: 
>       y(int* x) {x =
> coreDumpAndGenerateManyHeadaches(); // print x
> inside
> gdb } ;
> };
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
> 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
From ac131313@cygnus.com Thu Feb 24 18:55:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 18:55:00 -0000
Message-id: <38B5EEDB.8A8F2DD8@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00020.html
Content-length: 2275

FYI,

The current behavior is determined by gdbarch.c:

	o	it starts in auto mode using
		TARGET_BYTE_ORDER_DEFAULT as an
		initial value or (chosen arbitrarily)
		BIG_ENDIAN as the next best guess.

	o	as soon as GDB encounters a binary
		it pokes around the bfd file to determine
		the endianess and uses that (provided things
		are still auto).

To the best of my knowledge, no one has seriously investigated how to
set up an interface where the target determines architectural
information (such as endianess).

As for the current problem:

$ arm-elf-gdb
GNU gdb 4.18
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr  1 1998 at 00:43:57
Serial Rate:   9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently big endian)
                
$ ~/gdb-000222/gdb/gdb
GNU gdb 000222
[...]
This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
(gdb) target rdi /dev/ttyS1
EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT
2.11a)
Rebuilt on Apr  1 1998 at 00:43:57
Serial Rate:   9600
Connected to ARM RDI target.
(gdb) show endian
The target endianness is set automatically (currently little endian)

it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
wrong place.

	enjoy,
		Andrew



Fernando Nasser wrote:
> 
> Grant Edwards wrote:
> >
> > I had assumed that gdb was detecting the endianness of the
> > target already (before today, I didn't know it was user
> > selectable).  I'll take a look at make the "auto" mode pay
> > attention to the target hardware indication.  One could then
> > generate a warning if the endiannes of the target and the
> > endianness of a file being loaded disagree.
> >
> Good idea.  If the endianess is set to auto, then you set it appropriately.
> If not, and it differs from the target, a warning is in order.
> You got no indication at all that something was wrong.
> 
> --
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
> 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
> Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ac131313@cygnus.com Thu Feb 24 19:35:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: kevinb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Patches for GNU/Linux PPC native now in CVS
Date: Thu, 24 Feb 2000 19:35:00 -0000
Message-id: <38B5F82F.D4C46B90@cygnus.com>
References: <1000222025201.ZM9805@ocotillo.lan> <200002221013.e1MAD3A00261@delius.kettenis.local> <1000224102541.ZM14031@ocotillo.lan> <200002241047.LAA02405@landau.wins.uva.nl>
X-SW-Source: 2000-02/msg00021.html
Content-length: 1318

Mark Kettenis wrote:
> 
>    Date: Thu, 24 Feb 2000 03:25:41 -0700
>    From: Kevin Buettner <kevinb@cygnus.com>
> 
>    On Feb 22, 11:13am, Mark Kettenis wrote:
> 
>    [Detailed failure analysis snipped]
> 
>    > Anyway, I hope this helps,
> 
>    It did indeed.  Thanks!  (It showed me where not to focus my attention
>    first.)
> 
>    I'll respond to the sourceware list when I've had more time to study
>    your analysis, but in the meantime, I wanted to send you a note to let
>    you know that I appreciated your analysis...
> 
> Meanwhile, I learned something more about the
> 
> gdb.base/annota1.exp: backtrace @ signal handler
> 
> failure I reported.  There is nothing wrong with the test per se.
> It's just that on my i586-pc-linux-gnu system the regexp matching
> takes an awful lot of time.  Setting the timeout to 10 minutes made
> the test pass.  This is probably related to the fact that with glibc
> there is an extra frame.  Apparently the fix I suggested (but didn't
> understand), speeded up the regexp matching somewhat, but even in that
> case (with the default timeout) the test failed on my system last
> night.

Have a look at gdb.base/call-ar-st.exp and how it used
``gdb_expect_list''.  Patches that make the testsuite run 10 minutes
faster are always more than welcome :-)

	Andrew
From grante@visi.com Thu Feb 24 19:57:00 2000
From: Grant Edwards <grante@visi.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 19:57:00 -0000
Message-id: <20000224215652.A7650@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B5EEDB.8A8F2DD8@cygnus.com>
X-SW-Source: 2000-02/msg00022.html
Content-length: 801

> 	o	as soon as GDB encounters a binary
> 		it pokes around the bfd file to determine
> 		the endianess and uses that (provided things
> 		are still auto).

That implies that when I loaded a big-endian file it should have
switched to big-endian.  It didn't seem to -- I'll have to try that
again.

> To the best of my knowledge, no one has seriously investigated how to
> set up an interface where the target determines architectural
> information (such as endianess).

Since 50% of my sample of 2 target interfaces don't correctly report
endianess, it may not be something worth investigating.

> it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
> wrong place.

Now that I know what happened, it's not a big deal.  I can just set it
in .gdbinit.

-- 
Grant Edwards
grante@visi.com
From ac131313@cygnus.com Thu Feb 24 22:11:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Thu, 24 Feb 2000 22:11:00 -0000
Message-id: <38B61CF6.B4F80802@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com>
X-SW-Source: 2000-02/msg00023.html
Content-length: 1084

Grant Edwards wrote:
> 
> >       o       as soon as GDB encounters a binary
> >               it pokes around the bfd file to determine
> >               the endianess and uses that (provided things
> >               are still auto).
> 
> That implies that when I loaded a big-endian file it should have
> switched to big-endian.  It didn't seem to -- I'll have to try that
> again.

Possibly not.  If you were using:

	(gdb) load file-with-random-format

then GDB won't look at the file.  I should have said that something like
gdb sets the endianess once the debug file is specified (via ``file'' or
a few other commands) vis:

	(gdb) file debug-file
	(gdb) load

``load'' tends to not have side effects (and when it does, they are
hotly debated :-)

> > it looks like TARGET_BYTE_ORDER_DEFAULT was changed or added in the
> > wrong place.
> 
> Now that I know what happened, it's not a big deal.  I can just set it
> in .gdbinit.

It's more a question of should the endianess have changed between
releases or should it have been little-endian anyway.  Not my problem
:-)

	Andrew
From fnasser@redhat.com Fri Feb 25 07:08:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Grant Edwards <grante@visi.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:08:00 -0000
Message-id: <38B69A2A.ED2DC6F3@redhat.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com>
X-SW-Source: 2000-02/msg00024.html
Content-length: 962

Andrew Cagney wrote:
> 
> It's more a question of should the endianess have changed between
> releases or should it have been little-endian anyway.  Not my problem
> :-)
> 

I inherited this one :-)

But you are right, this will at least require an entry in the NEWS, as
it alters some previous behavior.  *If* the arm users in the list decide
that the default should be little-endian.  It does seem reasonable and
if the file command straights it out, only the load users would have to
care (but they are more aware of these issues, and can always have the
set endian on their .gdbinit).

It is a shame that Angel is so buggy.  The return code should
appropriately indicate the endianess of the target  --  it would be a
nice feature to use :-(

-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From grante@visi.com Fri Feb 25 07:14:00 2000
From: Grant Edwards <grante@visi.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:14:00 -0000
Message-id: <20000225091418.B3106@visi.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com>
X-SW-Source: 2000-02/msg00025.html
Content-length: 1379

On Fri, Feb 25, 2000 at 03:05:14PM +0000, Fernando Nasser wrote:

> > It's more a question of should the endianess have changed between
> > releases or should it have been little-endian anyway.  Not my problem
> > :-)
> 
> I inherited this one :-)
> 
> But you are right, this will at least require an entry in the
> NEWS, as it alters some previous behavior.  *If* the arm users
> in the list decide that the default should be little-endian.

From what I've seen/read little-endian is more common (does
ARM-Linux run little-endian or big?), and it's the default for
gcc/binutils, so it should probably be the default for gdb as
well.  I was just confused because I thought "auto" meant that it
would be determined by the target.

> It does seem reasonable and if the file command straights it
> out, only the load users would have to care (but they are more
> aware of these issues, and can always have the set endian on
> their .gdbinit).

Having the load command warn the user if the target and file
differ might also be something to consider.

> It is a shame that Angel is so buggy.  The return code should
> appropriately indicate the endianess of the target -- it would
> be a nice feature to use :-(

Does Angel not report it correctly?  The ARM EmbeddedICE is
broken in that respect, but I don't have a copy of Angel
running anywhere.

-- 
Grant Edwards
grante@visi.com
From fnasser@redhat.com Fri Feb 25 07:29:00 2000
From: Fernando Nasser <fnasser@redhat.com>
To: Grant Edwards <grante@visi.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Fernando Nasser <fnasser@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Fri, 25 Feb 2000 07:29:00 -0000
Message-id: <38B69F56.5ECE30F6@redhat.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> <38B69A2A.ED2DC6F3@redhat.com> <20000225091418.B3106@visi.com>
X-SW-Source: 2000-02/msg00026.html
Content-length: 1689

Grant Edwards wrote:
> 
> Having the load command warn the user if the target and file
> differ might also be something to consider.
> 
The trick is how to know the target endianess.  Also, note that the file
being loaded by the load command ay not have this info.  The file
command is the one that reads files from where this can be determined.

> Does Angel not report it correctly?  The ARM EmbeddedICE is
> broken in that respect, but I don't have a copy of Angel
> running anywhere.
> 
My mistake. I thought you made reference to an Angel board on you 50/50
little statistic.

I have two little-endian boards running two different versions of
Angel.  I will check wen I get back.

But I guess you are right, we should assume that the target RDI protocol
is working properly and check for the endianess.  For the boards/devices
that are broken, the user will have to turn off the auto mode and set
the endianess appropriately on his/her .gdbinit.  Another possibility is
that we just issue a warning (instead of setting the endianess) based on
the result returned from the board.  If it is a board/device with a know
problem of returning the wrong info, the user will just ignore the
warning.  To make GUI users happier, he warning would not be issued if
auto is turned off (what means that the user set deliberately the
endianess so he/she should know what he/she is doing).

BTW: AFAIK Linux-arm is little endian, and that is why Stan and Scott
changed the default.


-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From scottb@netwinder.org Fri Feb 25 10:11:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: "fnasser@cygnus.com" <fnasser@cygnus.com>
Cc: James Ingham <jingham@cygnus.com>, GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: bug in arm_push_arguments() 
Date: Fri, 25 Feb 2000 10:11:00 -0000
Message-id: <38B6C4A1.7A1461C4@netwinder.org>
X-SW-Source: 2000-02/msg00027.html
Content-length: 4031

Hi guys,

I've been looking at this function as there are regressions in
gdb.base/callfuncs.  In particular I've been looking at this code.


     /* ANSI C code passes float arguments as integers, K&R code
         passes float arguments as doubles.  The .stabs record for 
         for ANSI prototype floating point arguments records the
         type as FP_INTEGER, while a K&R style (no prototype)
         .stabs records the type as FP_FLOAT.  In this latter case
         the compiler converts the float arguments to double before
         calling the function.  */
      if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len)
        {
          float f;
          double d;
          char * bufo = (char *) &d;
          char * bufd = (char *) &dbl_arg;

          len = sizeof (double);
          f = *(float *) val;
          SWAP_TARGET_AND_HOST (&f, sizeof (float));  /* adjust endianess */
          d = f;
          /* We must revert the longwords so they get loaded into the
             the right registers. */
          memcpy (bufd, bufo + len / 2, len / 2);
          SWAP_TARGET_AND_HOST (bufd, len / 2);  /* adjust endianess */
          memcpy (bufd + len / 2, bufo, len / 2);
          SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
          val = (char *) &dbl_arg;
        }

I added this particular piece of code to handle functions without prototypes
that pass floats as parameters, because the compiler treats them differently. 
Someone added code which is attempting the following (see my comments):

	  /* The value is in TARGET byte order.  Convert it to HOST byte 
	     order in preparation for conversion to a double.  */
          f = *(float *) val;
          SWAP_TARGET_AND_HOST (&f, sizeof (float));  /* adjust endianess */

	  /* Convert the float to a double in HOST byte order.  */
          d = f;

	  /* Convert the double to TARGET byte order and swap things to 
	     conform to the ARM floating point layout.  */
          memcpy (bufd, bufo + len / 2, len / 2);
          SWAP_TARGET_AND_HOST (bufd, len / 2);  /* adjust endianess */
          memcpy (bufd + len / 2, bufo, len / 2);
          SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
          val = (char *) &dbl_arg;

This is ok, but the code for the last step is unnecessarily complex.  I think
something similar to the following should suffice.

	  int tmp, *buf = &d;
	  SWAP_TARGET_AND_HOST (&d, sizeof (double));
	  tmp = buf[0];
	  buf[0] = buf[1];
	  buf[1] = tmp;

I think this will result in better code from the compiler.  There are a couple
of problems though with this code.  First what happens if sizeof (TARGET_DOUBLE)
!= sizeof (HOST_DOUBLE).  Second, this breaks in the native case, because the
double is already in the right format. This is why I have regressions I believe
(I have yet to test my theory).  Is there a clean way to solve these problems?

I also noticed this comment while investigating.  I disabled the code when I
rewrote the function.  I didn't know what it was for, and I wasn't sure it
should stay.  I left it for Stan and Jim to evaluate.  If it is necessary I
would document what it does and why it does it, and get rid of question.  In
particular why is setting the mode bit fine?  
#if 1
      /* I don't know why this code was disable. The only logical use
         for a function pointer is to call that function, so setting
         the mode bit is perfectly fine. FN */
      /* If the argument is a pointer to a function, and it is a Thumb
         function, set the low bit of the pointer.  */
      if (TYPE_CODE_PTR == typecode
          && NULL != target_type
          && TYPE_CODE_FUNC == TYPE_CODE (target_type))
        {
          CORE_ADDR regval = extract_address (val, len);
          if (arm_pc_is_thumb (regval))
            store_address (val, len, MAKE_THUMB_ADDR (regval));
        }
#endif

Scott
 
-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From jimb@cygnus.com Fri Feb 25 10:27:00 2000
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: patch database proposal
Date: Fri, 25 Feb 2000 10:27:00 -0000
Message-id: <200002251827.NAA09955@zwingli.cygnus.com>
X-SW-Source: 2000-02/msg00028.html
Content-length: 8847

Here's a tentative proposal for how the patch database should work.
In reality, a good part of this is set up and ready to go, but there's
nothing we can't revise, in the presence of good ideas or persuasive
criticism.

Please let me know what you think; post your comments to the list.

----

If you've written a patch for GDB, either to fix a bug or to improve
the program, you should make sure it gets into the GDB patch database.
The GDB patch database is a GNATS database created to help GDB's
maintainers keep track of patches that need reviewing, and helps you
stay on top of what's happening to your patch.

Anyone can submit a patch.  There are two ways to do so:

- Visit the GDB Patch Submission page [Jason will supply URL], and
  submit your patch there.

- Submit your patches via E-mail, by sending a message to
  `gdb-patches-gnats@sourceware.cygnus.com'.  We have a template for
  mail messages [link here].  Following this template helps make sure
  we have the information we need to choose a reviewer for your patch,
  and to do the review itself.

We'd prefer that you use the web form, if possible, because that
provides more helpful prompts, and checks your input more thoroughly.

The database assigns each new patch a number, like `gdb-patch/209'.
Whenever you send mail regarding your patch, be sure to include the
address `gdb-patches-gnats@sourceware.cygnus.com' in the CC list, and
make sure the message subject starts with `gdb-patch/209: ', or
whatever your patch number is.  This way, GNATS will automatically log
the discussion along with the patch in the database.

Once you've submitted your patch, you can visit [another URL] to check
on its status, or to search the patch database in various ways.  Each
patch in the database has a set of headers, much like a mail message;
the two most interesting headers to look at are:

- `Responsible' --- this is the name of the person currently
  responsible for moving the patch forward.

- `State' --- the current status of the patch.

Here are the different states a patch might be in:

- `unclaimed'

  If the database software can't figure out automatically which
  maintainer should evaluate your patch, then it declares the patch
  `unclaimed', and sets the `Responsible' person to the GDB patch
  secretary.  It is then the secretary's job to find someone who can 
  review the patch, and change the patch's `State' and `Responsible'
  headers appropriately.

  Also, if the maintainer responsible for a patch decides that they
  can't process it --- for example, they might know they won't be able
  to evaluate it promptly --- then they can put it back in the
  `unclaimed' state.  As before, the patch secretary should find
  someone else to tend to it.  The patch database logs all changes
  to a patch's state or responsible party, along with all mail
  communication about the patch, which can help the new person pick
  the patch where it left off.

- `claimed'

  The person named in the patch's `Responsible' header has volunteered
  or been designated to review the patch, but they haven't made any
  decision about it yet, or they haven't gotten around to looking at
  it yet.

  The maintainer indicates his or her decision by putting the patch in
  one of the states below.

  If the patch requires additional maintainers' approval, then the
  maintainer should leave the patch in the `claimed' state, and simply
  change the `Responsible' field to the next maintainer in line.
  Since all changes in responsibility are logged with the patch, each
  maintainer can tell when the review process is complete.  The last
  maintainer to evaluate the patch should actually change the state to
  something more conclusive.

  As the name suggests, patch claims are voluntary.  Maintainers
  should feel free to claim interesting unclaimed patches for
  themselves, and to trade or reallocate patches amongst themselves as
  appropriate, simply by changing patches' `State' and `Responsible'
  headers.  Assignments made automatically by the database software,
  or manually by the patch secretary, are simply an optimization,
  meant to help the process run more smoothly.

  Of course, if a maintainer consistently fails to review patches in a
  timely fashion, the team will eventually suggest that they step
  down, or share the responsibility with someone more responsive.

- `feedback'

  This state indicates that the maintainer feels the patch needs
  revision, or that the author's intent is unclear and the patch
  should be further explained.  It is now the responsibility of the
  original author of the patch to satisfy the maintainer's concerns,
  to allow the patch to move forward.

  The maintainer's concerns should always be recorded with the patch
  somehow, either in a mail message logged with the patch, or in the
  state change message.

  Note that the maintainer is still responsible for patches in this
  state.  If the author is slow to respond, the maintainer must pursue
  the matter, or put the patch in the `rejected' state (described
  below) if the author doesn't reply.

- `prereqs'

  The maintainer approves of the patch, but can't apply it until some
  other change is made --- some other patch must be applied first, for
  example.  The maintainer should explain what they are waiting for in
  the patch record.  It is the maintainer's responsibility to notice
  when the prerequisites have been met, and move the patch along.

- `accepted'

  The maintainer has decided to apply the patch, and has accepted
  responsibility for whatever further work is necessary to get it into
  the sources.

- `applied'

  The maintainer has applied the patch, and expects no further work on
  that patch to be necessary.

- `rejected'

  This state represents several possible outcomes:

  - The maintainer has decided that the patch should not be applied, and
    is not expecting to do revisions or further work on that patch.

  - The patch's author has withdrawn it, and the maintainer agrees.

  - The patch is actually several smaller changes lumped together;
    the author must resubmit it as several separate patches.

  - The patch is so old that it is no longer useful in revising the
    current sources, and neither the author nor the maintainer has any
    intention of bringing it up to date.

  In any case, the maintainer should explain why the patch was
  rejected, in the patch notes.
  
  Of course, it is always possible for a maintainer to resurrect a
  rejected patch, simply by putting it back in one of the other
  states.

- `papers'

  The maintainer would like to apply the patch, but the patch is large
  enough that it is automatically copyrighted by the author, and
  cannot be applied to the GDB sources.  In this case, the author
  needs to assign his or her copyright interest in the patch to the
  Free Software Foundation; see [link], or the file `gdb/CONTRIBUTE'
  in the GDB source tree, for details about this.

[We'll work in full documentation for the other headers somewhere, but
this page is mostly about the process, which is the least obvious
part.]


If you're interested in monitoring patch activity, you may wish to
subscribe to `gdb-patches-prs@sourceware.cygnus.com'.  This mailing
list receives:

  - messages announcing newly submitted patches

  - all discussion about existing patches

  - messages indicating that a patch has changed state, and why

To subscribe, [appropriate instructions or link]


If you are having problems using the patch database, send mail to
`gdb-patches-secretary@sourceware.cygnus.com'.  The patch secretary
is responsible for:

  - the quality of the database (removing spam, getting people to use
    the headers in a helpful way, making sure all patches are placed
    in the database [in my experience, every database gets dirty, and
    there needs to be someone working to counteract entropy]);

  - passing `unclaimed' patches to willing and appropriate maintainers;

  - all GDB-specific documentation and web pages supporting the patch
    database; and

  - any other administration specific to the GDB patch database

The patch secretary is not responsible for:

  - technical issues (like evaluating patches);

  - administration of shared sourceware infrastructure, not specific to the
    GDB database (fixing wedged servers, upgrading software, etc.); or

  - prodding unresponsive maintainers.  (General community pressure is
    best for this; beyond that, the prodding needs to be done by
    someone with real authority over their time, like their manager,
    or authority over their maintainership, like the committee that
    made them a maintainer in the first place.)

In the GDB source tree, the file gdb/MAINTAINERS lists the current
patch secretary, along with all the maintainers and the areas they're
responsible for.
From kevinb@cygnus.com Fri Feb 25 11:08:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Re: bug in arm_push_arguments()
Date: Fri, 25 Feb 2000 11:08:00 -0000
Message-id: <1000225190817.ZM16382@ocotillo.lan>
References: <38B6C4A1.7A1461C4@netwinder.org> <scottb@netwinder.org>
X-SW-Source: 2000-02/msg00029.html
Content-length: 3099

On Feb 25,  1:06pm, Scott Bambrough wrote:

>      /* ANSI C code passes float arguments as integers, K&R code
>          passes float arguments as doubles.  The .stabs record for 
>          for ANSI prototype floating point arguments records the
>          type as FP_INTEGER, while a K&R style (no prototype)
>          .stabs records the type as FP_FLOAT.  In this latter case
>          the compiler converts the float arguments to double before
>          calling the function.  */
>       if (TYPE_CODE_FLT == typecode && REGISTER_SIZE == len)
>         {
>           float f;
>           double d;
>           char * bufo = (char *) &d;
>           char * bufd = (char *) &dbl_arg;
> 
>           len = sizeof (double);
>           f = *(float *) val;
>           SWAP_TARGET_AND_HOST (&f, sizeof (float));  /* adjust endianess */
>           d = f;
>           /* We must revert the longwords so they get loaded into the
>              the right registers. */
>           memcpy (bufd, bufo + len / 2, len / 2);
>           SWAP_TARGET_AND_HOST (bufd, len / 2);  /* adjust endianess */
>           memcpy (bufd + len / 2, bufo, len / 2);
>           SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
>           val = (char *) &dbl_arg;
>         }
> 
> I added this particular piece of code to handle functions without prototypes
> that pass floats as parameters, because the compiler treats them differently. 
> Someone added code which is attempting the following (see my comments):
> 
> 	  /* The value is in TARGET byte order.  Convert it to HOST byte 
> 	     order in preparation for conversion to a double.  */
>           f = *(float *) val;
>           SWAP_TARGET_AND_HOST (&f, sizeof (float));  /* adjust endianess */
> 
> 	  /* Convert the float to a double in HOST byte order.  */
>           d = f;
> 
> 	  /* Convert the double to TARGET byte order and swap things to 
> 	     conform to the ARM floating point layout.  */
>           memcpy (bufd, bufo + len / 2, len / 2);
>           SWAP_TARGET_AND_HOST (bufd, len / 2);  /* adjust endianess */
>           memcpy (bufd + len / 2, bufo, len / 2);
>           SWAP_TARGET_AND_HOST (bufd + len / 2, len / 2); /* adjust endianess */
>           val = (char *) &dbl_arg;
> 
> This is ok, but the code for the last step is unnecessarily complex.  I think
> something similar to the following should suffice.
> 
> 	  int tmp, *buf = &d;
> 	  SWAP_TARGET_AND_HOST (&d, sizeof (double));
> 	  tmp = buf[0];
> 	  buf[0] = buf[1];
> 	  buf[1] = tmp;
> 
> I think this will result in better code from the compiler.  There are a couple
> of problems though with this code.  First what happens if sizeof (TARGET_DOUBLE)
> != sizeof (HOST_DOUBLE).  Second, this breaks in the native case, because the
> double is already in the right format. This is why I have regressions I believe
> (I have yet to test my theory).  Is there a clean way to solve these problems?

It seems to me that you should be able to use store_floating() to do
what you want.  It'll handle both the conversion and the byte swapping.

Kevin
From jtc@redback.com Fri Feb 25 17:04:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: command error handling
Date: Fri, 25 Feb 2000 17:04:00 -0000
Message-id: <5mr9e093zj.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-02/msg00030.html
Content-length: 1257

The CLI for the memory region attributes feature I'm working on is
based on displays.  Each memory region created is assigned a number,
and can be enabled, disabled, and deleted.

While stealing the display CLI code, I noticed that when you enable or
disable a non-extant display, a message will be output with printf_-
unfiltered(), but when you do the same thing with delete, GDB calls
error().  The same thing occurs when you attempt to enable/disable/
delete displays with a non-numeric argument.  I'll argue that delete
should behave like enable and disable, that a message be output and
execution should continue.

The problem with error(), IMHO, is that it's very heavy handed.  While
it allows us to avoid the fun of propagating errors up from the lowest
levels of GDB, it also makes it impossible for user defined functions
to detect the failure of a command (that, plus the fact that there are
no command return values, but that's easily remedied by comparision).
Without such a mechanism, the usefulness of scripting is greatly
diminished.  I would expect it to much be the same for all extension
languages that may be bound into GDB.

Is this a (long-term) direction we should be investigating?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kingdon@redhat.com Sat Feb 26 10:30:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: command error handling
Date: Sat, 26 Feb 2000 10:30:00 -0000
Message-id: <b7lfr6cpc.fsf@rtl.cygnus.com>
References: <5mr9e093zj.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-02/msg00031.html
Content-length: 1005

> I'll argue that delete should behave like enable and disable, that a
> message be output and execution should continue.

Sounds good to me.

> The problem with error(), IMHO, is that it's very heavy handed.  While
> it allows us to avoid the fun of propagating errors up from the lowest
> levels of GDB, it also makes it impossible for user defined functions
> to detect the failure of a command

Well, sometimes the command will fail in its entirety.  Or to put it
another way, some errors you can't continue from, for example, in
"delete display foo 4 3 5 2" we might be willing to guess that 4, 3,
5, and 2 are display numbers but in a different case the syntax of the
first part has to be right for the last part to make any sense.  One
can presumably find non-syntactic examples too.

I haven't taken a close look at the error() machinery recently and how
it would relate to scripting languages, but there should be some way
to trap the error() and return it back to the script.
From weech@primenet.com Sat Feb 26 21:33:00 2000
From: Brent Weech <weech@primenet.com>
To: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com
Subject: GDB error 87 under Cygwin
Date: Sat, 26 Feb 2000 21:33:00 -0000
Message-id: <4.3.2.20000226214059.00b8f008@pop.primenet.com>
X-SW-Source: 2000-02/msg00032.html
Content-length: 1728

Where in the world in the Errors.h file that enumerates the error codes
coming from GDB?  In particular, I am interested in error 87, as
shown below:

BLACKBOX> gdb
h-hcube                                                   

GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as "i586-cygwin32"...(no debugging
symbols found)...
(gdb) r
Starting program: //e/h-hcube.exe 
Error creating process //e/h-hcube.exe, (error 87)

I'm sure the answer to this question is somewhere on the Cygnus and/or
GDB mailing archive, but for the life of me I can't figure out how to get
the wonderfully worthless ht://Dig search engine to accept phrase or
boolean searches with any accuracy.  It has got to be one of the
most frustrating search engine software packages I have ever used. 
For example, try the following:


On the Cygwin Project archive, a search for "error 87" set
to match all terms or a boolean search for "error and 87" both
give 5474 matches.
On the same archive, a search for "error" gives (yes, I'm
sure you can guess) the same 5474 matches!
But on the same archive, a search for "error 193" set to
match all terms only gives 21 hits.


What gives?  A search though many of the "error 87"
hits confirms that the string 87 is nowhere in the text or source of the
html page.

Someone tell me how to do a reliable phrase search of the mail
archives.

Brent Weech