libsys: reduce makefile decleration duplication

[brooks]

Summary

Every PSEUDO entry (_foo.o) has a corresponding NOASM entry (foo.o) to
suppress its addition to ASM. Check PSEUDO instead when adding entries
to ASM. No functional change.

These is no longer any valid usecase for system calls with no stub so
remove NOASM entierly.

[kib]

As I understand, this change is the reason to remove yield(2)? Might be, just start exposing yield(2) instead of removing it?

[brooks]

In D44106#1006709, @kib wrote:

As I understand, this change is the reason to remove yield(2)? Might be, just start exposing yield(2) instead of removing it?

I could also just keep NOASM around.

Not sure why we'd expose a symbol with no evidence it has ever been used.

[kib]

In D44106#1006716, @brooks wrote:

In D44106#1006709, @kib wrote:

As I understand, this change is the reason to remove yield(2)? Might be, just start exposing yield(2) instead of removing it?

I could also just keep NOASM around.

Not sure why we'd expose a symbol with no evidence it has ever been used.

Runtimes like go do not link to libc, and do not use our syscalls lists. I am not sure how to check them all and what else besides go there are.

[brooks]

In D44106#1006721, @kib wrote:

In D44106#1006716, @brooks wrote:

In D44106#1006709, @kib wrote:

As I understand, this change is the reason to remove yield(2)? Might be, just start exposing yield(2) instead of removing it?

I could also just keep NOASM around.

Not sure why we'd expose a symbol with no evidence it has ever been used.

Runtimes like go do not link to libc, and do not use our syscalls lists. I am not sure how to check them all and what else besides go there are.

One other option would be to put it under COMPAT14. That (in the current world order) would produce no symbols in libc/sys and keep it around for now.

I've done searches for SYS_yield, sys_yield, and yield 321 on Debian code search and didn't spot any real users. It looks like valgrind might need some minor patching, but that would be the case with COMPAT14 too. It is of course possible that something is using 321 directly or via a differently name local name.

[brooks]

• Update to retain NOASM support

[kib]

declEration in title