* [RFC] Pascal language: case insensitivity!
@ 2000-06-19 3:57 Pierre Muller
[not found] ` <200006191653.SAA03393@landau.wins.uva.nl>
0 siblings, 1 reply; 3+ messages in thread
From: Pierre Muller @ 2000-06-19 3:57 UTC (permalink / raw)
To: gdb
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 <cgf@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Nick Duffek <nsd@redhat.com>, 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 <dje@transmeta.com>
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 <larry@smith-house.org>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
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 <kettenis@wins.uva.nl>
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 <muller@cerbere.u-strasbg.fr>
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 <nsd@redhat.com>
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 <fnasser@cygnus.com>
To: Doug Evans <dje@transmeta.com>
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 <jingham@apple.com>
To: <gdb@sourceware.cygnus.com>
Subject: Re: non-blocking reads/writes and event loops
Date: Mon, 19 Jun 2000 13:21:00 -0000
Message-id: <B573AB21.14C0%jingham@apple.com>
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-06-19 15:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-19 3:57 [RFC] Pascal language: case insensitivity! Pierre Muller
[not found] ` <200006191653.SAA03393@landau.wins.uva.nl>
2000-06-19 13:25 ` muller
2000-06-19 15:34 ` Mark Kettenis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox