El Mon, Mar 19, 2018 at 04:20:53PM -0500 Josh Poimboeuf ha dit: > On Mon, Mar 19, 2018 at 01:31:30PM -0700, Matthias Kaehlcke wrote: > > > The ORC unwinder relies on objtool, which reverse engineers the compiled > > > code. This is objtool's first exposure to clang, so I'm not at all > > > surprised if it's getting confused. > > > > > > Send me one of the .o files and I can take a quick look to see how bad > > > it is, but I'm guessing it's going to be a lot of work to make objtool > > > compatible with clang (and unfortunately I won't have the bandwidth to > > > work on that in the near term.) > > > > > > In the meantime I'd recommend that you use frame pointers (and > > > CONFIG_STACK_VALIDATION=n) for clang-compiled kernels. > > > > Thanks for your assessment! > > > > dvo_ch7017.o is attached. > > Here's a (surprisingly easy) fix for this particular issue, though I'd > be shocked if there weren't a bunch more issues lurking elsewhere. Let > me know how it goes.
Thanks for having a look, this fixes the vast majority of warnings in a defconfig build! The remaining warnings are: arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next function pti_user_pagetable_walk_pmd() s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read() fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write() fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll() fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl() fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls through to next function fops_u8_open() In all these functions it's an 'early' return that 'causes' the warning. Obviously I don't expect you to spend large amounts of time investigating this, but should there be a similarily easy fix it would be certainly welcome :) > BTW, one thing I noticed in the .o file is that most of the functions' > stacks are aligned to 16 bytes. It might be worth checking if the clang > -mstack-alignment=8 option is getting set, and if so, if it's working > properly. Otherwise, with aligned stacks, the frame pointer is forced, > which defeats most of the benefits of ORC. Thanks for pointing this out. I verified that -mstack-alignment=8 is set. Do the "and $0xfffffffffffffff0,%rsp" instructions indicate the stack alignment of 16 bytes? These are also present in the object file generated by gcc.
pti.o
Description: application/object
file.o
Description: application/object
