Mark asm code with no-executable-stack.

[clalancette]

Newer versions of binutils (2.39 and above) complain if you have assembly without explicitly marking that it is not using an executable stack (see
https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments for more details). Mark it here to quiet that warning.

[clalancette]

CI for this is in ros2/mimick_vendor#32 (comment)

[cottsay]

This looks like something that should also be contributed upstream. Would it be appropriate to open a PR there as well?

[clalancette]

This looks like something that should also be contributed upstream. Would it be appropriate to open a PR there as well?

Yes, agreed. I will go ahead and do that.

That said, we have a bunch of other patches here (which is why we still have this fork), so I think we'll need to take this PR anyway. Someday we should clean this up and submit all of our patches upstream.

[cottsay]

...I think we'll need to take this PR anyway.

Agreed.

Someday we should clean this up and submit all of our patches upstream.

We can dream.

[cottsay]

Do we ever build Mimick with non-GNU toolchains?

[clalancette]

Do we ever build Mimick with non-GNU toolchains?

Good question. We do! Both MSVC and clang.

In the MSVC case, this definitely won't make a difference, as Mimick uses a different file for Windows (trampoline-x86_64-win.S).

However, there is some possibility this could be a problem with the clang build. Let's see what CI looks like there (and while we are at it, also RHEL). I've launched the builds in the other PR, just so the CI is all in one place: ros2/mimick_vendor#32 (comment)

[clalancette]

It looks like both MSVC and Clang are OK with this change, so I think this (and ros2/mimick_vendor#32) can be reviewed again.

[cottsay]

Here's the upstream PR for tracking purposes: Snaipe#38

[clalancette]

Thanks! I'm going to go ahead and merge this one in, then fix up ros2/mimick_vendor#32 to point to the correct hash.

[srmainwaring]

However, there is some possibility this could be a problem with the clang build.

Unfortunately breaks compilation on M1 macs.

[  4%] Building ASM object CMakeFiles/mimick.dir/src/asm/trampoline-aarch64.S.o
/Users/rhys/Code/ros2/rolling/ros2-rolling/src/Mimick/src/asm/trampoline-aarch64.S:80:19: error: unexpected token in '.section' directive
.section .note.GNU-stack, "", @progbits

% clang --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[clalancette]

/Users/rhys/Code/ros2/rolling/ros2-rolling/src/Mimick/src/asm/trampoline-aarch64.S:80:19: error: unexpected token in '.section' directive

Oh, that's interesting. It works on aarch64 (gcc), it works on clang (amd64), but it fails on clang aarch64 (at least with that version of clang). Looking around, this probably has to do with the assembler on macOS: https://stackoverflow.com/questions/59799671/error-unexpected-token-in-section-directive-section-multiboot .

I'm open to ideas on what to do. I don't have an aarch64 macOS machine to test on, unfortunately.