Re: non-blocking reads/writes and event loops

Re: non-blocking reads/writes and event loops

[Todd Whitesel]

> However, threads may need to be used in the case where you only have a
> blocking API to control the inferior, but in that case all you are doing is
> using threads to fix this local deficiency, not pushing it into the gdb
> architecture.  I think this is managable.

Agreed. If the API designers are dumb enough to trust threads absolutely,
and don't give us an option, then well, that's life.

-- 
Todd Whitesel
toddpw @ windriver.com
From jimb@zwingli.cygnus.com Wed Jun 14 15:48:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
Date: Wed, 14 Jun 2000 15:48:00 -0000
Message-id: <nppupjhoam.fsf@zwingli.cygnus.com>
References: <E130wkg-0000uJ-00@the-village.bc.nu> <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local>
X-SW-Source: 2000-06/msg00129.html
Content-length: 411

> If there are major problems, it might be wise to choose a different
> name for the PTRACE_{GET,SET}XFPREGS requests to avoid confusion.
> That way, nobody will end up with a non-functional GDB (of course the
> blame lies entirely with the GDB team for this mess).

Well, the blame lies specifically with me, I assume.  I did the
original SSE debugging support.

How should I have done this to avoid the mess?
From ac131313@cygnus.com Wed Jun 14 18:37:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: Jim Ingham <jingham@apple.com>, gdb@sourceware.cygnus.com, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Wed, 14 Jun 2000 18:37:00 -0000
Message-id: <394832F2.39D46459@cygnus.com>
References: <200006141746.KAA29364@alabama.wrs.com>
X-SW-Source: 2000-06/msg00130.html
Content-length: 1910

Todd Whitesel wrote:
> 
> > However, threads may need to be used in the case where you only have a
> > blocking API to control the inferior, but in that case all you are doing is
> > using threads to fix this local deficiency, not pushing it into the gdb
> > architecture.  I think this is managable.
> 
> Agreed. If the API designers are dumb enough to trust threads absolutely,
> and don't give us an option, then well, that's life.

For what it is worth, here is the ``It is hard'' reason number two:

In addition to the expression evaluator, every physical target (that is
the bit that knows how to read/write memory and registers) needs to be
inverted.  The basic programming model used when developing them
requiring a full rewrite.

At present a memory/register IO looks like (vaguely):

	event-loop
	   tty event: (gdb) print ...
		-> expression-evaluator
		    -> target->read()
		        -> os/remote->read()
		        <- data
		    <- data
		<- evaluate
	    print

at the target level, since we are inverting things, it would need to be
broken down into several transactions:

	event-loop
	    tty-event: (gdb) print ...
		-> expression-evaluator
		    -> target->request_read ()
		        -> os/remote->request_read ()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_some_of_data()

	event-loop
	    os/remote-event: some data ready
		-> os/remote->supply_rest_of_data() (all data ready)
		    -> target->supply_data()
			->expression_evaluator->supply_data()

	event-loop
	     ->expression-evaluator->display()

(please don't nit-pick on the detail :-).  The point being that you are
introducing a fundamentally different programming model into _all_
levels of GDB.  You are no longer using procedures but instead passing
around messages and writing state machines or similar.  All of which are
not mechanical.

Just making certain that your eyes are open :-)

	Andrew
From toddpw@windriver.com Wed Jun 14 18:49:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: toddpw@windriver.com (Todd Whitesel), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Wed, 14 Jun 2000 18:49:00 -0000
Message-id: <200006150149.SAA00358@alabama.wrs.com>
References: <394832F2.39D46459@cygnus.com>
X-SW-Source: 2000-06/msg00131.html
Content-length: 365

> > Agreed. If the API designers are dumb enough to trust threads absolutely,
> > and don't give us an option, then well, that's life.
> 
> For what it is worth, here is the ``It is hard'' reason number two:
...
> Just making certain that your eyes are open :-)

No doubts about that. That's why I said "long term goal"...

-- 
Todd Whitesel
toddpw @ windriver.com
From guo@cup.hp.com Thu Jun 15 09:59:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: dan@cgsoftware.com
Cc: gdb@sourceware.cygnus.com
Subject: rfc: remove gdb.hp/gdb.aCC/namespace.exp test
Date: Thu, 15 Jun 2000 09:59:00 -0000
Message-id: <Pine.LNX.4.10.10006150956450.801-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-06/msg00132.html
Content-length: 192

Daniel,

Since you've moved namespace.exp & namespace.cc to gdb.c++, the copies in
gdb.hp/gdb.aCC are redundant.  I can remove these two files if no one
objects.

- Jimmy Guo, guo@cup.hp.com

Re: non-blocking reads/writes and event loops

[Nick Duffek]

On 19-Jun-2000, Jim Ingham wrote:

>Note also that this data has to be updated on EACH STEP, while the user
>expects steps to complete quickly.  And most people are pretty unforgiving
>about both performance in this area

Shared memory could minimize the performance impact.  In fact, on a
multi-processor host, the 2-process approach conceivably could result in
snappier GDB response.

>AND the UI being out of synch with the
>inferior at each stage.

I don't understand how data display synchronization is a 1-GDB-process
vs. multi-GDB-process issue.  If data is being displayed while the
inferior is running, GDB's data display will lag behind reality regardless
of whether the display is happening in a front-end UI process.  If the
inferior is stopped, the data display will be accurate.

What am I missing?

>There are also some interrupt type things that are quite useful to have, and
>which would be more safely implemented in gdb.  One example of this is the
>ability to insert breakpoints while the inferior is running.

Isn't this already addressed by the asynchronous execution feature?

I see how asynchronous breakpoints could be useful, and I agree that they
should be implemented directly rather than via ^C.  I'm arguing against
making things like inferior memory I/O be asynchronous.

>I don't think that the END RESULT of event loop-izing gdb would be to make
>GDB hugely more complex.

I once modified a piece of software to do asynchronous magnetic tape I/O.
It was complex and messy to keep track of the state necessary to make that
one part of the software work asynchronously, but there was a big
performance payoff that made it worthwhile.

Making all parts of GDB work asynchronously seems very complex and messy,
and I still don't see the big payoff.  Of course, I'm extrapolating the
complexity from another software project, so perhaps I'm overestimating
it.

>> Toward implementing this approach, it might be helpful to have a library
>> for storing and transferring parts of GDB state like breakpoints,
>> watchpoints, and "set" values.

>This sounds okay, but do we really want to go the route of prospectively
>priming the GUI with ALL the bits that GDB knows about, and which the UI
>might want to know, at each step, just so we don't have to make gdb
>non-blocking?

Maybe yes, because I would expect a GUI be primed with all those bits
anyway, for the sake of displaying them graphically rather than textually.
E.g., to display the breakpoint list as something other than raw "info
breakpoints" output, a GUI would need to know about breakpoint numbers,
conditions, commands, threads, etc.

Thanks for the in-depth response,

Nick
From jingham@apple.com Mon Jun 19 16:39:00 2000
From: Jim Ingham <jingham@apple.com>
To: Nick Duffek <nsd@redhat.com>
Cc: <gdb@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Mon, 19 Jun 2000 16:39:00 -0000
Message-id: <B573FD45.15D1%jingham@apple.com>
References: <200006192308.TAA21677@nog.bosbc.com>
X-SW-Source: 2000-06/msg00157.html
Content-length: 4989

on 6/19/00 4:08 PM, Nick Duffek at nsd@redhat.com wrote:

> On 19-Jun-2000, Jim Ingham wrote:
> 
>> Note also that this data has to be updated on EACH STEP, while the user
>> expects steps to complete quickly.  And most people are pretty unforgiving
>> about both performance in this area
> 
> Shared memory could minimize the performance impact.  In fact, on a
> multi-processor host, the 2-process approach conceivably could result in
> snappier GDB response.

I would hesitate to use shared memory to communicate between gdb and the UI,
unless I knew that I was only going to have to support a few platforms,
since it is pretty platform dependent...  Maybe if you wrapped it in some
abstraction like CORBA...

> 
>> AND the UI being out of synch with the
>> inferior at each stage.
> 
> I don't understand how data display synchronization is a 1-GDB-process
> vs. multi-GDB-process issue.  If data is being displayed while the
> inferior is running, GDB's data display will lag behind reality regardless
> of whether the display is happening in a front-end UI process.  If the
> inferior is stopped, the data display will be accurate.
> 
> What am I missing?
> 

The processing that goes into packing all the information you need to
present into string based data structures on the gdb end, shipping it across
the pipe, and then unpacking it on the other end.  With a lot of data, this
can be pretty noticable.  You can ameliorate this by using shared memory,
and using something like CORBA to transmit the data in a more structured
form.  But this is not a negligible concern, in my experience.

>> There are also some interrupt type things that are quite useful to have, and
>> which would be more safely implemented in gdb.  One example of this is the
>> ability to insert breakpoints while the inferior is running.
> 
> Isn't this already addressed by the asynchronous execution feature?

Yes, this example falls in the realm of execution, so its okay (except that
of course there is only one target that actually has an async equivalent.)

> 
> I see how asynchronous breakpoints could be useful, and I agree that they
> should be implemented directly rather than via ^C.  I'm arguing against
> making things like inferior memory I/O be asynchronous.
> 

The problem that I have seen is that many things can go wrong in the
communication between the debugger and the target, and if gdb is hung
waiting on something to happen, then the UI can't really give good feedback
as to what is going on.  This leads to times where the UI is alive, which is
good, but has no idea of what GDB is doing.  I can usually reset in this
case, but this is not all that satisfactory, since I don't know from the UI
what went wrong...

>> I don't think that the END RESULT of event loop-izing gdb would be to make
>> GDB hugely more complex.
> 
> I once modified a piece of software to do asynchronous magnetic tape I/O.
> It was complex and messy to keep track of the state necessary to make that
> one part of the software work asynchronously, but there was a big
> performance payoff that made it worthwhile.
> 
> Making all parts of GDB work asynchronously seems very complex and messy,
> and I still don't see the big payoff.  Of course, I'm extrapolating the
> complexity from another software project, so perhaps I'm overestimating
> it.

I don't know.  Tcl is pretty much all event driven.  It took a lot of work
to come up with a model that works well for all sorts of different input
sources, and on a wide variety of different platforms, but having done the
work, it is not that hard now to plug in new sources, and get them to play
nice.  I guess I am saying that we have some models where, once correctly
juked around, the results are quite nice.

> 
>>> Toward implementing this approach, it might be helpful to have a library
>>> for storing and transferring parts of GDB state like breakpoints,
>>> watchpoints, and "set" values.
> 
>> This sounds okay, but do we really want to go the route of prospectively
>> priming the GUI with ALL the bits that GDB knows about, and which the UI
>> might want to know, at each step, just so we don't have to make gdb
>> non-blocking?
> 
> Maybe yes, because I would expect a GUI be primed with all those bits
> anyway, for the sake of displaying them graphically rather than textually.
> E.g., to display the breakpoint list as something other than raw "info
> breakpoints" output, a GUI would need to know about breakpoint numbers,
> conditions, commands, threads, etc.
>

I think I was making the distinction between having data structures to
represent all these sorts of things, which the GUI probably will need, and
actually prospectively filling them all before certain classes of operation,
because the GUI knows the user might open a new window requiring their data,
and GDB will be unresponsive during the given operation, so it can't provide
the info...
 
> Thanks for the in-depth response,
> 

Interesting discussion, no prob...

Jim

Re: non-blocking reads/writes and event loops

[Andrew Cagney]

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

Jim Ingham wrote:


> > As far as I can tell, this provides all the benefits of fully
> > event-loopizing GDB without the cost of making GDB hugely more complex.
> 
> I don't think that the END RESULT of event loop-izing gdb would be to make
> GDB hugely more complex.  In many cases, I think that it would make the
> architecture much simpler and cleaner, since you would not have modal loops
> hiding out all over gdb, but rather a very simple event loop, and,
> hopefully, a standard mechanism for waiting in the event loop that all the
> different modules of gdb could share.  Not to say that the PROCESS of
> getting GDB to this point would be easy, as Andrew points out...

Yes, FWIW, an example of code that would benefit from being inverted is
remote.c.  remote.c, which is implementing a protocol, should be
implemented using a state machine.

	Andrew
From gareth@precisioninsight.com Mon Jun 19 20:56:00 2000
From: Gareth Hughes <gareth@precisioninsight.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: drepper@redhat.com, linux-kernel@vger.rutgers.edu, bug-glibc@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
Date: Mon, 19 Jun 2000 20:56:00 -0000
Message-id: <394FCC8B.37745992@precisioninsight.com>
References: <E130wkg-0000uJ-00@the-village.bc.nu> <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local> <39454E7B.593AFA66@precisioninsight.com> <200006122059.e5CKx9n30406@delius.kettenis.local>
X-SW-Source: 2000-06/msg00159.html
Content-length: 1765

Mark Kettenis wrote:
> 
> Don't put too much effort into it.  I'm going to add some routines to
> GDB that do the conversion from an FXSAVE area to GDB's internal
> format that can be reused for other i386 targets besides Linux.

Okay, I've been offline working on the next release of XFree86 but I've
got the necessary kernel changes in place.  Core dumps now include the
standard FPU format and the FXSAVE FPU format.  We use
PTRACE_{GET|SET}FPXREGS as discussed, with the corresponding
user_fpxregs_struct in user.h.

> Yep, that would be fine.  You'll have to choose a name for the note
> too.  The other notes have the name "CORE", which is also used by
> other SVR4-derived systems.  In that case you'd have to make sure that
> NT_PRFPXREG doesn't clash with types that are already in use.  It's
> probably better to choose a different name.  There are no rules but
> the System V ABI suggests using the name of the vendor.  The old SSE
> support uses "LINUX", which isn't such a bad idea (there is no reason
> to choose a different name).  You can pick any number for NT_PRFPXREG,
> but choosing one that's not already used in libbfd makes life a bit
> easier.

I'd really like to use "CORE" rather than "LINUX", and have chosen
NT_PRFPXREG=20 (or NT_FPXREGSET as appropriate) as this seems to be okay
from what I can tell.  What do Unixware use?  It would be nice to end up
with the note as "CORE", but I can accept "LINUX" as an interim
solution.  Having a standard, cross-platform elf note for the fxsave
data would be ideal.

> Pick a number, and I'll make sure the necessary support will be added
> to libbfd and GDB.

NT_PRFPXREG|NT_FPXREGSET = 20 would make me happy.

I'm merging my work with Linus' latest stuff and will get it out ASAP.

-- Gareth
From toddpw@windriver.com Tue Jun 20 02:48:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: jingham@apple.com (Jim Ingham)
Cc: nsd@redhat.com (Nick Duffek), gdb@sourceware.cygnus.com
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 02:48:00 -0000
Message-id: <200006200948.CAA15871@alabama.wrs.com>
References: <B573FD45.15D1%jingham@apple.com>
X-SW-Source: 2000-06/msg00160.html
Content-length: 716

> I don't know.  Tcl is pretty much all event driven.  It took a lot of work
> to come up with a model that works well for all sorts of different input
> sources, and on a wide variety of different platforms, but having done the
> work, it is not that hard now to plug in new sources, and get them to play
> nice.  I guess I am saying that we have some models where, once correctly
> juked around, the results are quite nice.

While I agree with the theory here, I take issue with the statement that Tcl
implements it.

I was actually quite disappointed by the sources to Tcl/Tk 8.0.2 which
appear to have subtle sub-event loops creeping around whenever callbacks
are used.

-- 
Todd Whitesel
toddpw @ windriver.com
From toddpw@windriver.com Tue Jun 20 03:43:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: ac131313@cygnus.com (Andrew Cagney)
Cc: toddpw@windriver.com (Todd Whitesel), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 03:43:00 -0000
Message-id: <200006201043.DAA22919@alabama.wrs.com>
References: <394DAD8D.C100E36F@cygnus.com>
X-SW-Source: 2000-06/msg00161.html
Content-length: 1519

> For what its worth, for some reason I have preference for the first
> option - not sure why, perhaphs it is simply that I'm more familar with
> targets and back-ends.

IMHO the simplest way is always to invert from the top down, so things are
just merged into the main event loop as you go.

> As I noted above, one of the original design decisions for the event
> loop that it not be re-entrant.  The above questions that decision. 

Well that depends on how much of the event loop machinery is used by the
low-level inversion. If it calls things that assume a single global event
loop, then we have a problem.

If you have to invert a low-level algorithm early on, there are a couple
ways to do it:

  1. make the event loop machinery instantiable and use a new instance of it.
	THIS IS ARGUABLY NECESSARY FOR MULTIPLE TARGET CONNECTIONS ANYWAY.

  2. do not attempt to provide full non-blocking facilities yet, just show
	that the low-level code works correctly in inverted form -- its
	sub-event loop just calls it repeatedly, so it still blocks but at
	least uses the new code structure.

IMHO either is fine; which one you use depends on whether you have gotten
the instantiable event loop machinery working yet.

> Another decision was that GDB's core assume no threads.  Should that too
> be questioned?

I don't mind specific native target support assuming threads.

However using threads as a general method of avoiding the inversion of
GDB core code is a COP OUT.

-- 
Todd Whitesel
toddpw @ windriver.com
From ezannoni@cygnus.com Tue Jun 20 07:35:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Todd Whitesel <toddpw@windriver.com>
Cc: ac131313@cygnus.com (Andrew Cagney), jingham@apple.com (Jim Ingham), gdb@sourceware.cygnus.com, insight@sourceware.cygnus.com ("Insight (GDB GUI)")
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 07:35:00 -0000
Message-id: <14671.33056.854540.470670@kwikemart.cygnus.com>
References: <394DAD8D.C100E36F@cygnus.com> <200006201043.DAA22919@alabama.wrs.com>
X-SW-Source: 2000-06/msg00162.html
Content-length: 2857

Todd Whitesel writes:
 > > For what its worth, for some reason I have preference for the first
 > > option - not sure why, perhaphs it is simply that I'm more familar with
 > > targets and back-ends.
 > 
 > IMHO the simplest way is always to invert from the top down, so things are
 > just merged into the main event loop as you go.
 > 
 > > As I noted above, one of the original design decisions for the event
 > > loop that it not be re-entrant.  The above questions that decision. 
 > 
 > Well that depends on how much of the event loop machinery is used by the
 > low-level inversion. If it calls things that assume a single global event
 > loop, then we have a problem.

Yes, that wasn't one of the things I worried about when I wrote the
event loop.

 > 
 > If you have to invert a low-level algorithm early on, there are a couple
 > ways to do it:
 > 
 >   1. make the event loop machinery instantiable and use a new instance of it.
 > 	THIS IS ARGUABLY NECESSARY FOR MULTIPLE TARGET CONNECTIONS ANYWAY.
 > 
 >   2. do not attempt to provide full non-blocking facilities yet, just show
 > 	that the low-level code works correctly in inverted form -- its
 > 	sub-event loop just calls it repeatedly, so it still blocks but at
 > 	least uses the new code structure.
 > 

Yes, we must do things in smaller steps. Otherwise the task is so
daunting, it will never get done. 

There were actually a few things that we were considering as 'next
steps' in the event-loopization process. One is to hook up the async
version of the remote target to the Insight gui. Another is to make a
native target asynchronous. The choice here would be Linux, I
think. Also there are interface/CLI issues (style decisions) still to
be resolved with the asyncrhonous remote target.

As Andrew pointed out, the remote target is the hairy case. We
encountered several problems when writing the asynchronous version. We
got as far as we could, w/o having to revise major assumptions, and
found that we got maybe 70/80 % of the stuff working fine. The
remaining bits were the hard ones (the ones where GDB gets stuck
and you don't know what happened), for which we really need to do
major surgery to remote.c and the layers below that.

Has anybody tried to use 'target async' and 'target extended-async' in
place of 'target remote' and 'target extended-remote'? I have heard no
feedback on them at all. 

Elena

 > IMHO either is fine; which one you use depends on whether you have gotten
 > the instantiable event loop machinery working yet.
 > 
 > > Another decision was that GDB's core assume no threads.  Should that too
 > > be questioned?
 > 
 > I don't mind specific native target support assuming threads.
 > 
 > However using threads as a general method of avoiding the inversion of
 > GDB core code is a COP OUT.
 > 
 > -- 
 > Todd Whitesel
 > toddpw @ windriver.com
From jimb@zwingli.cygnus.com Tue Jun 20 10:20:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, Todd Whitesel <toddpw@windriver.com>, Jim Ingham <jingham@apple.com>, gdb@sourceware.cygnus.com, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 10:20:00 -0000
Message-id: <np1z1sfevh.fsf@zwingli.cygnus.com>
References: <Pine.LNX.4.10.10006182227270.24967-100000@propylaea.anduin.com>
X-SW-Source: 2000-06/msg00163.html
Content-length: 524

> The question about whether we *should* use threads is a different
> one altogether.  The real question splits into "Are there parts of
> gdb where we could be doing processing that isn't dependent on other
> processing, and we therefore are possibly wasting time on MP systems
> by not having each done in a thread" and "Are there parts of GDB
> where we could simplify code flow by using threads".

Srikanth at HP has mentioned the idea of doing symbol table reads in
the background.  I thought that sounded pretty cool.
From jimb@zwingli.cygnus.com Tue Jun 20 10:23:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: non-blocking reads/writes and event loops
Date: Tue, 20 Jun 2000 10:23:00 -0000
Message-id: <npzooge063.fsf@zwingli.cygnus.com>
References: <3944B786.A16E9A2F@cygnus.com> <200006162154.RAA21307@nog.bosbc.com>
X-SW-Source: 2000-06/msg00164.html
Content-length: 426

> I'd rather see the GUI problems solved by two processes:
>   (1) the GDB core, which talks to inferior processes;
>   (2) the user interface, which talks to (1) over a pipe using a
>       well-defined protocol.
> 
> [Credit to Chris Faylor and Jim Blandy for suggesting this
>   approach.]

I don't think that's what I meant to suggest.  I meant to suggest
something much less radical, and probably didn't explain it well.
From jimb@zwingli.cygnus.com Tue Jun 20 10:43:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Gareth Hughes <gareth@precisioninsight.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, drepper@redhat.com, linux-kernel@vger.rutgers.edu, bug-glibc@gnu.org, gdb@sourceware.cygnus.com
Subject: Re: [PATCH] More updates to FXSR/SSE support in 2.4.0-test1
Date: Tue, 20 Jun 2000 10:43:00 -0000
Message-id: <npwvjkdz90.fsf@zwingli.cygnus.com>
References: <E130wkg-0000uJ-00@the-village.bc.nu> <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local> <39454E7B.593AFA66@precisioninsight.com> <200006122059.e5CKx9n30406@delius.kettenis.local> <394FCC8B.37745992@precisioninsight.com>
X-SW-Source: 2000-06/msg00165.html
Content-length: 1547

> > Yep, that would be fine.  You'll have to choose a name for the note
> > too.  The other notes have the name "CORE", which is also used by
> > other SVR4-derived systems.  In that case you'd have to make sure that
> > NT_PRFPXREG doesn't clash with types that are already in use.  It's
> > probably better to choose a different name.  There are no rules but
> > the System V ABI suggests using the name of the vendor.  The old SSE
> > support uses "LINUX", which isn't such a bad idea (there is no reason
> > to choose a different name).  You can pick any number for NT_PRFPXREG,
> > but choosing one that's not already used in libbfd makes life a bit
> > easier.
> 
> I'd really like to use "CORE" rather than "LINUX", and have chosen
> NT_PRFPXREG=20 (or NT_FPXREGSET as appropriate) as this seems to be okay
> from what I can tell.  What do Unixware use?  It would be nice to end up
> with the note as "CORE", but I can accept "LINUX" as an interim
> solution.  Having a standard, cross-platform elf note for the fxsave
> data would be ideal.

When I last talked with folks from SCO, they said they had no
debugging support for SSE registers.  I didn't feel I had the right to
speak for all Unixes, so I chose LINUX.

Keep in mind that it's easy for a debugger to recognize multiple note
types, but (in general) impossible to unravel conflicting definitions
for the same note type.  While it certainly feels cleaner to have a
"standard, cross-platform ELF note", I think it's actually asking for
trouble.  I recommend sticking with "LINUX".
From eliz@delorie.com Wed Jun 21 05:16:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Re: non-blocking reads/writes and event loops
Date: Wed, 21 Jun 2000 05:16:00 -0000
Message-id: <200006211216.IAA02909@indy.delorie.com>
References: <B573AB21.14C0%jingham@apple.com> <394DA914.5C6CA062@cygnus.com>
X-SW-Source: 2000-06/msg00166.html
Content-length: 3675

Could we please step back for a moment and see the big picture before
talking about the details?

It's possible that I'm the only clueless one in town, in which case
please be gentle with me ;-).  But it seems to me that not everybody
in this thread has the same purpose in mind when discussing the
non-blocking features.  So perhaps it will help to revisit the broader
issue, even if it were discussed in the past.

I mean, non-blocking is nice, but where would a user want it in GDB?

To me, a debugger is a way of tightly-controlled program execution.
We all know how much concentration and detail it takes to debug a
non-trivial program.  You need to be sure what is the current state of
the program, before you make the next step.  Finding out the exact
state of the program might require printing lots of variables,
examining registers, calling functions, head-scratching, hair-pulling,
etc.

So what does ``non-blocking'' mean, in this context?  If I ask GDB for
the value of some expression that takes a long time to compute, what
possibly would I want to do while GDB and the inferior grind away to
bring me the result, except wait impatiently for the result to come
through?  I cannot switch to anything else, because that will distract
me, and I will lose my grip on the problem (unless the computation
takes hours, in which case I probably won't use that method of
debugging anyway).

Someone brought up the issue of several targets being debugged
simultaneously.  One possible situation when this will be useful is
when the targets being debugged are parts of a complex system,
i.e. they talk to each other through various means, or act on the same
data.  (Are there any other situations where debugging several targets
simultaneously makes sense?)

If that is the case, would you want to let one target run while the
other is blocked because GDB is interrogating it?  I think not: if you
do, you lose control of what's going on in the larger _system_ you are
debugging.  So, again, there's nothing you can do but wait for the
lengthy operation to complete and show you the results.

Only *after* you have seen these results, can you decide what to do
next.  You could let the program run some more, or add some variables
to the displayed ones and single-step it, or maybe look at some more
variables before you know what to do.  It will not help you to be able
to run the inferior while you are examining variables and thinking
about what you see, because it's quite possible that what the inferior
does while you think will have to be discarded, or even destroys some
data and covers up the traces of the bug you are hunting.  Since
there's no easy way to run the inferior backwards, it's better not to
let it run until you know how do you want to proceed with debugging.

It does make sense to have some degree of non-blocking behavior when
the info I requested is so voluminous that it is larger than I can
grasp in a single glance.  In that case, it is useful to have GDB work
asynchronously while I'm reading the first screenful.  But this kind
of functionality is already supported by the event loop, so if GDB
talks to targets through `select' or `poll', we are done.  This is
nowhere near the problem of GDB and the UI falling out of sync, data
coming to the user that lags behind the inferior program's state,
etc., which, to me, are in sharp contradiction to the very purpose of
debugging: a controlled execution of a program.

In other words, I submit that debugging is a single-thread activity,
as far as we humans are concerned.  And if that is the case, what
exactly do we want the totally-non-blocking GDB for, except the
voluminous output case?
From gerwynd@tommoll.freeserve.co.uk Thu Jun 22 02:20:00 2000
From: "Gerwyn Davies" <gerwynd@tommoll.freeserve.co.uk>
To: "GDB" <gdb@sourceware.cygnus.com>
Subject: Trying to build GDB
Date: Thu, 22 Jun 2000 02:20:00 -0000
Message-id: <002401bfdc2b$684c5280$1d4d883e@gtd-s-machine>
X-SW-Source: 2000-06/msg00167.html
Content-length: 742

I have a few small problems building GDB which 
maybe someone can provide a little help:
 
I'm building on a Windows 98 system from within 
a BASH shell, my configure command line was:-
 sh configure i586 
--target=mipstx39
 
The configure completes all OK, but during the 
make process I get a illegal operation error, with the message in my shell 
window saying " make: vfork: No more processes ". Sounds like I've got 
some resource problem that needs a tweak, but I dont know what to 
tweak.
 
My other problem occours towards the end of the 
make, with make complaining that it can't find the files <psapi.h> and 
<imagehlp.h>. I've searched, but these two don't exist anywhere on my 
system.
 
Any ideas?
 
Many thanks
 
Gerwyn