From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30244 invoked by alias); 16 Mar 2004 15:42:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30213 invoked from network); 16 Mar 2004 15:42:33 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 16 Mar 2004 15:42:33 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2GFgV8u013780 for ; Tue, 16 Mar 2004 16:42:31 +0100 Message-ID: <40572066.2020304@axis.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Next over function and breakpoint setting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00352.txt.bz2 Out of curiosity I followed what happens when issuing a next command over a function call. The reason I got curious was that I noticed (remote protocol) that GDB sets a breakpoint on the first instruction of the function being stepped over, and, when stopped there, sets another breakpoint at that function's return address to accomplish the "next". Actually, maybe that's a misrepresentation: looking at the code, it seems GDB does a step, and if it *then* finds it ended up inside a function (step_into_function -> step_over_function) it decides to step out of it. Looking at the code in infcmd.c and infrun.c I'm sure there's a good reason for not just setting the breakpoint on the address belonging to the next line of code, but I couldn't find any comment saying what that reason is. Anyone care to enlighten me? (I couldn't say if any of this was remote target/CRIS specific; apologies if it is and I missed it.) -- Orjan Friberg Axis Communications From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30244 invoked by alias); 16 Mar 2004 15:42:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30213 invoked from network); 16 Mar 2004 15:42:33 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 16 Mar 2004 15:42:33 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2GFgV8u013780 for ; Tue, 16 Mar 2004 16:42:31 +0100 Message-ID: <40572066.2020304@axis.com> Date: Tue, 16 Mar 2004 15:42:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: Next over function and breakpoint setting Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00352.txt Message-ID: <20040316154200.QxzJm2Ko6OSnrdmLZhdKIme4EdEvkik2nMgH94D-tyA@z> Out of curiosity I followed what happens when issuing a next command over a function call. The reason I got curious was that I noticed (remote protocol) that GDB sets a breakpoint on the first instruction of the function being stepped over, and, when stopped there, sets another breakpoint at that function's return address to accomplish the "next". Actually, maybe that's a misrepresentation: looking at the code, it seems GDB does a step, and if it *then* finds it ended up inside a function (step_into_function -> step_over_function) it decides to step out of it. Looking at the code in infcmd.c and infrun.c I'm sure there's a good reason for not just setting the breakpoint on the address belonging to the next line of code, but I couldn't find any comment saying what that reason is. Anyone care to enlighten me? (I couldn't say if any of this was remote target/CRIS specific; apologies if it is and I missed it.) -- Orjan Friberg Axis Communications