From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6055 invoked by alias); 29 Sep 2009 03:23:28 -0000 Received: (qmail 6046 invoked by uid 22791); 29 Sep 2009 03:23:28 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-yw0-f201.google.com (HELO mail-yw0-f201.google.com) (209.85.211.201) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 03:23:24 +0000 Received: by ywh39 with SMTP id 39so5717095ywh.12 for ; Mon, 28 Sep 2009 20:23:22 -0700 (PDT) Received: by 10.151.16.2 with SMTP id t2mr9185617ybi.176.1254194602475; Mon, 28 Sep 2009 20:23:22 -0700 (PDT) Received: from xpjpn (pool-71-111-147-240.ptldor.dsl-w.verizon.net [71.111.147.240]) by mx.google.com with ESMTPS id 15sm1970802gxk.12.2009.09.28.20.23.20 (version=SSLv3 cipher=RC4-MD5); Mon, 28 Sep 2009 20:23:21 -0700 (PDT) From: Caz Yokoyama To: "'Joel Brobecker'" Cc: "'Pedro Alves'" , References: <200905152223.58241.pedro@codesourcery.com> <20090515213410.GA10064@caradoc.them.org> <8AA4B846934A4A9081F778449B96F416@xpjpn> <4A0DE914.1050800@vmware.com> <20090923004802.GA20859@adacore.com> <9ECED0F0DCF04CC185B027503876430D@xpjpn> <20090925160627.GB5077@adacore.com> <66E35EA6599040F894D040E4F50389D0@xpjpn> <535d47e30909260627n662135a1hf6d1a0bb33368b3a@mail.gmail.com> <20090929015830.GJ9003@adacore.com> Subject: RE: symbolic debug of loadable modules with kgdb light Date: Tue, 29 Sep 2009 03:23:00 -0000 Message-ID: <1724490614004CEB9EE1A091A151E05B@xpjpn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20090929015830.GJ9003@adacore.com> 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: 2009-09/txt/msg00904.txt.bz2 Hello Joel, I understand 1) You don't want to introduce dependency of the target into gdb 2) You want to check whether the user enters correct setting to interrupt_sequence. In case of debugging user space program, interrupt_sequence is always ^C. However, when we debug kernel, interrupt_sequence is varied from kernel to kernel. It means interrupt_sequence depends on each kernel. To check correctness of interrupt_sequence, we have to know which kernel we are debugging. It introduces dependency of kernel. As the result, it is impossible to satisfy both 1) and 2). I give up. Thank you for reviewing my patches. -caz -----Original Message----- From: Joel Brobecker [mailto:brobecker@adacore.com] Sent: Monday, September 28, 2009 6:59 PM To: caz yokoyama Cc: Pedro Alves; gdb-patches@sourceware.org Subject: Re: symbolic debug of loadable modules with kgdb light > > I revised my patch. As I wrote in ChangeLog, I expanded interrupt_sequence > > to arbitrary characters include ^C and BREAK instead of 3 choices. Actually, I'm sorry, but I don't agree with this change. I don't think it's providing much in terms of user experience and your implementation has many downsides: The command hander no longer verifies that the user enters valid values (the user finds this out later when connecting to the target or possibly only when requesting an interrupt; either way, it's too late), you lose tab-completion, and your implementation of send_interrupt_sequence becomes unecessarily complex and inefficient as a result. > -static int remote_break; > +static int remote_break = 0; > + > +static void > +set_remote_break (char *args, int from_tty, struct cmd_list_element *c) > +{ > + if (strcmp (interrupt_sequence, CTRL_C) == 0) > + { > + interrupt_sequence = xmalloc (sizeof(BREAK) + 1); > + strcpy (interrupt_sequence, BREAK); > + remote_break = 1; > + } > + else > + { > + interrupt_sequence = xmalloc (sizeof(CTRL_C) + 1); > + strcpy (interrupt_sequence, CTRL_C); > + remote_break = 0; > + } > +} What we are trying to achieve, here, is make things work for a user that was used to using "set remotebreak" while yet telling him which command should now be used instead. In other words, "set remotebreak on" should act as if the user entered "set remote interrupt-sequence BREAK" and "set remotebreak off" should act as if the user entered "set remote interrupt-sequence control-c". The code itself should *ignore* the boolean that set/show remotebreak use internally, and use the "enum" that "set remote interrupt-sequence" uses instead. Calling deprecate_cmd on the cmd_list_element structs associcated to the set/show remotebreak commands will make sure that the user is informed which commands are replacing these commands, and allows us to remove them eventually, once users have had a chance to transition to the new ones. -- Joel