Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <lgustavo@codesourcery.com>
To: Bernhard Heckel <bernhard.heckel@intel.com>, <qiyaoltc@gmail.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] AMD64, Prologue: Recognize stack decrementation as prologue operation.
Date: Fri, 02 Dec 2016 15:19:00 -0000	[thread overview]
Message-ID: <26ac700b-0a50-e136-8e4f-99e19d64548e@codesourcery.com> (raw)
In-Reply-To: <58413365.50701@intel.com>

On 12/02/2016 02:40 AM, Bernhard Heckel wrote:
> 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
> prologue sequence.
> This causes regressions on Mac.
>
> I attached disassembly of Clang and GCC for the same program. ICC
> behaves like GCC.
> I was trying to file a ticket for Clang, but I don't have access to
> bugzilla. Auto-registration
> is not available and manual account registration is still ongoing.
>
>>
>>>
>>> 2016-10-20  Bernhard Heckel  <bernhard.heckel@intel.com>
>>>
>>> gdb/Changelog:
>>>     amd64-tdep.c (amd64_analyze_prologue): Recognize stack
>>> decrementation
>>>     as prologue operation.
>>
>> gdb/ChangeLog above the date line, adjust date and add "*" before the
>> 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] = { 0x89, 0xe5 };
>>>    static const gdb_byte mov_esp_ebp_2[2] = { 0x8b, 0xec };
>>> +  /* Ditto for subtraction on the stack pointer.  */
>>> +  static const gdb_byte sub_rsp_imm8[3] = { 0x48, 0x83, 0xec };
>>> +  static const gdb_byte sub_rsp_imm32[3] = { 0x48, 0x81, 0xec };
>>> +  /* Ditto for subtraction on the stack pointer.  */
>>> +  static const gdb_byte sub_esp_imm8[2] = { 0x83, 0xec };
>>> +  static const gdb_byte sub_esp_imm32[2] = { 0x81, 0xec };
>>
>> Should we add a comment making it explicit which instruction patterns
>> we're looking at matching here?
> You mean, adding it to the function description. There we have
> description for push and mov instruction.
>

To add it to these sub_[esp|rsp|_imm* bits, if meaningful. I don't know 
if these are documented/used somewhere else in gdb. Just a suggestion 
that could improve visual identification of such instructions when going 
through the prologue in disassembly view.

>>
>> I looked up sub esp imm32, for example, and i got no meaningful hits
>> 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 = 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
>> vague.
> Actually, GCC, ICC and Clang are using this approach.
>

I guess you'd want "some compilers" then.


  reply	other threads:[~2016-12-02 15:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01 14:17 Bernhard Heckel
2016-12-01 15:32 ` Luis Machado
2016-12-02  8:40   ` Bernhard Heckel
2016-12-02 15:19     ` Luis Machado [this message]
2016-12-02 23:06 ` Yao Qi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26ac700b-0a50-e136-8e4f-99e19d64548e@codesourcery.com \
    --to=lgustavo@codesourcery.com \
    --cc=bernhard.heckel@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox