From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27389 invoked by alias); 8 Oct 2009 16:52:49 -0000 Received: (qmail 27380 invoked by uid 22791); 8 Oct 2009 16:52:48 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Oct 2009 16:52:43 +0000 Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id n98Gqd09008818 for ; Thu, 8 Oct 2009 17:52:40 +0100 Received: from ywh3 (ywh3.prod.google.com [10.192.8.3]) by zps19.corp.google.com with ESMTP id n98GqaD0012935 for ; Thu, 8 Oct 2009 09:52:36 -0700 Received: by ywh3 with SMTP id 3so29986ywh.22 for ; Thu, 08 Oct 2009 09:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.107.2 with SMTP id j2mr1592302anm.135.1255020755546; Thu, 08 Oct 2009 09:52:35 -0700 (PDT) In-Reply-To: <20091008162350.GA8625@caradoc.them.org> References: <20091002004954.8966C76B2B@ppluzhnikov.mtv.corp.google.com> <8ac60eac0910080916i5a2eb49an5f21f3b5c7fb96ef@mail.gmail.com> <20091008162350.GA8625@caradoc.them.org> Date: Thu, 08 Oct 2009 16:52:00 -0000 Message-ID: <8ac60eac0910080952p46f15693x6ed339473db0139d@mail.gmail.com> Subject: Re: [RFC][patch] Allow to disassemble line. From: Paul Pluzhnikov To: Paul Pluzhnikov , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true 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-10/txt/msg00174.txt.bz2 On Thu, Oct 8, 2009 at 9:23 AM, Daniel Jacobowitz wrote: > I'd mildly prefer changing the behavior of GDB - but only if we can > get an additional enhancement that I don't think we have yet: "*" at > the PC... That sounds good. I'll try to implement that. On Thu, Oct 8, 2009 at 9:24 AM, Joel Brobecker wrote: > My 2 cents: I *think* the intention of this setting was to display > the next few instructions that are about to be executed. Yes, but the context (a couple of instructions which have just executed) is often important as well. If 'set disassemble-next-line on' worked as Daniel proposed, that would significantly reduce the need for 'disas/l', I think. Thanks, -- Paul Pluzhnikov