On 7/30/20 2:33 PM, pet...@infradead.org wrote:
On Thu, Jul 30, 2020 at 01:40:48PM +0100, Julien Thierry wrote:
On 7/30/20 11:03 AM, pet...@infradead.org wrote:
On Thu, Jul 30, 2020 at 10:41:43AM +0100, Julien Thierry wrote:
One orc_entry is associated with each instruction in the object file,
but having the orc_entry contained by the instruction structure forces
architectures not implementing the orc subcommands to provide a dummy
definition of the orc_entry.
I guess I forgot about the usecase of running objtool on vmlinux...
Right, and LTO builds will even do ORC at that level.
On a kernel build for x86_64 defconfig, the difference in time seems to be
withing the noise.
Good.
But I agree the proposed code is not ideal and on the other we've tried
avoiding #ifdef in the code. Ideally I'd have an empty orc_entry definition
when SUBCMD_ORC is not implemented.
Would you have a suggested approach to do that?
How ugly is having that:
struct orc_entry { };
?
Not sure I am understanding the suggestion. Without #ifdef this will
conflict with the definition in <asm/orc_types.h> for x86. Or every arch
needs to provide their own <asm/orc_types.h> and definition of struct
orc_entry, even if they don't implement the orc subcommand.
Which would be preferable? #ifdef? or arch provided definition? (or
something I have not thought of)
--
Julien Thierry
