From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24943 invoked by alias); 8 Oct 2009 17:16:48 -0000 Received: (qmail 24934 invoked by uid 22791); 8 Oct 2009 17:16:47 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,BOTNET,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Oct 2009 17:16:41 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KR700D00H746800@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Thu, 08 Oct 2009 19:15:56 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.70.84.229]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KR7002U6HAJ7OC0@i-mtaout1.012.net.il>; Thu, 08 Oct 2009 19:15:56 +0200 (IST) Date: Thu, 08 Oct 2009 17:16:00 -0000 From: Eli Zaretskii Subject: Re: [RFC][patch] Allow to disassemble line. In-reply-to: <20091008162445.GC11440@adacore.com> To: Joel Brobecker Cc: ppluzhnikov@google.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pr8xlsff.fsf@gnu.org> References: <20091002004954.8966C76B2B@ppluzhnikov.mtv.corp.google.com> <8ac60eac0910080916i5a2eb49an5f21f3b5c7fb96ef@mail.gmail.com> <20091008162445.GC11440@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-10/txt/msg00175.txt.bz2 > Date: Thu, 8 Oct 2009 09:24:45 -0700 > From: Joel Brobecker > Cc: gdb-patches@sourceware.org > > > Does anybody have an opinion on whether the implementation should be > > changed to match the manual, or vice versa? > > My 2 cents: I *think* the intention of this setting was to display > the next few instructions that are about to be executed. That's the way > I personally would like this feature to work as I'd be able to identify > immediately which instruction is next. So my vote goes towards updating > the manual to match the current implementation. If the current implementation is what we want (and I personally don't have an opinion either way), then I don't think the subtle difference is important enough to update the manual. The described behavior is what most users will see almost all the time; accurately describing the subtlety of this when you crash will most probably be so confusing that it is not worth doing.