sim: detect clang native compiler on MacOS.

[ptka]

Summary

Detect clang native compiler on MacOS.
In case clang based compiler is used, skip objcopy step in final build step.

Impact

Simulation on MacOS.

Testing

MacBook Pro Late 2013 running Big Sur (X86_64)
Testing on MacBook Air 2020 running Monterey (ARM64) will be part of separate PR.

[yamt]

X86_64 based hosts stay on current (gcc/binutils) configuration for backward compatibility.

i guess you misunderstand the situation.

i have always been using clang to develop sim/macOS/x86-64.
i have not used gcc for the purpose.
i don't know if it's possible to build sim/macOS with gcc.

also, i usually use clang to build sim/Linux/x86-64 without problems.
so i'm not sure why this option is necessary.

[ptka]

Native compiler on MacOS doesn't have objcopy installed. I assume, you have additional software installed on your MacOS which (maybe as a side-effect) installs objcopy. Can you check your system regarding this point, please.
If current MacOS/X86 is designed to use clang, then the option is most likely not needed, as it was just introduced for backward compatibility.

[yamt]

Native compiler on MacOS doesn't have objcopy installed. I assume, you have additional software installed on your MacOS which (maybe as a side-effect) installs objcopy. Can you check your system regarding this point, please. If current MacOS/X86 is designed to use clang, then the option is most likely not needed, as it was just introduced for backward compatibility.

yes, it requires objcopy from binutils.
see #1817
maybe we forgot to document it.
at that point, the llvm version of objcopy didn't work well.

can you explain why objcopy is not necessary for clang?

[xiaoxiang781216]

@ptka does llvm-objcpy and llvm-objdump exist on macOS?

[yamt]

@ptka does llvm-objcpy and llvm-objdump exist on macOS?

in my environment with Monterey x86-64, Xcode 13.2.1,
neither Xcode nor CommandLineTools has them.

llvm from homebrew has them.

[yamt]

maybe we can consider to revert #1817 .
it's awkward to require binutils.

[xiaoxiang781216]

@ptka found that objcopy isn't really needed, I think.

[ptka]

Native compiler on MacOS doesn't have objcopy installed. I assume, you have additional software installed on your MacOS which (maybe as a side-effect) installs objcopy. Can you check your system regarding this point, please. If current MacOS/X86 is designed to use clang, then the option is most likely not needed, as it was just introduced for backward compatibility.

yes, it requires objcopy from binutils. see #1817 maybe we forgot to document it. at that point, the llvm version of objcopy didn't work well.

can you explain why objcopy is not necessary for clang?

Afaik: objcopy is used to hide the NuttX world from the HOST world to avoid, that the wrong functions are called. Before linking the final host executable, objcopy renames a list of NuttX symbols. Overall this is a kind of a workaround as in principle is should work in a different way: Compiling code with "-fvisibility=hidden" should mark functions as hidden. Hidden means, they are not exported from any 'ld' created object file. All symbols, which needs to exported, can overwrite the visibility in the code itself. This way 'main()' and 'up_doirq()' gets visible in the HOST world although they are defined in the NuTTX world. On MacOS/clang the compiler/linker behaves exactly that way and objcopy is thus not needed.

[yamt]

Native compiler on MacOS doesn't have objcopy installed. I assume, you have additional software installed on your MacOS which (maybe as a side-effect) installs objcopy. Can you check your system regarding this point, please. If current MacOS/X86 is designed to use clang, then the option is most likely not needed, as it was just introduced for backward compatibility.

yes, it requires objcopy from binutils. see #1817 maybe we forgot to document it. at that point, the llvm version of objcopy didn't work well.
can you explain why objcopy is not necessary for clang?

Afaik: objcopy is used to hide the NuttX world from the HOST world to avoid, that the wrong functions are called. Before linking the final host executable, objcopy renames a list of NuttX symbols. Overall this is a kind of a workaround as in principle is should work in a different way: Compiling code with "-fvisibility=hidden" should mark functions as hidden. Hidden means, they are not exported from any 'ld' created object file. All symbols, which needs to exported, can overwrite the visibility in the code itself. This way 'main()' and 'up_doirq()' gets visible in the HOST world although they are defined in the NuTTX world. On MacOS/clang the compiler/linker behaves exactly that way and objcopy is thus not needed.

ok. thank you for the explanation.

• i guess more functions need to be exported. eg. netdriver_setmacaddr
• i don't think it's arm specific.
• if it's clang-specific (i dunno) it might be simpler to use ifneq "$(shell $(CC) --version | grep clang)" "" than a kconfig
• i don't understand the change in up_vfork_x86_64.S. is it somehow tied to the objcopy part of the PR? otherwise, i'd suggest to leave it for a separate PR.

[ptka]

maybe we can consider to revert #1817 .
it's awkward to require binutils.

I think, we need to distinguish between clang and gcc/binutils based HOST compiler suites (maybe it's even just an MacOS issue). On gcc/binutils based HOST compiler suites objcopy is needed to avoid wrong function calls between the NuttX and the HOST world within the overall simulation. In my opinion we cannot simply revert mentioned PR.

[yamt]

maybe we can consider to revert #1817 .
it's awkward to require binutils.

I think, we need to distinguish between clang and gcc/binutils based HOST compiler suites (maybe it's even just an MacOS issue). On gcc/binutils based HOST compiler suites objcopy is needed to avoid wrong function calls between the NuttX and the HOST world within the overall simulation. In my opinion we cannot simply revert mentioned PR.

as far as your approach works, there is no point to revert.

[xiaoxiang781216]

If @ptka finding is right, I would prefer that we remove objcopy step for macOS regardless whether it is run on x64 or arm64.

[ptka]

Native compiler on MacOS doesn't have objcopy installed. I assume, you have additional software installed on your MacOS which (maybe as a side-effect) installs objcopy. Can you check your system regarding this point, please. If current MacOS/X86 is designed to use clang, then the option is most likely not needed, as it was just introduced for backward compatibility.

yes, it requires objcopy from binutils. see #1817 maybe we forgot to document it. at that point, the llvm version of objcopy didn't work well.
can you explain why objcopy is not necessary for clang?

Afaik: objcopy is used to hide the NuttX world from the HOST world to avoid, that the wrong functions are called. Before linking the final host executable, objcopy renames a list of NuttX symbols. Overall this is a kind of a workaround as in principle is should work in a different way: Compiling code with "-fvisibility=hidden" should mark functions as hidden. Hidden means, they are not exported from any 'ld' created object file. All symbols, which needs to exported, can overwrite the visibility in the code itself. This way 'main()' and 'up_doirq()' gets visible in the HOST world although they are defined in the NuTTX world. On MacOS/clang the compiler/linker behaves exactly that way and objcopy is thus not needed.

ok. thank you for the explanation.

• i guess more functions need to be exported. eg. netdriver_setmacaddr
• i don't think it's arm specific.
• if it's clang-specific (i dunno) it might be simpler to use ifneq "$(shell $(CC) --version | grep clang)" "" than a kconfig
• i don't understand the change in up_vfork_x86_64.S. is it somehow tied to the objcopy part of the PR? otherwise, i'd suggest to leave it for a separate PR.

This ifneq "$(shell $(CC) --version | grep clang)" "" could be a good approach. I reworked the PR.

[ptka]

@ptka does llvm-objcpy and llvm-objdump exist on macOS?

in my environment with Monterey x86-64, Xcode 13.2.1, neither Xcode nor CommandLineTools has them.

llvm from homebrew has them.

I would like to see MacOS based simulation independent from homebrew. There's nothing wrong with homebrew, but native compiler suite should be good enough, so there's no need for this dependencies from compiler perspective.

[xiaoxiang781216]

more symbol need add default visibility: _up_cpu_started, _up_init_ipi, _netdriver_setmacaddr.

[ptka]

more symbol need add default visibility: _up_cpu_started, _up_init_ipi, _netdriver_setmacaddr.

that's the easy part ... the critical part is getting the modules compiled ... there's a hard dependency:

MODULECC = x86_64-elf-gcc
MODULELD = x86_64-elf-ld

to get the elf modules build.

This could be really a show-stopper (or at least an not-easy to fix dependency to homebrew based additional software needed on MacOS).

[ptka]

Let me park this PR completely ... it's not working, the way it was intended ... I need to re-think.

[xiaoxiang781216]

more symbol need add default visibility: _up_cpu_started, _up_init_ipi, _netdriver_setmacaddr.

that's the easy part ... the critical part is getting the modules compiled ... there's a hard dependency:

MODULECC = x86_64-elf-gcc
MODULELD = x86_64-elf-ld

to get the elf modules build.

This could be really a show-stopper (or at least an not-easy to fix dependency to homebrew based additional software needed on MacOS).

Yes, elf need gcc toolchain, but this is an advance feature, not used by most people. It's reasonable require the user to install gcc toolchain if they want to try elf.

[ptka]

I installed the packages via homebrew to fulfill:

MODULECC = x86_64-elf-gcc
MODULELD = x86_64-elf-ld

Additionally, I removed all changed except the "objcopy" part and the related symbol export changes. Making this PR focus on a single topic.

[xiaoxiang781216]

@yamt do you ok with the change?

[yamt]

the init array stuff is about linux, not clang/gcc.

[xiaoxiang781216]

so, gcc on macOS go the dynamical replacement?

[yamt]

my concern is clang on linux. i can't think of a reason why the init array is not necessary in that case.

[yamt]

#5486