OSDev.org

vvaltchev wrote:Guys,
I've just discovered that the following code:

Code: Select all

#include <inttypes.h>

static __attribute__((always_inline)) inline void
bar(uint8_t a) {
    /* do nothing */
}

void foo(void)
{
   bar(0);
}

When compiled with clang, ANY version, from 3.x to 11.x, using the options: -m32 -O0 -ffreestanding, generates:

Code: Select all

foo:                                    # @foo
        push    ebp
        mov     ebp, esp
        sub     esp, 1                        # What? Why are you making the stack unaligned?
        mov     byte ptr [ebp - 1], 0
        add     esp, 1
        pop     ebp
        ret

Check the example on Compiler Explorer: https://gcc.godbolt.org/z/KPeqaPqjY
Is this a compiler bug? Notes:

1. It doesn't happen with any other compiler.
2. -O0 -ffreestanding have no effect, I just added to remark that it works online without optimizations and that -ffreestanding have no effect.
3. It happens ONLY when __attribute__((always_inline)) is used
4. It happens ONLY when bar() takes an argument that is < sizeof(void *)
5. It happens ONLY with -m32

As you can imagine, I discovered it while debugging my project, after enabling UBSAN and the real example generates much more code,
but, it doesn't matter. This is the shortest and simplest code that reproduces the problem.

In opinion this is definitively a bug, but what do you think about it?

thewrongchristian wrote:I don't think so. $esp isn't being dereferenced, so it's not being used as an invalid or unaligned pointer.
It's probably just boiler plate code that has not yet been optimised away.

qookie wrote:I don't see the problem with this though? foo is a leaf function since it doesn't call anything else. As such, nothing depends on what the stack pointer is aligned to inside of it, and I assume the compiler is smart enough to order things in such a way to respect alignment requirements of the data it puts on the stack.

For example, if inside of bar you add a call to a third function, baz, defined simply like so:

Code: Select all

void baz(uint8_t);

the compiler properly allocates 8 bytes on the stack to keep the proper alignment needed by the ABI.

static void textmode_enable_cursor(void)
{
   const u8 s_start = 0; /* scanline start */
   const u8 s_end = 15;  /* scanline end */

   outb(0x3D4, 0x0A);
   outb(0x3D5, (inb(0x3D5) & 0xC0) | s_start);  // Note: mask with 0xC0
                                                // which keeps only the
                                                // higher 2 bits in order
                                                // to set bit 5 to 0.

   outb(0x3D4, 0x0B);
   outb(0x3D5, (inb(0x3D5) & 0xE0) | s_end);    // Mask with 0xE0 keeps
                                                // the higher 3 bits.
}

vvaltchev wrote: The problem is what: happens when an interrupt occurs?

Korona wrote:Use -mstack-alignment=8 in your kernel to make sure that this does not bite you.

kzinti wrote:I guess the easiest thing to do here then is to align your stack when entering interrupt handlers... It's one more instruction... Not great, but sounds like it is necessary.

thewrongchristian wrote:It won't help. The CPU has already pushed the eflags, esp and cs onto the stack with the dodgy alignment before your interrupt code even has a chance to run.

vvaltchev wrote: Btw, do you know my theory about why the Linux guys haven't hit this problem yet? Linux compiles with clang (as far as I know) and it has support for UBSAN as well, but "-fsanitize=alignment" is not turned on for architectures supporting unaligned access. And, even if you turn it on, it will just log a ton of unaligned access warnings. Not panic handling like in my case.