Messages in this thread | | | Date | Tue, 21 Jan 2020 10:31:01 +0000 | From | Will Deacon <> | Subject | Re: [RFC v5 00/57] objtool: Add support for arm64 |
| |
On Mon, Jan 13, 2020 at 07:57:48AM +0000, Julien Thierry wrote: > On 1/12/20 8:42 AM, Nathan Chancellor wrote: > > The 0day bot reported a couple of issues with clang with this series; > > the full report is available here (clang reports are only sent to our > > mailing lists for manual triage for the time being): > > > > https://groups.google.com/d/msg/clang-built-linux/MJbl_xPxawg/mWjgDgZgBwAJ > > > > Thanks, I'll have a look at those. > > > The first obvious issue is that this series appears to depend on a GCC > > plugin? I'll be quite honest, objtool and everything it does is rather > > over my head but I see this warning during configuration (allyesconfig): > > > > WARNING: unmet direct dependencies detected for GCC_PLUGIN_SWITCH_TABLES > > Depends on [n]: GCC_PLUGINS [=n] && ARM64 [=y] > > Selected by [y]: > > - ARM64 [=y] && STACK_VALIDATION [=y] > > > > Followed by the actual error: > > > > error: unable to load plugin > > './scripts/gcc-plugins/arm64_switch_table_detection_plugin.so': > > './scripts/gcc-plugins/arm64_switch_table_detection_plugin.so: cannot > > open shared object file: No such file or directory' > > > > If this plugin is absolutely necessary and can't be implemented in > > another way so that clang can be used, seems like STACK_VALIDATION > > should only be selected on ARM64 when CONFIG_CC_IS_GCC is not zero. > > > > So currently the plugin is necessary for proper validation. One option can > be to just let objtool output false positives on files containing jump > tables when the plugin cannot be used. But overall I guess it makes more > sense to disable stack validation for non-gcc builds, for now.
Alternatively, could we add '-fno-jump-tables' to the KBUILD_CFLAGS if STACK_VALIDATION is selected but we're not using GCC? Is that sufficient to prevent generation of these things?
Will
| |