[Bug c/111896] New: call with wrong stack alignment

[Bug c/111896] New: call with wrong stack alignment

[lukas.graetz@tu-darmstadt.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

            Bug ID: 111896
           Summary: call with wrong stack alignment
           Product: gcc
           Version: 9.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lukas.graetz@tu-darmstadt.de
  Target Milestone: ---

Created attachment 56157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56157&action=edit
ccnhCTdD.i.tmp.i

For some reason, I manged to get a SEGV when running a program. I spent time
debugging it, and found out that the problem was when executing:

movaps %xmm0,0x40(%rsp)

It took me some time, but I realized the SEGV was caused by the rsp pointer 8
bytes off. It should be aligned to 16 bytes. So wrong alignment. I also found
out where the misalignment happend.

See the attached file. dlist_free_original() is calling freeit(). This is
compiled as dlist_free_original.constprop.0 calling do_line() as follows:

dlist_free_original.constprop.0:
...
        pushq   %rbp
...
        pushq   %rbx
...
        call    do_line

So the stack is misaligned when the call happens. It might be because do_line()
is written in inline asm with __attribute__((naked)).

Starting with gcc 11.3, there seems to be an extra "sub rsp,8" which seems to
solve this. But I was using gcc 9.4.0 (shipped with ubuntu 20.04) on amd64
linux. A quick check on godbolt showed me that misalignment still happen in gcc
11.2. So I am unsure if this is still relevant but I am reporting just in case.

gcc -O3 -c -S ccnhCTdD.i.tmp.i -o tmp.s

If you need the full executable or anything else, ask me.

Background:

I wanted to have a way to record which functions where called through a
pointer. For that, I created a wrapper for every function, renaming the
original function to ..._original. I also created a macro renaming direct calls
to _original so that only calls through a pointer were left. The wrapper
functions are doing their logging (it takes only a few instructions) and then
sibcall to the respective original function. A wrapper for vararg functions
seemed to be only possible using asm, so I used asm. Since the other functions
might be static, I had to do inline asm with attribute naked.

[Bug target/111896] call with wrong stack alignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-10-20

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
No I think you are looking into the wrong location.

When a call happens, it pushes a value on the stack aligning the stack that is
incoming into that function.

In the case of GCC 11.3 and above, there is inlining happening.

[Bug target/111896] call with wrong stack alignment

[lukas.graetz@tu-darmstadt.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

--- Comment #2 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
(In reply to Andrew Pinski from comment #1)
> No I think you are looking into the wrong location.
> 
> When a call happens, it pushes a value on the stack aligning the stack that
> is incoming into that function.
> 
> In the case of GCC 11.3 and above, there is inlining happening.

Well, I could be mistaken. But I couldn't see the inlining.

In GCC 11.3 and above I get something like:
======================
dlist_free_original.constprop.0:
        push    rbp
        push    rbx
...
        sub     rsp, 8
...
        call    do_line
======================

In GCC 11.2 and below it is something like:
=====================
dlist_free_original.constprop.0:
        push    rbp
...
        push    rbx
...
        call    do_line
===================

And I checked with the gdb debugger that the rsp is indeed misaligned at the
start of do_line(). The alignment was OK at the start of
"dlist_free_original.constprop.0".

======================
$ gdb busybox_unstripped
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
...
(gdb) break dlist_free_original.constprop.0
Breakpoint 1 at 0x59a7ac
(gdb) break do_line
Breakpoint 2 at 0x59a474
(gdb) run patch -R -i input.patch

Breakpoint 1, 0x000000000059a7ac in dlist_free_original.constprop ()
(gdb) i r rsp
rsp            0x7fffffffd998      0x7fffffffd998
(gdb) c
Continuing.

Breakpoint 2, 0x000000000059a474 in do_line ()
(gdb) i r rsp
rsp            0x7fffffffd980      0x7fffffffd980
======================

[Bug target/111896] call with wrong stack alignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This was fixed via PR 101354 's fix.
The simple workaround is to add noipa in an additional to naked.

*** This bug has been marked as a duplicate of bug 101354 ***

[Bug target/111896] call with wrong stack alignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> This was fixed via PR 101354 's fix.
> The simple workaround is to add noipa in an additional to naked.
> 
> *** This bug has been marked as a duplicate of bug 101354 ***

And yes I tested 9.4.0 to see that "fixes" the issue.

[Bug target/111896] call with wrong stack alignment

[lukas.graetz@tu-darmstadt.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111896

--- Comment #5 from Lukas Grätz <lukas.graetz@tu-darmstadt.de> ---
Thanks a lot!