[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200414093506.7b91bbbb@gandalf.local.home>
Date: Tue, 14 Apr 2020 09:35:06 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Julien Thierry <jthierry@...hat.com>
Cc: Matt Helsley <mhelsley@...are.com>, linux-kernel@...r.kernel.org,
Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Miroslav Benes <mbenes@...e.cz>
Subject: Re: [RFC][PATCH 00/36] objtool: Make recordmcount a subcommand
On Tue, 14 Apr 2020 08:24:15 +0100
Julien Thierry <jthierry@...hat.com> wrote:
> If all you need from objtool it the elf parsing code, wouldn't it make
> more sense to move that out of objtool, as a utility library that both
> objtool and recordmcount could use (and perhaps other tools in the future?)
>
> In patch 3 you seem to mention that other tools already have their own
> code to parse elf. So instead of converting everything as an objtool
> subcommand, maybe just have the library with the required functionality.
>
> Any opinions on the above? What do people prefer?
I think we discussed this before (and originally that was the plan), but I
believe one of the goals for bringing recordmcount into objtool is to speed
up the processing. Instead of having to read the elf sections for each use
case, we do it once, and then execute all the necessary operations for that
build.
If we just have a elf parsing library, then each object file is going to
have that read redundantly for each operation that is done on it.
I was hoping to have objtool handle all the operations needed that required
reading elf headers.
But if that's not what objtool maintainers want, then we can certainly go
back to looking at pulling out the elf headers, and have each tool be a
standalone again.
-- Steve
Powered by blists - more mailing lists