From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10475 invoked by alias); 2 Dec 2016 08:40:47 -0000 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 Received: (qmail 10014 invoked by uid 89); 2 Dec 2016 08:40:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:HELO, Hx-spam-relays-external:HELO, Deutschland, deutschland X-HELO: mga05.intel.com Received: from mga05.intel.com (HELO mga05.intel.com) (192.55.52.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 08:40:27 +0000 Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga105.fm.intel.com with ESMTP; 02 Dec 2016 00:40:25 -0800 X-ExtLoop1: 1 Received: from heckel-mobl3.ger.corp.intel.com (HELO [172.28.205.41]) ([172.28.205.41]) by fmsmga004.fm.intel.com with ESMTP; 02 Dec 2016 00:40:06 -0800 Subject: Re: [PATCH] AMD64, Prologue: Recognize stack decrementation as prologue operation. To: Luis Machado , qiyaoltc@gmail.com References: <1480601804-3128-1-git-send-email-bernhard.heckel@intel.com> <2b71dfb7-0ab8-2440-b102-e8cc6dfc8bef@codesourcery.com> Cc: gdb-patches@sourceware.org From: Bernhard Heckel Message-ID: <58413365.50701@intel.com> Date: Fri, 02 Dec 2016 08:40:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2b71dfb7-0ab8-2440-b102-e8cc6dfc8bef@codesourcery.com> Content-Type: multipart/mixed; boundary="------------050108060308020009000101" X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00069.txt.bz2 This is a multi-part message in MIME format. --------------050108060308020009000101 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable Content-length: 4365 On 01/12/2016 16:31, Luis Machado wrote: > On 12/01/2016 08:16 AM, Bernhard Heckel wrote: >> Some compiler decrement stack pointer within the prologue >> sequence in order to reserve memory for local variables. >> Recognize this subtraction to stop at the very end of the >> prologue. > > I suppose this was exercised with GCC as well via the testsuite? Yes GCC,ICC and Clang 6.0 (llvm 3.5) No regression with GCC nor with ICC. But, there is a major issue when running with Clang. Clang associate this "subtraction instruction" with the line after the=20 prologue sequence. This causes regressions on Mac. I attached disassembly of Clang and GCC for the same program. ICC=20 behaves like GCC. I was trying to file a ticket for Clang, but I don't have access to=20 bugzilla. Auto-registration is not available and manual account registration is still ongoing. > >> >> 2016-10-20 Bernhard Heckel >> >> gdb/Changelog: >> amd64-tdep.c (amd64_analyze_prologue): Recognize stack=20 >> decrementation >> as prologue operation. > > gdb/ChangeLog above the date line, adjust date and add "*" before the=20 > filename. > >> >> --- >> gdb/amd64-tdep.c | 30 ++++++++++++++++++++++++++++++ >> 1 file changed, 30 insertions(+) >> >> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c >> index a3a1fde..795d78e 100644 >> --- a/gdb/amd64-tdep.c >> +++ b/gdb/amd64-tdep.c >> @@ -2283,6 +2283,12 @@ amd64_analyze_prologue (struct gdbarch *gdbarch, >> /* Ditto for movl %esp, %ebp. */ >> static const gdb_byte mov_esp_ebp_1[2] =3D { 0x89, 0xe5 }; >> static const gdb_byte mov_esp_ebp_2[2] =3D { 0x8b, 0xec }; >> + /* Ditto for subtraction on the stack pointer. */ >> + static const gdb_byte sub_rsp_imm8[3] =3D { 0x48, 0x83, 0xec }; >> + static const gdb_byte sub_rsp_imm32[3] =3D { 0x48, 0x81, 0xec }; >> + /* Ditto for subtraction on the stack pointer. */ >> + static const gdb_byte sub_esp_imm8[2] =3D { 0x83, 0xec }; >> + static const gdb_byte sub_esp_imm32[2] =3D { 0x81, 0xec }; > > Should we add a comment making it explicit which instruction patterns=20 > we're looking at matching here? You mean, adding it to the function description. There we have=20 description for push and mov instruction. > > I looked up sub esp imm32, for example, and i got no meaningful hits=20 > other than some nasm posix entry. > >> >> gdb_byte buf[3]; >> gdb_byte op; >> @@ -2316,6 +2322,18 @@ amd64_analyze_prologue (struct gdbarch *gdbarch, >> { >> /* OK, we actually have a frame. */ >> cache->frameless_p =3D 0; >> + >> + /* Some compiler do subtraction on the stack pointer >> + to reserve memory for local variables. >> + Two common variants exist to do so. */ > > What compiler exactly? Would be nice to know, otherwise this is a bit=20 > vague. Actually, GCC, ICC and Clang are using this approach. > > The comment seems to imply a specific compiler does this, or did you=20 > mean "some compilers"? > >> + read_code (pc + 4, buf, 3); >> + if (memcmp (buf, sub_rsp_imm8, 3) =3D=3D 0) >> + /* Operand is 1 byte. */ >> + return pc + 8; >> + else if (memcmp (buf, sub_rsp_imm32, 3) =3D=3D 0) >> + /* Operand is 4 bytes. */ >> + return pc + 11; >> + >> return pc + 4; >> } >> >> @@ -2327,6 +2345,18 @@ amd64_analyze_prologue (struct gdbarch *gdbarch, >> { >> /* OK, we actually have a frame. */ >> cache->frameless_p =3D 0; >> + >> + /* Some compiler do subtraction on the stack pointer >> + to reserve memory for local variables. >> + Two common variants exist to do so. */ >> + read_code (pc + 3, buf, 2); >> + if (memcmp (buf, sub_esp_imm8, 2) =3D=3D 0) >> + /* Operand is 1 byte. */ >> + return pc + 6; >> + else if (memcmp (buf, sub_esp_imm32, 2) =3D=3D 0) >> + /* Operand is 4 bytes. */ >> + return pc + 9; >> + >> return pc + 3; >> } >> } >> > > Otherwise LGTM. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 --------------050108060308020009000101 Content-Type: text/plain; charset=UTF-8; name="disassembly_clang.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="disassembly_clang.txt" Content-length: 496 disas /m caller1 9 { 0x0000000100000f60 <+0>: push %rbp 0x0000000100000f61 <+1>: mov %rsp,%rbp 10 int i = 1; 0x0000000100000f64 <+4>: sub $0x10,%rsp 0x0000000100000f68 <+8>: movl $0x1,-0x4(%rbp) 11 int b = 2; 0x0000000100000f6f <+15>: movl $0x2,-0x8(%rbp) 12 caller2(); 0x0000000100000f76 <+22>: callq 0x100000f50 13 } 0x0000000100000f7b <+27>: add $0x10,%rsp 0x0000000100000f7f <+31>: pop %rbp 0x0000000100000f80 <+32>: retq --------------050108060308020009000101 Content-Type: text/plain; charset=UTF-8; name="disassembly_gcc.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="disassembly_gcc.txt" Content-length: 443 disas /m caller1 9 { 0x00000000004004fd <+0>: push %rbp 0x00000000004004fe <+1>: mov %rsp,%rbp 0x0000000000400501 <+4>: sub $0x10,%rsp 10 int i = 1; 0x0000000000400505 <+8>: movl $0x1,-0x4(%rbp) 11 int b = 2; 0x000000000040050c <+15>: movl $0x2,-0x8(%rbp) 12 caller2(); 0x0000000000400513 <+22>: callq 0x4004f0 13 } 0x0000000000400518 <+27>: leaveq 0x0000000000400519 <+28>: retq --------------050108060308020009000101 Content-Type: text/plain; charset=UTF-8; name="test.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.c" Content-length: 131 void caller2 (void) { int i = 1; } void caller1 (void) { int i = 1; int b = 2; caller2(); } int main () { caller1(); } --------------050108060308020009000101--