From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gareth Hughes To: Mark Kettenis Cc: alan@lxorguk.ukuu.org.uk, drepper@redhat.com, adam@yggdrasil.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: Sun, 11 Jun 2000 21:56:00 -0000 Message-id: <39454E7B.593AFA66@precisioninsight.com> References: <394428DD.A2EFC21B@precisioninsight.com> <200006120002.e5C02mv14043@delius.kettenis.local> X-SW-Source: 2000-06/msg00086.html Mark Kettenis wrote: > > Date: Sun, 11 Jun 2000 18:03:41 -0600 > From: Gareth Hughes > > Here's a copy of my latest work, this time kernel and glibc headers > only. I'm still working on updating GDB, as incorporating Mark's > suggestions leads to some problems with the stock 5.0 code (mainly in > the interpretation of the FPU tag word). > > Looks much better :-). I didn't realize there were tag word problems > until yesterday :-(. If this means that stock GDB 5.0 won't work > anymore, so be it. A sane kernel interface is more important. I agree. I'm happy with this as it's correct, fast *and* backward compatible. Thanks again everyone for pulling me up on the third point :-) > What exactly happens if you try to compile stock GDB 5.0 with the new > kernel? Does it compile at all? Is it seriously crippled? Or does > it basically work right? It works (kind of), it's just extracting the FPU register data incorrectly and then misinterpreting the tag word and thus incorrectlying interpreting the incorrect data :-). It's a pretty trivial patch, the extraction fix is contained in my last patch and I've just got to copy the tag word conversion code across. Should have a patch in a couple of hours - busy with work at the moment. > 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). My suggestion > would be to call those requests PTRACE_{GET,SET}FPXREGS. It turns out > that Unixware uses a similar name for its FXSR support (they don't > have ptrace(), but they have a PCSFPXREG ioctl() and a __fpxregset_t > type[1]). Moreover this makes the FSAVE/FPREGS vs. FXSAVE/FPXREGS > analogy a bit more explicit. I like this idea, makes a whole lot more sense. This is kinda what I was arguing for way back in our previous emails. It also matches up nicely with the signal handling types I've declared. It would be good to get a working GDB 5.0 with a patch rather than a broken one when you haven't patched it. The standard PTRACE_{GET|SET}FPREGS works fine as it stands, and in many cases this will be good enough. When is the next release of GDB planned for? I'd like some clarification on core dumping - will it be okay to add a new note NT_PRFPXREG, a new elf type elf_fpxregset_t and so on? If so, I'll add this to the kernel and my GDB 5.0 patch and fire it off today. -- Gareth >From ac131313@cygnus.com Mon Jun 12 02:04:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory regions, dcache Date: Mon, 12 Jun 2000 02:04:00 -0000 Message-id: <3944A778.74396B73@cygnus.com> References: <5mk8fyvfzy.fsf@jtc.redback.com> X-SW-Source: 2000-06/msg00087.html Content-length: 6109 "J.T. Conklin" wrote: > > Setting aside symbol table performance for the moment, I'm back > finishing up memory region attributes. > > In previous messages, I've shared my changes to target_xfer_memory(). > Those have not changed significantly. Since that time, I've added a > 'mem_attrib *attrib' argument to the target vectors to_xfer_memory() > function, and have fixed up all the code for all the targets. While I > was there, I noticed that some target's *_xfer_memory() function did > not declare the 'struct target_ops *target' argument, so I fixed that > up at the same time. (Btw, Are there any *_xfer_memory() functions > that use the 'target' argument? I didn't see any while I was adding > the new argument, but I wasn't looking for it either. If nothing uses > it, I wouldn't mind removing it as part of this change.) I think, long term, the target will need to be a parameter to every target method. If GDB ever does find its self with two active target vectors then this will become an issue. However, in the mean time .... > Now that the mem_attrib argument is available, target *_xfer_memory() > functions may be able to tailor their behavior accordingly. I say > 'may be able' because currently most of the functions simply ignore > the new arguement (either because the function has not been changed to > use the attribute, or perhaps because the host/target interface/ > protocol cannot support the attribute(s) selected. Is there anything > I should do about this now, or is the fact that some attributes are > not supported on all targets a given that just needs to be documented? If a user sets (pick a random attribute) the atomic attribute (see next paragraph) but the target doesn't support it shouldn't the user be told that the attribute was ignored? I think it is important to not mis-lead the user with this. (By atomic I mean read/write a word as a word and not as a sequence of bytes - assuming that is a possible attribute. On some targets a word read (arm?) returns a different value to a byte read). > In most of the embedded remote targets, the target vector code calls > dcache_init() in the *_open() function to register functions used to > read and write memory, and the *_xfer_memory() functions calls > dcache_xfer_memory() which uses the functions registered earlier to > perform the I/O. The problem is that there is no way to pass the > attribute argument through dcache to the functions. > > This should be fairly easy to address --- just a lot of grunt work > fixing up dcache_xfer_memory() and the read and write functions to > take the new argument. However, I wonder whether it would be better > (cleaner, more "elegant", etc.) to move dcache up a layer and put it > between target_xfer_memory() and the target *_xfer_memory() functions. > > For example, instead of calling a target vector's *to_xfer_memory(), > target_xfer_memory() would call dcache_xfer_memory() with a target > vector pointer. If dcache_xfer_memory() had to do i/o, it would call > the target vector's *to_xfer_memory() function. I think the elegant solution is preferable (but as you ask, is it feasible?). > Having the dcache at a higher level might be useful for implementing > the verify (read and compare after writes) attribute. As I imagine > things, verify support would be implemented in target_xfer_memory() > and would re-read and compare after a write. But if the target code > uses dcache, the read would not come from the target but the cache. > On the other hand, target_xfer_memory() could do a cache invalidate > before reading (and a more refined cache invalidate could easily be > written). > > All that being said, I think that going the simple route and adding > the parameter to dcache_xfer_memory() and to the target read/write > functions may be the right thing for now. It won't be difficult to > re-evaluate this decision and go for the more integrated approch if > that turns out to be the right thing over time. Everytime something in the target makes a call back into the guts of GDB, the problem of implementing things like gdbserver become just that bit harder. The less things the target tries to do the better. With this in mind, have you considered a more incremental approach: o add a new memory read/write method that has the interface you desire. o have the new dcache use that interface o provide a simple default implementation of the new method that uses the old interface. This should give you the freedom to ``get it working'' using the main repository and then people can fix their target (Or I'll get Stan to obsolete it :-). It would also make dcache available to native targets. The comment: /* NOTE: cagney/1999-10-18: This function (and its siblings in other remote targets) shouldn't attempt to read the entire buffer. Instead it should read a single packet worth of data and then return the byte size of that packet to the caller. The caller (its caller and its callers caller ;-) already contains code for handling partial reads. */ is relevant here. [There is another issue lurking here, rather then raise it I'll start a new thread] > One more thing before this gets too long. There is a remotecache > variable that globally enables the cache which is currently disabled. > With attributes, each memory region has a cache/nocache atttribute. > Should the remotecache variable override the attribute. Or can we > depricate remotecache completely? Since when no memory attributes > are defined the default attribute is used which disables the cache, > there isn't much need for a global flag any more. You mean delete the command :-) FYI, things have changed a little - its now the static variable dcache.c:dcache_enabled_p and wince.c sets it using dcache.c:set_dcache_state(1). I think the command (but not the global variable) would need to be around for at least one more release. Can it be converted into a recursive call to the CLI with a command that enables/disables all memory regions? However, is there any evidence that people actually use it? Andrew >From ac131313@cygnus.com Mon Jun 12 03:13:00 2000 From: Andrew Cagney To: GDB Discussion , "Insight (GDB GUI)" Subject: non-blocking reads/writes and event loops Date: Mon, 12 Jun 2000 03:13:00 -0000 Message-id: <3944B786.A16E9A2F@cygnus.com> X-SW-Source: 2000-06/msg00088.html Content-length: 2596 Hello, [this is a cross post, reply-to has been set to gdb@sourceware] Two architectural changes introduced in 5.0 were the the event-loop and the targets ``remote async'' and ``remote extended-async''. J.T.'s recent posting about memory read/write raises a second significant issue related to the event-loops, GUI's and async but first some background. The event-loop provides a mechanism that allows GDB to block on more than one input (or output) source. For instance, GDB might be blocked waiting for both the remote target and the user input. As events arrive, the event-loop dispatches them. The async/extended-async targets exploit the event-loop so that, while the target is running, the user can still enter various commands. For instance: (gdb) target extended-async .... (gdb) run& (gdb) (gdb) help ... .... (gdb) Breakpoint #1 reached, ... (gdb) In getting this working, numerous problems were identified and several compromizes were made (look for FIXMEs, especially in remote.c). The main compromize is to do with when the target has halted. While the target is running the async target code returns control to the main event-loop. When the target starts ending it stopped packet, or when the target is assumed to be halted, the code revers to polling. Memory reads/writes and the like are blocking operations - they do not return control to the event loop. For instance: (gdb) print foo gdb calls target-vector to read memory (&foo, sizeof(foo)) target-vector ``calls'' remote to read memory from &foo target-vector blocks target-vector receives data from remote gdb receives data from target-vector $1 = "foo" (gdb) The rationale behind the decision to block in this case was very pragmatic - it wasn't going to be feasible to invert (as was done to serial.c) all of GDB (so that everything was event based) in a single hit. The consequence is that, during these blockages, GDB is slower than dring normal operation - for the CLI the problem isn't too noticable. For the GUI, however, it is very noticable. As a result, the built in GUI (ex insight) is forced to use other means to avoid this slugishness - during those blocked reads a timer is set up and that is used to process the GUI events (see ui_loop_hook() and gdb/gdbtk/generic/gdbtk-hooks.c:x_event()). The thing that needs to be decided is how far GDB should be pushed to address this problem. Should GDB continue to be pushed to the point where everything is event based or should, the current compromise remain where a GUI is unable to exploit GDBs event-loop. Andrew >From ac131313@cygnus.com Mon Jun 12 04:15:00 2000 From: Andrew Cagney To: GDB Discussion Subject: That vision thing ... Date: Mon, 12 Jun 2000 04:15:00 -0000 Message-id: <3944C636.7C8EF242@cygnus.com> X-SW-Source: 2000-06/msg00089.html Content-length: 1747 (If you know something about Australian politics ``The Vision Thing'' is a backhanded slap at someone that that has no sense of vision :-) Hello, For the curious :-) Where next. Firstly, there is always the ongoing and important need to improve things like language support (namely C++), symbol-table performance, native threads, code cleanups, bug fixes and the like. I believe that that there is now plenty active and ongoing development in these area. Me giving opinions on it would just be distracting. I also think that these ongoing developments are going to be the principal factors that determine the time frame for each succeeding GDB release. They are also the things that attract the most attention and also get the most praise :-) Longer term I can see two significant developments: o libgdb The basic motivation is the desire to make it easier (and more robust) to integrate GDB into a GUI. Here the first step is MI (along with ui-out/ui-file). o multi-arch et al. Here the objective is to remove the assumption that GDB has, at any time, just one thread/language/isa /abi/vm/target/.... The motivation being to make it possible for GDB to handle complex targets that contain multiple architectures and the like. Here that first step is multi-arch. So? I'd just like to encourage people to pursue what they are currently working on. Just keep in mind that there is likely to be more significant change (especially through multi-arch) lurking in the background. For my part I hope to be concentrating on mult-arch et al, however, I will most likely occasionally prod libgdb. As with any bit of open source, there is of course, no timeframe ... Comments, fits of laughter, ... Andrew >From eliz@delorie.com Mon Jun 12 05:46:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, nsd@cygnus.com, Peter.Schauer@regent.e-technik.tu-muenchen.de, rjl@sco.com, cgf@cygnus.com, jtc@redback.com, jimb@cygnus.com Subject: Re: i386 debugging registers Date: Mon, 12 Jun 2000 05:46:00 -0000 Message-id: <200006121246.IAA24337@indy.delorie.com> References: <200006112322.e5BNM6513971@delius.kettenis.local> <3944218C.6FAAA98A@cygnus.com> X-SW-Source: 2000-06/msg00090.html Content-length: 704 > Date: Sun, 11 Jun 2000 23:32:28 +0000 > From: Fernando Nasser > > I can see one situation where one may want to look at or set > debugger registers: when debugging a debugger's hardware breakpoint > support. Yes, definitely. I found myself doing that a lot when I enhanced the hardware watchpoint/breakpoint support in go32-nat.c (you will see in the sources an #ifdef'ed away fragment which, if $GDB_SHOW_DR is set in the environment, causes go32-nat.c to print current values of debug registers). > We can add a maintenance command to access that. That is what maintenance > commands are for. I agree: a maint command that prints the debug registers would be very useful. >From qqi@world.std.com Mon Jun 12 08:00:00 2000 From: Quality Quorum To: Andrew Cagney Cc: GDB Discussion Subject: Re: That vision thing ... Date: Mon, 12 Jun 2000 08:00:00 -0000 Message-id: References: <3944C636.7C8EF242@cygnus.com> X-SW-Source: 2000-06/msg00091.html Content-length: 1984 On Mon, 12 Jun 2000, Andrew Cagney wrote: > (If you know something about Australian politics ``The Vision Thing'' is > a backhanded slap at someone that that has no sense of vision :-) > > Hello, > > For the curious :-) Where next. > > Firstly, there is always the ongoing and important need to improve > things like language support (namely C++), symbol-table performance, > native threads, code cleanups, bug fixes and the like. I believe that > that there is now plenty active and ongoing development in these area. > Me giving opinions on it would just be distracting. > > I also think that these ongoing developments are going to be the > principal factors that determine the time frame for each succeeding GDB > release. They are also the things that attract the most attention and > also get the most praise :-) > > Longer term I can see two significant developments: > > o libgdb > > The basic motivation is the desire > to make it easier (and more robust) to > integrate GDB into a GUI. > > Here the first step is MI (along with > ui-out/ui-file). > > o multi-arch et al. > > Here the objective is to remove > the assumption that GDB has, at any > time, just one thread/language/isa > /abi/vm/target/.... The motivation > being to make it possible for GDB to > handle complex targets that contain > multiple architectures and the like. > > Here that first step is multi-arch. > > So? > > I'd just like to encourage people to pursue what they are currently > working on. Just keep in mind that there is likely to be more > significant change (especially through multi-arch) lurking in the > background. For my part I hope to be concentrating on mult-arch et al, > however, I will most likely occasionally prod libgdb. > > As with any bit of open source, there is of course, no timeframe ... > > Comments, fits of laughter, ... Can we split target depended pieces into subdirs under gdb ? > > Andrew > Thanks, Aleksey