[Bug c++/108337] New: Misaligned memory access issues when inline assembly is used with optimization on x86_64

[Bug c++/108337] New: Misaligned memory access issues when inline assembly is used with optimization on x86_64

[eric-bugs at omnifarious dot org]

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

            Bug ID: 108337
           Summary: Misaligned memory access issues when inline assembly
                    is used with optimization on x86_64
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric-bugs at omnifarious dot org
  Target Milestone: ---

The following code works fine when compiled this way:

g++ -std=c++20 -march=znver2 -static -O1 -nostartfiles -nostdlib -Wl,-emain
foo.cpp

but when compiled this way generates a segfault before outputting anything:

g++ -std=c++20 -march=znver2 -static -O2 -nostartfiles -nostdlib -Wl,-emain
foo.cpp


---------- foo.cpp ---------
using val_t = unsigned long;
using call_id = unsigned short;

  template<typename _Tp>
    struct remove_reference
    { typedef _Tp type; };

  template<typename _Tp>
    struct remove_reference<_Tp&>
    { typedef _Tp type; };

  template<typename _Tp>
    struct remove_reference<_Tp&&>
    { typedef _Tp type; };

  template<typename _Tp>
    [[__nodiscard__]]
    constexpr _Tp&&
    forward(typename remove_reference<_Tp>::type& __t) noexcept
    { return static_cast<_Tp&&>(__t); }


struct syscall_param {
   syscall_param(val_t v) noexcept : value(v) { }

   syscall_param(void *v) noexcept : value(reinterpret_cast<val_t>(v)) {
      static_assert(sizeof(void *) == sizeof(val_t));
   }

   syscall_param(void const *v) noexcept : value(reinterpret_cast<val_t>(v)) {
      static_assert(sizeof(void *) == sizeof(val_t));
   }
   val_t value;
};

inline val_t do_syscall(call_id callnum,
                           syscall_param const &p1) noexcept
{
   val_t retval;
   asm volatile (
      "syscall\n\t"
       :"=a"(retval)
       :"a"(static_cast<unsigned long>(callnum)), "D"(p1.value)
       :"%rcx", "%r11", "memory"
      );
   return retval;
}

inline val_t do_syscall(call_id callnum,
                           syscall_param const &p1,
                           syscall_param const &p2,
                           syscall_param const &p3) noexcept
{
   val_t retval;
   asm volatile (
      "syscall\n\t"
       :"=a"(retval)
       :"a"(static_cast<unsigned long>(callnum)), "D"(p1.value), "S"(p2.value),
 "d"(p3.value)
       :"%rcx", "%r11", "memory"
      );
   return retval;
}

template <typename... T>
val_t
syscall_expected(call_id callnum, T &&... args) noexcept
{
   val_t result = do_syscall(callnum, forward<T>(args)...);

   return result;
}

inline val_t write(int fd, char const *data, unsigned long size) noexcept
{
   return syscall_expected(1, fd, data, size);
}

inline void exit [[noreturn]](int status) noexcept {
   syscall_expected(231, status);
   __builtin_unreachable();
}

int main(int argc, char *argv[])
{
    int i = 0;
    char msg[] = "Hello World 0!\n";

    auto result = write(1, msg, sizeof(msg) - 1);
    i = 1;
    while (result >= 0 && i < 10) {
        msg[12] = i++ + '0';
        result = write(1, msg, sizeof(msg) - 1);
    }
    exit(result >= 0 ? 0 : 1);
}

[Bug target/108337] Misaligned memory access issues when inline assembly is used with optimization on x86_64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It might be the case the stack pointer is not inlined when main is called from
the kernel ...

What target is this? X86_64-linux-gnu?

[Bug target/108337] Misaligned memory access issues when inline assembly is used with optimization on x86_64

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
int main(int argc, char *argv[])
{
    int i = 0;
    char msg[65] = "Hello World 0!\n";

    auto result = write(1, msg, sizeof(msg) - 1);
    i = 0;
    uintptr_t t;
    asm("mov %%rsp, %0":"=r"(t));
    while (i < 64) {
        uintptr_t tt = (t >> i) & 0xf;
        msg[(64-i-1)] = (tt > 9) ? (tt - 10 + 'a') : (tt + '0');
        i++;
    }
    result = write(1, msg, sizeof(msg) - 1);
    exit(result >= 0 ? 0 : 1);
}

Gives:
00000000000000000137fffffffffffeda5b6db6da5a49248124925b7eda5a48
For  -static -nostartfiles -nostdlib -Wl,-emain without gives:
00000000000000000137ffffffffffedb6c92480001248137ec8125b6da5a480


You need  -mstackrealign to correct for the not aligned stack pointer that the
kernel gives.

[Bug target/108337] Misaligned memory access issues when inline assembly is used with optimization on x86_64

[eric-bugs at omnifarious dot org]

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

eric-bugs at omnifarious dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #3 from eric-bugs at omnifarious dot org ---
Oh, interesting! Does -mstackrealign affect every single function the compiler
emits?

[Bug target/108337] Misaligned memory access issues when inline assembly is used with optimization on x86_64

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes it affects every function. There might be another way to use attribute to
specific that only main needs this treatment. Or better yet add a _start
function in assembly to that.

[Bug target/108337] Misaligned memory access issues when inline assembly is used with optimization on x86_64

[eric-bugs at omnifarious dot org]

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

--- Comment #5 from eric-bugs at omnifarious dot org ---
(In reply to Andrew Pinski from comment #4)
> Yes it affects every function. There might be another way to use attribute
> to specific that only main needs this treatment. Or better yet add a _start
> function in assembly to that.

That's what I was thinking. I need to actually re-implement a bunch of the g++
runtime environment for what I want to achieve, and so that's likely what I'll
be doing. Thanks!