Messages in this thread | | | Date | Thu, 30 Apr 2020 16:08:05 -0500 | From | Josh Poimboeuf <> | Subject | Re: Remaining randconfig objtool warnings, linux-next-20200428 |
| |
On Thu, Apr 30, 2020 at 02:46:30PM -0500, Josh Poimboeuf wrote: > > Yup, makes sense. I think I've been getting confused by the syscall > > wrappers. > > > > > How hard would it be to change objtool instead of changing the sources?
So I just realized this is an objtool bug after all. Or at least a new GCC quirk. The quick fix is:
sed -si 's/cold./cold/' tools/objtool/check.c
However... after studying how all this works, I'm actually thinking that it makes sense to move the SYS_NI usage into kernel/sys_ni.c, like you originally suggested. That seems cleaner to me: all the syscall aliasing code together in one file. SYS_NI is similar to COND_SYSCALL, except it has a custom ENOSYS handler. Having "NI" in the name is another clue it belongs in sys_ni.c.
Alternatively, I could do the x86-specific SYSCALL_ALIAS, which is easy enough, but I really prefer the sys_ni.c approach.
Either of those would allow the removal of some hacky objtool code, which only ever existed in the first place because of posix-stubs.c and that inline asm SYSCALL_ALIAS macro.
One of objtool's goals is to standardize ELF data, and it seems reasonable to require the use of C-based aliases. And I think it would be a nice cleanup anyway.
-- Josh
| |