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.
Avoid that by having orc_entries in a separate list, part of the
objtool_file.
diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
index 66fd56c33303..00f1efd05653 100644
--- a/tools/objtool/orc_gen.c
+++ b/tools/objtool/orc_gen.c
@@ -9,18 +9,33 @@
#include "check.h"
#include "warn.h"
+struct orc_data {
+ struct list_head list;
+ struct instruction *insn;
+ struct orc_entry orc;
+};
+
int create_orc(struct objtool_file *file)
{
struct instruction *insn;
for_each_insn(file, insn) {
- struct orc_entry *orc = &insn->orc;
struct cfi_reg *cfa = &insn->cfi.cfa;
struct cfi_reg *bp = &insn->cfi.regs[CFI_BP];
+ struct orc_entry *orc;
+ struct orc_data *od;
if (!insn->sec->text)
continue;
+ od = calloc(1, sizeof(*od));
+ if (!od)
+ return -1;
+ od->insn = insn;
+ list_add_tail(&od->list, &file->orc_data_list);
+
+ orc = &od->orc;
+
orc->end = insn->cfi.end;
if (cfa->base == CFI_UNDEFINED) {
This will dramatically increase the amount of allocation calls, what, if
anything, does this do for the performance of objtool?
I guess I forgot about the usecase of running objtool on vmlinux...
On a kernel build for x86_64 defconfig, the difference in time seems to
be withing the noise.
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?
Thanks,
--
Julien Thierry
