From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27338 invoked by alias); 3 Dec 2012 20:22:48 -0000 Received: (qmail 27327 invoked by uid 22791); 3 Dec 2012 20:22:45 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,KHOP_THREADED,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cora.hrz.tu-chemnitz.de (HELO cora.hrz.tu-chemnitz.de) (134.109.228.40) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 20:22:38 +0000 Received: from 91-66-50-232-dynip.superkabel.de ([91.66.50.232] helo=localhost) by cora.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1TfcXD-0006Jd-Dc; Mon, 03 Dec 2012 21:22:35 +0100 Date: Mon, 03 Dec 2012 20:22:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Tom Tromey Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: RFC: implement "catch signal" Message-ID: <20121203202233.GA23933@klara.mpi.htwm.de> References: <874nkpv03j.fsf@fleche.redhat.com> <20121202093807.GA21883@host2.jankratochvil.net> <87y5hfvu5v.fsf@fleche.redhat.com> <20121203193713.GA10256@host2.jankratochvil.net> <87obibvsb1.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87obibvsb1.fsf@fleche.redhat.com> X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1354566155-00000CD1-F7F347DB/0-0/0-0 X-Scan-AV: cora.hrz.tu-chemnitz.de;2012-12-03 21:22:35;05ef6d146a8a4684f82ea9392821bb18 X-Scan-SA: cora.hrz.tu-chemnitz.de;2012-12-03 21:22:35;cfd1b4636bfd1d9eec8ed642423669c6 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00041.txt.bz2 On Mon, Dec 03, 2012 at 12:39:30PM -0700, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil 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=" 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'