Re: [PATCH v2 02/13] script language API for GDB: extension.[ch]

[ludo at gnu dot org (Ludovic CourtÃs)]

Doug Evans <xdje42@gmail.com> skribis:

> On Mon, Dec 23, 2013 at 1:57 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Doug" == Doug Evans <xdje42@gmail.com> writes:
>>
>> Doug> +void
>> Doug> +clear_quit_flag (void)
>> Doug> +{
>> Doug> +  int i;
>> Doug> +  const struct extension_language_defn *extlang;
>> Doug> +
>> Doug> +  ALL_ENABLED_EXTENSION_LANGUAGES (i, extlang)
>> Doug> +    {
>> Doug> +      if (extlang->ops->clear_quit_flag != NULL)
>> Doug> + extlang->ops->clear_quit_flag (extlang);
>> Doug> +    }
>> Doug> +
>> Doug> +  quit_flag = 0;
>> Doug> +}
>>
>> I don't think this will work properly.  It seems to me that a given
>> interrupt may be processed multiple times -- once by each extension
>> language.
>
> Guile doesn't provide the same hooks that Python does for SIGINT
> (PyErr_SetInterrupt, et.al.) so I expect this part to need some work.
>
>> The way it works right now, if Python handles the "quit", then Python
>> clears the flag -- which also clears gdb's notion of the flag, because
>> the two are identical.
>>
>> With the above it seems that Python could clear its flag -- but leave
>> other extension languages unaware that the interrupt was handled.  So, a
>> subsequent call into Guile will presumably erroneously throw an
>> exception.
>
> We carefully manage entry and exit to/from extension languages.
> It should be possible to manage SIGINT across these boundaries.
> v3 coming up, but I'm leaving this part to v4.

Iâm not sure I understand the problem.

What part of the code calls signal(2) or sigaction(2) in the end?  There
can only be one SIGINT handler in the process anyway, so I guess it
has to be installed by GDB (the extension-language-independent part), no?

What are extension languages typically expected to do when the âquitâ
flag is set?

(And happy new year, where applicable! ;-))

Ludoâ.