lkml.org 
[lkml]   [2020]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v5 00/57] objtool: Add support for arm64
From
Date
Hi Nathan,

On 1/12/20 8:42 AM, Nathan Chancellor wrote:
>
> Hi Julien,
>
> 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.

Once people are happy with the state of things of arm64 objtool with gcc
it might be worth looking at a clang plugin (although I don't know if
the kernel has any support to build those at the moment).

In the mean time, I'll do as you suggest and rely on CC_IS_GCC.

> The second issue I see is the -Wenum-conversion warnings; they are
> pretty trivial to fix (see commit e7e83dd3ff1d ("objtool: Fix Clang
> enum conversion warning") upstream and the below diff).
>

Oh yes, these are valid warnings. I'll fix those.

> Would you mind addressing these in a v6 if you happen to do one?
>

Yes, I'll most likely do one as I don't expect this to be a final version.

Thanks for reporting those. I'll fix them in the next iteration.

Cheers,

--
Julien Thierry

\
 
 \ /
  Last update: 2020-01-13 08:59    [W:0.250 / U:0.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site