From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: [RFC] Pascal language: case insensitivity! Date: Mon, 19 Jun 2000 03:57:00 -0000 Message-id: <200006191117.NAA25188@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00146.html I have code in my local source tree that allow GDB to cope with the case insensitivity of pascal language (at least partially). The diffs are at the bottom of this file. The way I implemented is to define a new function extern int re_iexec _RE_ARGS ((char *,int)); that does a case sensitive (normal) search if the second arg is zero while the search becomes insensitive if the second arg is non zero in practice the second arg is (current_language.language == language_pascal) for now, but there might be other case insensitive languages supported. (I even don't know if Modula 2 is case sensitive or not). Practically I added also extern int create_case_insensitive_translate_buffer _RE_ARGS (()); extern int reset_translate_buffer _RE_ARGS (()); functions to create the translations. I already talked a while ago about this and someone (can't remember who) said that there is a much simpler way to get this result. I would of course really like to know more about this possibility. The diffs below are not a patch as such, I only append them to show the amont of code that is involved in this feature, which isn't that huge in fact. By the way, gnu-regex still has PARAMS stuff in it ! is the _RE_ARGS macro still to be kept or should it be removed as PARAMS ? Index: gnu-regex.c =================================================================== RCS file: /cvs/src/src/gdb/gnu-regex.c,v retrieving revision 1.4 diff -c -r1.4 gnu-regex.c *** gnu-regex.c 2000/05/31 21:26:47 1.4 --- gnu-regex.c 2000/06/19 10:34:44 *************** *** 5480,5485 **** --- 5480,5486 ---- /* BSD has one and only one pattern buffer. */ static struct re_pattern_buffer re_comp_buf; + static RE_TRANSLATE_TYPE case_insensitive_buffer; char * #ifdef _LIBC *************** *** 5538,5543 **** --- 5539,5616 ---- const int len = strlen (s); return 0 <= re_search (&re_comp_buf, s, len, 0, len, (struct re_registers *) 0); + } + + /* allocates a unique translation buffer for insensitive search */ + /* FIXME this buffer is never disposed */ + + int create_case_insensitive_translate_buffer () + { + int i; + if (!case_insensitive_buffer) + { + case_insensitive_buffer = (RE_TRANSLATE_TYPE) malloc (CHAR_SET_SIZE + * sizeof (*(RE_TRANSLATE_TYPE)0)); + if (case_insensitive_buffer == NULL) + return (int) REG_ESPACE; + + /* Map uppercase characters to corresponding lowercase ones. */ + for (i = 0; i < CHAR_SET_SIZE; i++) + case_insensitive_buffer[i] = ISLOWER (i) ? toupper (i) : i; + } + + /* Use this for re_comp called after */ + re_comp_buf.translate = case_insensitive_buffer; + + return 0; + } + + int reset_translate_buffer () + { + int i; + if (case_insensitive_buffer) + free(case_insensitive_buffer); + /* Use this for re_comp called after */ + re_comp_buf.translate = NULL; + return 0; + } + + int + re_iexec (s,insensitive) + char *s; + int insensitive; + { + RE_TRANSLATE_TYPE store_translate; + struct re_pattern_buffer private_preg; + const int len = strlen (s); + int res; + if (insensitive) + { + unsigned i; + if (!case_insensitive_buffer) + { + int res = create_case_insensitive_translate_buffer(); + if (res) + return res; + } + store_translate = re_comp_buf.translate; + re_comp_buf.translate = case_insensitive_buffer; + + for (i = 0; i < len; i++) + if (ISLOWER(s[i])) + s[i] = toupper (s[i]); + } + else + { + store_translate = re_comp_buf.translate; + re_comp_buf.translate = case_insensitive_buffer; + + } + res = re_search (&re_comp_buf, s, len, 0, len, (struct re_registers *) 0); + + re_comp_buf.translate = store_translate; + return + 0 <= res; } #endif /* _REGEX_RE_COMP */ Index: gnu-regex.h =================================================================== RCS file: /cvs/src/src/gdb/gnu-regex.h,v retrieving revision 1.1.1.4 diff -c -r1.1.1.4 gnu-regex.h *** gnu-regex.h 1999/10/12 04:37:21 1.1.1.4 --- gnu-regex.h 2000/06/19 10:34:45 *************** *** 536,543 **** --- 536,547 ---- #ifdef _REGEX_RE_COMP # ifndef _CRAY /* 4.2 bsd compatibility. */ + extern int create_case_insensitive_translate_buffer _RE_ARGS (()); + extern int reset_translate_buffer _RE_ARGS (()); extern char *re_comp _RE_ARGS ((const char *)); extern int re_exec _RE_ARGS ((const char *)); + extern int re_iexec _RE_ARGS ((char *,int)); + # endif #endif Index: source.c =================================================================== RCS file: /cvs/src/src/gdb/source.c,v retrieving revision 1.3 diff -c -r1.3 source.c *** source.c 2000/05/28 01:12:29 1.3 --- source.c 2000/06/19 10:34:52 ************* *** 1587,1593 **** /* we now have a source line in buf, null terminate and match */ *p = 0; ! if (re_exec (buf) > 0) { /* Match! */ fclose (stream); --- 1587,1593 ---- /* we now have a source line in buf, null terminate and match */ *p = 0; ! if (re_iexec (buf,(int) (current_language->la_language == language_pascal)) > 0) { /* Match! */ fclose (stream); *************** *** 1697,1703 **** /* We now have a source line in buf; null terminate and match. */ *p = 0; ! if (re_exec (buf) > 0) { /* Match! */ fclose (stream); --- 1697,1703 ---- /* We now have a source line in buf; null terminate and match. */ *p = 0; ! if (re_iexec (buf,(int) (current_language->la_language == language_pascal)) > 0) { /* Match! */ fclose (stream); Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.8 diff -c -r1.8 symtab.c *** symtab.c 2000/06/14 00:59:07 1.8 --- symtab.c 2000/06/19 10:35:10 *************** *** 3677,3682 **** --- 3677,3690 ---- } } + if (current_language->la_language == language_pascal) + { + create_case_insensitive_translate_buffer(); + } + else + { + reset_translate_buffer(); + } if (0 != (val = re_comp (regexp))) error ("Invalid regexp (%s): %s", val, regexp); } *************** Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From cgf@cygnus.com Mon Jun 19 08:23:00 2000 From: Chris Faylor To: Andrew Cagney Cc: Nick Duffek , gdb@sourceware.cygnus.com Subject: Re: non-blocking reads/writes and event loops Date: Mon, 19 Jun 2000 08:23:00 -0000 Message-id: <20000619112314.G14829@cygnus.com> References: <3944B786.A16E9A2F@cygnus.com> <200006162154.RAA21307@nog.bosbc.com> <394DA914.5C6CA062@cygnus.com> X-SW-Source: 2000-06/msg00147.html Content-length: 2730 On Mon, Jun 19, 2000 at 03:01:08PM +1000, Andrew Cagney wrote: >Nick Duffek wrote: > >> >So my vote is to eradicate ALL the blocking behavior, and make GDB a pure >> >event driven application. >> >> Does that include file I/O? Reading a core file over NFS could freeze a >> GUI for quite a while. > >Some how, I suspect not. Some operations, such as reading/writing an >executable will continue to be blocking. If an NFS partition freezes >then I suspect a hung GDB is the last thing on the users mind :-) > >> 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.] > >FYI, the ``well defined protocol'' is called MI :-) I think I suggested that this was the same mechanism that we had been considering for future UI work. (deftly dancing) >> The user interface could be a GUI, a command-line interface, Emacs, etc. >> Pipes are non-blocking, so a GUI need never freeze due to blocking >> debugging calls. >> >> 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. > >Unfortunately, it avoids rather than solves the problem. One thing we >found from MI is that even after you separate out the GUI, GDB, in the >end, still needs to be 100% non blocking. > >Consider a GDBng (GDB 6) that is trying to talk to two (or more) active >remote targets. The current remote.c blocks out all other activity >while it is communicating with a single target. Just like it can >currently block out the GUI, it would also block out the processing of >those other targets. While the user is surprisingly tolerant of a 5-30 >second hiccup, the typical protocol tends to be be surprisingly >intolerant :-) I don't think that Nick was suggesting going back to 100% blocking behavior. In this case, if blocking I/O was the only thing available, you'd need to fork another process. I was thinking more of a process hive which communicated via shared memory. So, there would be a main "gdb" which printed a prompt and as many other dedicated processes as needed to control targets. As far as NFS is concerned, I think that Nick was talking about the noticeable lags that can occur when loading something like a core file over NFS. The delay isn't necessarily a sign of a problem with NFS. Maybe a user would expect a long delay in this case but I would think that it would also be a problem for gdb. If you assigned the "reading a core file" function to another process then the lag could be circumvented. cgf >From dje@transmeta.com Mon Jun 19 09:02:00 2000 From: Doug Evans To: gdb@sourceware.cygnus.com Subject: execute_command wrapper? Date: Mon, 19 Jun 2000 09:02:00 -0000 Message-id: <200006191601.JAA28217@casey.transmeta.com> X-SW-Source: 2000-06/msg00148.html Content-length: 198 Would it be reasonable to add an execute_command wrapper to wrapper.c? I'm thinking of a situation where one has added a different scripting language to gdb and one wants to execute a gdb command. >From larry@smith-house.org Mon Jun 19 09:12:00 2000 From: Larry Smith To: Pierre Muller Cc: gdb@sourceware.cygnus.com Subject: Re: [RFC] Pascal language: case insensitivity! Date: Mon, 19 Jun 2000 09:12:00 -0000 Message-id: <394E467F.3DF1A1E1@smith-house.org> References: <200006191117.NAA25188@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00149.html Content-length: 487 Pierre Muller wrote: > for now, but there might be other case insensitive languages supported. > (I even don't know if Modula 2 is case sensitive or not). Modula/2 IS case-sensitive, as is Oberon, Oberon/2 and Component Pascal. -- .-. .-. .---. .---. .-..-. | "Bill Gates is just a monocle | |__ / | \| |-< | |-< > / | and a Persian Cat away from `----'`-^-'`-'`-'`-'`-' `-' | being one of the bad guys in a My opinions only. | James Bond movie." -- D Miller >From kettenis@wins.uva.nl Mon Jun 19 09:53:00 2000 From: Mark Kettenis To: muller@cerbere.u-strasbg.fr Cc: gdb@sourceware.cygnus.com Subject: Re: [RFC] Pascal language: case insensitivity! Date: Mon, 19 Jun 2000 09:53:00 -0000 Message-id: <200006191653.SAA03393@landau.wins.uva.nl> References: <200006191117.NAA25188@cerbere.u-strasbg.fr> X-SW-Source: 2000-06/msg00150.html Content-length: 891 Date: Mon, 19 Jun 2000 12:51:56 +0200 From: Pierre Muller I already talked a while ago about this and someone (can't remember who) said that there is a much simpler way to get this result. I would of course really like to know more about this possibility. It might have been me. I believe I suggested to change GDB to use the POSIX entry points regcomp() and regexec() instead of the BSD re_comp() and re_exec() functions. There is already a REG_ICASE flag that's supposed to ignore case when matching. It's just that you cannot use it with re_comp() and re_exec(). The GNU regex library is used by several GNU packages, and the master version lives in the GNU C Library. The version in GDB shouldn't diverge too much from the master version, and I'm pretty sure your patch will be rejected by the maintainer of the GNU C Library. Mark >From nsd@redhat.com Mon Jun 19 10:21:00 2000 From: Nick Duffek To: cgf@cygnus.com Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: non-blocking reads/writes and event loops Date: Mon, 19 Jun 2000 10:21:00 -0000 Message-id: <200006191721.NAA21496@nog.bosbc.com> References: <20000619112314.G14829@cygnus.com> X-SW-Source: 2000-06/msg00151.html Content-length: 803 On 19-Jun-2000, Chris Faylor wrote: >On Mon, Jun 19, 2000 at 03:01:08PM +1000, Andrew Cagney wrote: >>Consider a GDBng (GDB 6) that is trying to talk to two (or more) active >>remote targets. >I was thinking more of a process hive which communicated via shared >memory. Or via a pipe or socket, the point (for me) being that multiple processes -- one per target plus one for the user interface -- give us all the non-blocking parallelism we need. At least, I haven't yet come up with a scenario where that's not the case; has anyone else? >As far as NFS is concerned, I think that Nick was talking about the >noticeable lags that can occur when loading something like a core file >over NFS. Right. Isn't getting rid of temporary GUI freezes one of the whole points of event-loopification? Nick >From fnasser@cygnus.com Mon Jun 19 11:11:00 2000 From: Fernando Nasser To: Doug Evans Cc: gdb@sourceware.cygnus.com Subject: Re: execute_command wrapper? Date: Mon, 19 Jun 2000 11:11:00 -0000 Message-id: <394E624D.E7F09D41@cygnus.com> References: <200006191601.JAA28217@casey.transmeta.com> X-SW-Source: 2000-06/msg00152.html Content-length: 629 Doug Evans wrote: > > Would it be reasonable to add an execute_command wrapper to wrapper.c? > > I'm thinking of a situation where one has added a different scripting > language to gdb and one wants to execute a gdb command. Hi Doug, The scripting language should not try to use the CLI stuff. Please look at the MI section (new) at the GDB manual. Also, look at the gdb/mi subdirectory. Regards, Fernando -- 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 jingham@apple.com Mon Jun 19 13:21:00 2000 From: Jim Ingham To: Subject: Re: non-blocking reads/writes and event loops Date: Mon, 19 Jun 2000 13:21:00 -0000 Message-id: References: <200006162154.RAA21307@nog.bosbc.com> X-SW-Source: 2000-06/msg00153.html Content-length: 6308 on 6/16/00 2:54 PM, Nick Duffek at nsd@redhat.com wrote: > On 12-Jun-2000, Andrew Cagney wrote: > >> 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. > > On 12-Jun-2000, Jim Ingham wrote: > >> One thing to remember about this is that any blocking operation that can >> fail, particularly ones that have fairly long timeouts (or in some cases >> like the RDI code, none at all) becomes a point of fragility for any GUI >> based on top of gdb. > > [...] > >> So my vote is to eradicate ALL the blocking behavior, and make GDB a pure >> event driven application. > > Does that include file I/O? Reading a core file over NFS could freeze a > GUI for quite a while. > > If so, then we'd need to invert BFD as well. Ideally, yes we should do this. But this can be a gradual process, and I am less worried about reading core files, since this is a single atomic operation, and thus easier to protect against with timeouts, etc... > > 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.] While I have a lot of respect for these two folks, this is hardly their idea. This is the approach that most GUI interfaces to GDB have taken over the years. I am of two minds here. In many IDE type applications, there is a desire to host the debugger IN the IDE, and breaking out the debugger engine into a separate process is certainly attractive. It also does (with proviso's that I note below) help solve the problem of gdb blocking without having to do much work. On the other hand, GDB knows a lot about the application that it is debugging, and in big programs there is a LOT to know... So having an in-process gui is also attractive, since you can get very quick and direct access to all this knowledge, without having to package it into strings, and unpackage it at the other end. Doing things like presenting all the globals available to a given module, or sometimes even all the local variables, can involve a lot of data flow. Ditto for memory views, and even some crazy processors that have hundreds of registers. 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, AND the UI being out of synch with the inferior at each stage. If there is a delay in stepping, you interrupt the concentration of the user as they are trying to chase the flow of control of their program. And if data is ever out of synch (even if you try to get around this by coloring un-updated data or some such) you break the user's trust in the information being presented. Maintaining this trust is also essential to allowing the user to settle into and concentrate on the difficult problem of debugging... So I still think it is important to try to make it easy to support in-process GUI's to gdb like Insight. > > The user interface could be a GUI, a command-line interface, Emacs, etc. > Pipes are non-blocking, so a GUI need never freeze due to blocking > debugging calls. Note that even when the UI is in another process, it is really nice to have a non-blocking gdb under the hood. It makes it easier/possible to implement things like progress bars, etc. It also makes the question "Has gdb gone south, has a board gone south, or is it just waiting a long time to do something?" easier to ask & answer. Moreover, the ^C mechanism for interrupting gdb is pretty fragile as well, or at least it caused us LOTS of problems with Insight... 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. If you have ever used a debugger that supports this, I think you will agree this is REALLY useful. You can of course implement this by sending a ^C to gdb from the UI, inserting the breakpoint, and then continuing the inferior. But I think (a) it is silly for each GUI to have to implement this separately, and (b) gdb is better equipped to do this correctly than a UI which, after all, has fairly limited knowledge of the inferior. The architecture for this becomes much cleaner if gdb is live and able to respond to the client at all times. > > 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... > > 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. > > Such a library could be used by a GUI e.g. to maintain a copy of the > breakpoint list, so that it could perform the equivalent of "info > breakpoints" without blocking. 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? > > It could also be used to implement the saving of breakpoints, watchpoints, > and other state across GDB sessions. > This sort of stuff is very useful, though I would want to make sure that this library is more of a library, i.e. useable in process as well as for client apps. The MI interface is a step towards this, though it still suffers from the "distributed" nature of information gathering in gdb. But I think this is a separate issue from the blocking behavior of gdb. Jim