Re: non-blocking reads/writes and event loops

[Andrew Cagney <ac131313@cygnus.com>]

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