The asmdecl checker infers the architecture from file name or the +build line, and assumes all the functions in the same file uses this architecture. So defining a function for ppc64le in a ppc64 file may not work:

#ifdef GOARCH_ppc64le
...
#endif

If we don't want to create a separate file "src/runtime/sys_linux_ppc64le.s" to avoid duplications, then we may need to change this checker's assumption, and examine the intent architecture for each function.

I think I have a workaround for this. Just create different stubs files for ppc64le and ppc64 and aix and put the Go prototype where it is needed by vet. Personally I think the tools should adapt to the code, and not make the code adapt to the tool. I see lines in several places saying "needed for vet."

Without knowing too much about how vet works, it must know what the target goos goarch is because it has decided to parse some files but not others since it has decided what prototype to remember for use when matching with the function in the asm file. With that information it could run the preprocessor or the equivalent on the source file before parsing it. The assembler must need to do that. Just a thought.

There are a lot of problems with asmdecl right now, unfortunately. I'm going to close this as a duplicate of #17544.

With that information it could run the preprocessor or the equivalent on the source file before parsing it.

This is tricky because there's no separate preprocessor right now for vet to run. In fact, calling what asmdecl does "parsing" would be quite generous. It's really just a pile of ad hoc regexps. This is why we'd like to just integrate this into cmd/asm itself.