From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32434 invoked by alias); 23 May 2005 15:37:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32382 invoked by uid 22791); 23 May 2005 15:36:55 -0000 Received: from fra-del-02.spheriq.net (HELO fra-del-02.spheriq.net) (195.46.51.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 23 May 2005 15:36:55 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-02.spheriq.net with ESMTP id j4NFarCu019484 for ; Mon, 23 May 2005 15:36:53 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id j4NFaaK1029172 for ; Mon, 23 May 2005 15:36:36 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id j4NFalbR016414 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 23 May 2005 15:36:50 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 010FBDA42 for ; Mon, 23 May 2005 15:36:46 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 35EB04759C; Mon, 23 May 2005 15:38:22 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 31F59759BF for ; Mon, 23 May 2005 15:38:22 +0000 (UTC) Received: from mail2.gnb.st.com (mail2.gnb.st.com [164.129.119.59]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 2E46447599 for ; Mon, 23 May 2005 15:38:16 +0000 (GMT) Received: from st.com (pcx0003.gnb.st.com [164.129.118.67]) by mail2.gnb.st.com (MOS 3.4.4-GR) with ESMTP id BGT02882 (AUTH lyon); Mon, 23 May 2005 17:36:37 +0200 (CEST) Message-ID: <4291F882.BC2F3699@st.com> Date: Mon, 23 May 2005 15:37:00 -0000 From: Christophe LYON MIME-Version: 1.0 To: gdb@sourceware.org Subject: Handling the 'next' command on a variable-length bundles target Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 2.2.1 X-SW-Source: 2005-05/txt/msg00283.txt.bz2 Hi all, I am working on a port of GDB on a processor which used variable-length bundles, that is one bundle is composed of a set of several instructions, the number of which is variable inside a bundle. Breakpoints can only be set on bundles boundaries. I am facing an issue with the 'next' command with optimised code. Consider a sample code which contains: int testcall2 (void) { int a, b, c, d, e, f, w, x, y, z; a = testcall(); b = testcall(); c = testcall(); d = testcall(); e = testcall(); f = testcall(); w = testcall(); x = testcall(); y = testcall(); z = testcall(); return a + b + c + d + e + f + w + x + y + z; } The generated code for the beginning of the function looks like this: testcall2: *bundle start* adjust SP save return address call testcall *bundle stop* *bundle start* store result into a call testcall *bundle stop* etc... When I set a breakpoint in testcall2 with "break testcall2", the breakpoint is inserted at the testcall2 label. Indeed, it is not possible to skip the function prologue and also set the breakpoint before calling testcall Then, if I use the 'next' command, GDB actually performs a 'stepi', and discovers it is now in testcall. As a result, it decides to compute the return address, set a breakpoint to it and resume execution. All of this works :-) When the breakpoint on the return address fires, GDB compares the frame address in order to handle the case of a recursive function call. In my case, as SP has been modified during the 'next' command, GDB thinks it has entered a recursive function and decides to continue.... until the end of the program. I would like to have your inputs on possible clean ways of handling this. I am considering modyfing the way 'next' and 'stepi' memorize the frame in this specific case, but this is far from being generic. Maybe it is too specific to think of a generic fix, but maybe some of you have similar features? Thanks for any input, Christophe.