From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20338 invoked by alias); 30 Jun 2009 16:11:26 -0000 Received: (qmail 20328 invoked by uid 22791); 30 Jun 2009 16:11:25 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Jun 2009 16:11:18 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5UGBHxR029001 for ; Tue, 30 Jun 2009 12:11:17 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5UGBGu3009839; Tue, 30 Jun 2009 12:11:16 -0400 Received: from opsy.redhat.com (vpn-225-39.phx2.redhat.com [10.3.225.39]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5UGBFbE016720; Tue, 30 Jun 2009 12:11:15 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id D77ECC88051; Tue, 30 Jun 2009 10:11:14 -0600 (MDT) To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [FYI] Inlining support, rough patch References: <20080715192020.GB3094@caradoc.them.org> <200807172353.m6HNr1nY015884@brahms.sibelius.xs4all.nl> <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> <20090420155405.GA6072@host0.dyn.jankratochvil.net> <20090627180122.GA6139@caradoc.them.org> <20090628101621.GA31457@host0.dyn.jankratochvil.net> From: Tom Tromey Reply-To: tromey@redhat.com Date: Tue, 30 Jun 2009 16:11:00 -0000 In-Reply-To: <20090628101621.GA31457@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Sun\, 28 Jun 2009 12\:16\:21 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-06/txt/msg00875.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> ### Whether this or that case is shown is also dependent on the current Jan> ### architecture - currently the behavior differs depending of whether there Jan> ### is at least one instruction of the same source line after the call Jan> ### instruction. Next `step' will have to do _nothing_ to the inferior, just Jan> ### display the next line in GDB. This is interesting. Alexandre Oliva has talked about something similar -- a dwarf extension which would let gdb users "step" through a sequence of source statements, even when the compiler has optimized them away. The idea would be to emit debug info describing the variables virtually, and this "step" would simply advance through the debuginfo without updating the PC. (I'm not really doing this justice, but I can't find Alexandre's note to the gcc list atm.) About your proposal: IIUC, it is trying a bit to hide more of the underlying reality from the user. Can it really work in all cases? I'm wondering about things like multiple levels of inlining (you may need several do-nothing steps?); multiple levels of inlining where the user wants to "finish" out of each one (you may need a do-nothing finish as well?); or inlining that results in a tail-call optimization being applied (there's no good spot to return to). Does any of this make sense? I can't tell if I actually understand :-) Tom