From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9820 invoked by alias); 2 Oct 2009 18:31:25 -0000 Received: (qmail 9811 invoked by uid 22791); 2 Oct 2009 18:31:25 -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.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Oct 2009 18:31:21 +0000 Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n92IVIq0007203 for ; Fri, 2 Oct 2009 11:31:18 -0700 Received: from ywh16 (ywh16.prod.google.com [10.192.8.16]) by zps18.corp.google.com with ESMTP id n92IVFo1016510 for ; Fri, 2 Oct 2009 11:31:16 -0700 Received: by ywh16 with SMTP id 16so661559ywh.13 for ; Fri, 02 Oct 2009 11:31:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.107.2 with SMTP id j2mr3145843anm.135.1254508275792; Fri, 02 Oct 2009 11:31:15 -0700 (PDT) In-Reply-To: <20091002065226.GW10338@adacore.com> References: <20091002004954.8966C76B2B@ppluzhnikov.mtv.corp.google.com> <20091002065226.GW10338@adacore.com> Date: Fri, 02 Oct 2009 18:31:00 -0000 Message-ID: <8ac60eac0910021131j71b1f79t5d908195652dc7e1@mail.gmail.com> Subject: Re: [RFC][patch] Allow to disassemble line. From: Paul Pluzhnikov To: Joel Brobecker Cc: 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/msg00064.txt.bz2 On Thu, Oct 1, 2009 at 11:52 PM, Joel Brobecker wrote: >> Attached patch makes it so 'disas/l' will disassemble current line, and >> 'disas/l foo.c:22' will disassemble line 22 of foo.c > > Without looking at the implementation itself for now, I have to say that > I have been missing this feature very badly. > > Questions: > > 1. What should we do if there are more than one match for the given SAL? I only ever needed this feature while single-stepping through the code (i.e. this line crashes, but why?). Perhaps it is reasonable to get rid of the parameter, and just say that 'disas/l' always disassembles current line, thus eliminating the ambiguity. Alternatively, if there are two code segments matching 'foo.c:22', but one of them is inlined into the current function and the other is inlined somewhere else, then clearly the user is interested in the "current" one (same for templates). > 2. A little trickier: How do we want to handle the case where a line > of code is split in more than one block of instructions. This happens > really often when debugging optimized code. > > Right now, the easy solution is to only disassemble the first > block. It'd be nice to have them all, though. Perhaps printing > the instructions for each block one after the other, with something > like a little sign in between indicating the next instruction is > part of another block? > > 0x... bla bla bla > 0x... bla bla bla > [...] > 0x... bla bla bla Some alternatives: A) determine min(low), max(high) core address for all SALs, then disassemble that entire range, but there are discontinuous source lines turn on DISASSEMBLY_SOURCE automatically, so it becomes clear which instructions come from which line(s). The trouble with this approach is that the two blocks could be quite far apart. I haven't see GCC do that, but under MSVC I've seen wildly discontinuous blocks of code. I think GCC may soon start doing hot/cold code splitting as well, especially with FDO. B) disassemble only the SAL which "covers" current $pc (as that's likely what the user is looking for). This would be consistent with proposed elimination of parameter, so 'disas/l' always implies 'current $pc'. -- Paul Pluzhnikov