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 To: Mark Kettenis 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: <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 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: 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 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 To: Todd Whitesel 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 To: Daniel Berlin Cc: Andrew Cagney , Todd Whitesel , Jim Ingham , gdb@sourceware.cygnus.com, "Insight (GDB GUI)" Subject: Re: non-blocking reads/writes and event loops Date: Tue, 20 Jun 2000 10:20:00 -0000 Message-id: References: 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 To: Nick Duffek 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: 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 To: Gareth Hughes Cc: Mark Kettenis , 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: References: <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 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: <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" To: "GDB" 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 and . I've searched, but these two don't exist anywhere on my system.   Any ideas?   Many thanks   Gerwyn