Re: RFC: implement "catch signal"

["André Pönitz" <andre.poenitz@mathematik.tu-chemnitz.de>]

On Mon, Dec 03, 2012 at 12:39:30PM -0700, Tom Tromey wrote:
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> That MI output is now:
> 
> Jan> body=[bkpt={number="1",type="catchpoint",disp="keep",enabled="y",what=[signal="SIGINT",signal="SIGTRAP"],times="0"}]
> 
> Jan> vs. for example existing:
> 
> Jan> body=[bkpt={number="3",type="catchpoint",disp="keep",enabled="y",what="<any
> syscall> ",times="0"}]
> 
> Jan> but maybe it is OK this way, MI parsing has never been easy.
> 
> Yes, I think it is clearly better this way: we use MI constructs for
> representing lists and such.
> 
> The "type" of the "what" field is now a bit variable.
> That is, it can either be a list or a string, depending on the signal
> catchpoint.

As a more general remark from a MI consumer's perspective: It's nicer to not
change existing fields, but instead add new ones.

I understand that changing values is formally covered by the "guarantees" in
sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Development-and-Front-Ends.html,
as this is covered by "The range of values for fields with specified values
[...] may be extended" but I would like to think that the basic idea behind
writing those rules was to not break consumers of existing MI output when
extending that output. A preference of adding new fields over changing
contents (or even "type" of existing fields) should increase the chance
that frontends don't break, and can adjust to the change at their own pace.

Andre'