3 ms·

The macro from the article uses nested functions which on gcc are implemented with tramolines that need executable stack. https://thephd.dev/lambdas-nested-fun

The macro from the article uses nested functions which on gcc are implemented with tramolines that need executable stack. https://thephd.dev/lambdas-nested-functions-block-expressions-oh-my https://thephd.dev/lambdas-nested-functions-block-expression...

uecker 2y ago
The trampolines are not generated in this case.
- eqvinox 2y ago
  To be fair you're not communicating very well — there are no trampolines being used here because the call site is directly in the same function, so no trampoline is needed with already being in the correct stack frame. (And also on -O1 and higher the entire call is optimized out and the nested function inlined instead.)
  - uecker 2y ago
    Fair, I was not explaining why the statement was wrong. Anyhow, the trampoline is not related to the call site being in the same function but whether a pointer is generated to the nested function and escapes. Nested functions in general do not need trampolines or executable stack.
    - accelbred 2y ago
      Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.
      - Gibbon1 2y ago
        I've used nested functions for a very long time with gcc and they are completely reliable. Since my code is embedded without an MMU the oh noes executable stack doesn't fill me with any dread. It's unfortunate a lot of the standards guys are horrified by anything that isn't C89. Because if the executable stack is an issue it's worth fixing. Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies.
        eru 2y ago
        > Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies. Slowing them down is good. And: separating data and code helps simplify managing the caches.
        uecker 2y ago
        One could easily remove the need for trampolines by having a wide function pointer type. In C, this would even be allowed without having a new type, but ABI compatibility makes this not practical. With a new qualifier this would be no problem though. The real reason some people are against it is that it diverges from C++.
    - uecker 2y ago
      And I should mention that GCC nowadays can also allocate the trampoline on the heap: -ftrampoline-impl=heap
      - eqvinox 2y ago
        Well, the heap is also non-executable on a whole bunch of platforms these days (and for good measure, w^x is a good concept to go by; even JITed code shouldn't be writable and executable at the same time)
  - kragen 2y ago
    I feel that uecker went above and beyond the call of duty by including a godbolt link in their first comment which shows the full assembly-language implementation of this behavior by GCC without using an executable stack, with syntax highlighting, and full C source for reproducing the behavior on your own machine. I don't see how anything they could possibly have written as a comment could be clearer or more convincing.
    - uecker 2y ago
      I edited the comment to add the link a couple of minutes later, so maybe it was missed.

uecker 2y ago

The trampolines are not generated in this case.

eqvinox 2y ago
To be fair you're not communicating very well — there are no trampolines being used here because the call site is directly in the same function, so no trampoline is needed with already being in the correct stack frame. (And also on -O1 and higher the entire call is optimized out and the nested function inlined instead.)
- uecker 2y ago
  Fair, I was not explaining why the statement was wrong. Anyhow, the trampoline is not related to the call site being in the same function but whether a pointer is generated to the nested function and escapes. Nested functions in general do not need trampolines or executable stack.
  - accelbred 2y ago
    Nice, if this is reliable across gcc versions and optimization levels, I might consider it for future stuff. Though making it such that treesitter and other tools dont barf on it would still need investigation.
    - Gibbon1 2y ago
      I've used nested functions for a very long time with gcc and they are completely reliable. Since my code is embedded without an MMU the oh noes executable stack doesn't fill me with any dread. It's unfortunate a lot of the standards guys are horrified by anything that isn't C89. Because if the executable stack is an issue it's worth fixing. Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies.
      - eru 2y ago
        > Side note: 20 years ago people thought if they made the stack non executable that would totally fix stack smashing attacks and unfortunately it only slows down script kiddies. Slowing them down is good. And: separating data and code helps simplify managing the caches.
        uecker 2y ago
        One could easily remove the need for trampolines by having a wide function pointer type. In C, this would even be allowed without having a new type, but ABI compatibility makes this not practical. With a new qualifier this would be no problem though. The real reason some people are against it is that it diverges from C++.
  - uecker 2y ago
    And I should mention that GCC nowadays can also allocate the trampoline on the heap: -ftrampoline-impl=heap
    - eqvinox 2y ago
      Well, the heap is also non-executable on a whole bunch of platforms these days (and for good measure, w^x is a good concept to go by; even JITed code shouldn't be writable and executable at the same time)
- kragen 2y ago
  I feel that uecker went above and beyond the call of duty by including a godbolt link in their first comment which shows the full assembly-language implementation of this behavior by GCC without using an executable stack, with syntax highlighting, and full C source for reproducing the behavior on your own machine. I don't see how anything they could possibly have written as a comment could be clearer or more convincing.
  - uecker 2y ago
    I edited the comment to add the link a couple of minutes later, so maybe it was missed.