From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18682 invoked by alias); 12 Feb 2004 22:05:44 -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 18628 invoked from network); 12 Feb 2004 22:05:43 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 12 Feb 2004 22:05:43 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i1CM5gb02147 for ; Thu, 12 Feb 2004 17:05:42 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i1CM5fM10284 for ; Thu, 12 Feb 2004 17:05:41 -0500 Received: from 192.168.1.129 (vpn50-30.rdu.redhat.com [172.16.50.30]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i1CM5dX32548; Thu, 12 Feb 2004 14:05:40 -0800 From: Fred Fish Reply-To: fnf@redhat.com To: gdb-patches@sources.redhat.com Subject: [RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present Date: Thu, 12 Feb 2004 22:05:00 -0000 User-Agent: KMail/1.5.4 Cc: fnf@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200402121505.37560.fnf@ninemoons.com> X-SW-Source: 2004-02/txt/msg00329.txt.bz2 For the following test case: sub1 () { printf ("In sub1\n"); } sub2 () { printf ("In sub2\n"); } main () { sub1 (); sub2 (); } sh-elf-gcc with -O2 will schedule the code to call sub1 into the prologue of main. If the code is compiled WITHOUT debug info, the prologue scanner in gdb will not stop when it sees the jsr and will eventually return a pc somewhere after the jsr. For example: (gdb) br main Breakpoint 1 at 0x1162 (gdb) x/8i main 0x1158
: mov.l r14,@-r15 0x115a : mov.l 0x116c ,r0 ! 0x1120 0x115c : sts.l pr,@-r15 0x115e : jsr @r0 0x1160 : mov r15,r14 * 0x1162 : mov.l 0x1170 ,r1 ! 0x113c 0x1164 : mov r14,r15 0x1166 : lds.l @r15+,pr Note that the breakpoint on main() gets set well after the jsr. When you set breakpoints at sub1 and sub2 and run the program, you get: (gdb) run Starting program: /links1/build/sourceware/gdb/T-sh-elf/gdb/g Breakpoint 2, 0x00001128 in sub1 () (gdb) c Continuing. In sub1 Breakpoint 1, 0x00001162 in main () (gdb) c Continuing. Breakpoint 3, 0x00001144 in sub2 () (gdb) c Continuing. In sub2 Program exited with code 012. which is very confusing because it appears that sub1 is called before main! With the attached patch, the prologue scanner returns the pc of the jsr instruction, allowing the breakpoint at main to be hit before the breakpoint at sub1: (gdb) br main Breakpoint 1 at 0x115e (gdb) x/8i main 0x1158
: mov.l r14,@-r15 0x115a : mov.l 0x116c ,r0 ! 0x1120 0x115c : sts.l pr,@-r15 * 0x115e : jsr @r0 0x1160 : mov r15,r14 0x1162 : mov.l 0x1170 ,r1 ! 0x113c 0x1164 : mov r14,r15 0x1166 : lds.l @r15+,pr (gdb) br sub1 Breakpoint 2 at 0x1128 (gdb) br sub2 Breakpoint 3 at 0x1144 (gdb) run Starting program: /links1/build/sourceware/gdb/T-sh-elf/gdb/g Breakpoint 1, 0x0000115e in main () (gdb) c Continuing. Breakpoint 2, 0x00001128 in sub1 () (gdb) c Continuing. In sub1 Breakpoint 3, 0x00001144 in sub2 () (gdb) c Continuing. In sub2 Program exited with code 012. It's also useful to note where the breakpoint gets set if you recompile to generate debugging information: (gdb) br main Breakpoint 1 at 0x115a: file g.c, line 13. (gdb) x/8i main 0x1158
: mov.l r14,@-r15 0x115a : mov.l 0x116c ,r0 ! 0x1120 0x115c : sts.l pr,@-r15 0x115e : jsr @r0 0x1160 : mov r15,r14 0x1162 : mov.l 0x1170 ,r1 ! 0x113c 0x1164 : mov r14,r15 0x1166 : lds.l @r15+,pr This patch causes no regressions in the gdb testsuite. Anyone see any issues with installing it? :-) -Fred 2004-02-12 Fred Fish * sh-tdep.c (IS_JSR): New macro. (sh_analyze_prologue): Use IS_JSR to terminate prologue scan. Index: sh-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/sh-tdep.c,v retrieving revision 1.158 diff -c -p -r1.158 sh-tdep.c *** sh-tdep.c 11 Feb 2004 15:40:28 -0000 1.158 --- sh-tdep.c 12 Feb 2004 21:16:39 -0000 *************** sh_breakpoint_from_pc (CORE_ADDR *pcptr, *** 333,338 **** --- 333,341 ---- #define GET_SOURCE_REG(x) (((x) >> 4) & 0xf) #define GET_TARGET_REG(x) (((x) >> 8) & 0xf) + /* JSR @Rm 0100mmmm00001011 */ + #define IS_JSR(x) (((x) & 0xf0ff) == 0x400b) + /* STS.L PR,@-r15 0100111100100010 r15-4-->r15, PR-->(r15) */ #define IS_STS(x) ((x) == 0x4f22) *************** sh_analyze_prologue (CORE_ADDR pc, CORE_ *** 530,535 **** --- 533,552 ---- else break; } + break; + } + else if (IS_JSR (inst)) + { + /* We have found a jsr that has been scheduled into the prologue. + If we continue the scan and return a pc someplace after this, + then setting a breakpoint on this function will cause it to + appear to be called after the function it is calling via the + jsr, which will be very confusing. Most likely the next + instruction is going to be IS_MOV_SP_FP in the delay slot. If + so, note that before returning the current pc. */ + inst = read_memory_integer (pc + 2, 2); + if (IS_MOV_SP_FP (inst)) + cache->uses_fp = 1; break; } #if 0 /* This used to just stop when it found an instruction that