From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17424 invoked by alias); 18 Oct 2012 02:52:21 -0000 Received: (qmail 17416 invoked by uid 22791); 18 Oct 2012 02:52:20 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Oct 2012 02:52:15 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1TOgDW-0000qn-9z from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Wed, 17 Oct 2012 19:52:14 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Oct 2012 19:52:13 -0700 Received: from qiyao.dyndns.org.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Wed, 17 Oct 2012 19:52:13 -0700 From: Yao Qi To: Subject: [RFC] Handle prologue on atom. Date: Thu, 18 Oct 2012 02:52:00 -0000 Message-ID: <1350528745-5887-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain 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: 2012-10/txt/msg00311.txt.bz2 Hi, I am looking at gdb testsuite fails when test cases are compiled with -march=atom. They are caused by gdb is unable to recognize prologue. Usually, the i386 prologue looks like push %ebp mov %esp,%ebp sub $0x10,%esp and gdb can skip it correctly. However, in my test , gcc (based on 4.7.2, with flag -march=atom) generates prologue that gdb doesn't understand, $ ./install/bin/i686-pc-linux-gnu-gcc -g -march=atom gdb/testsuite/gdb.base/cursal.c -o cursal $ ./install/bin/i686-pc-linux-gnu-gdb ./cursal (gdb) disassemble /r main Dump of assembler code for function main: 0x0804841b <+0>: 55 push %ebp 0x0804841c <+1>: 8d 2c 24 lea (%esp),%ebp 0x0804841f <+4>: 8d 64 24 f0 lea -0x10(%esp),%esp 0x08048423 <+8>: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp) 0x0804842a <+15>: e8 e2 ff ff ff call 0x8048411 0x0804842f <+20>: c9 leave 0x08048430 <+21>: c3 ret Looks gcc prefers lea for add/sub operation, probably done by this gcc patch, PATCH: Add Intel Atom optimization http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01722.html In "12.3.2.2 Address Generation" of "Intel 64 and IA-32 Architectures Optimization Reference Manual", there are some description on using LEA. This patch teaches gdb to understand prologue for atom, and it fixes many testsuite fails. Regression tested on host i686-pc-linux-gnu with different compilation options to test cases (default/m64/-march=atom). OK to apply? gdb: 2012-10-18 Yao Qi * i386-tdep.c (i386_analyze_frame_setup): Handle opcode 0x8d (lea). --- gdb/i386-tdep.c | 38 +++++++++++++++++++++++++++++++++++--- 1 files changed, 35 insertions(+), 3 deletions(-) diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c index 84e9794..27e00d9 100644 --- a/gdb/i386-tdep.c +++ b/gdb/i386-tdep.c @@ -1388,18 +1388,40 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch, if (target_read_memory (pc + skip, &op, 1)) return pc + skip; - /* Check for `movl %esp, %ebp' -- can be written in two ways. */ + /* The i386 prologue looks like + + push %ebp + mov %esp,%ebp + sub $0x10,%esp + + and a different prologue can be generated for atom. + + push %ebp + lea (%esp),%ebp + lea -0x10(%esp),%esp + + We handle both of them here. */ + switch (op) { + /* Check for `movl %esp, %ebp' -- can be written in two ways. */ case 0x8b: if (read_memory_unsigned_integer (pc + skip + 1, 1, byte_order) != 0xec) return pc; + pc += (skip + 2); break; case 0x89: if (read_memory_unsigned_integer (pc + skip + 1, 1, byte_order) != 0xe5) return pc; + pc += (skip + 2); + break; + case 0x8d: /* Check for 'lea (%ebp), %ebp'. */ + if (read_memory_unsigned_integer (pc + skip + 1, 2, byte_order) + != 0x242c) + return pc; + pc += (skip + 3); break; default: return pc; @@ -1410,7 +1432,6 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch, necessary. We also now commit to skipping the special instructions mentioned before. */ cache->locals = 0; - pc += (skip + 2); /* If that's all, return now. */ if (limit <= pc) @@ -1419,6 +1440,8 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch, /* Check for stack adjustment subl $XXX, %esp + or + lea -XXX(%esp),%esp NOTE: You can't subtract a 16-bit immediate from a 32-bit reg, so we don't have to worry about a data16 prefix. */ @@ -1447,9 +1470,18 @@ i386_analyze_frame_setup (struct gdbarch *gdbarch, cache->locals = read_memory_integer (pc + 2, 4, byte_order); return pc + 6; } + else if (op == 0x8d) + { + /* The ModR/M byte is 0x64. */ + if (read_memory_unsigned_integer (pc + 1, 1, byte_order) != 0x64) + return pc; + /* 'lea' with 8-bit displacement. */ + cache->locals = -1 * read_memory_integer (pc + 3, 1, byte_order); + return pc + 4; + } else { - /* Some instruction other than `subl'. */ + /* Some instruction other than `subl' nor 'lea'. */ return pc; } } -- 1.7.7.6