Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC][PATCH 00/36] objtool: Make recordmcount a subcommand
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     Matt Helsley <mhelsley@vmware.com>, linux-kernel@vger.kernel.org,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>, Miroslav Benes <mbenes@suse.cz>
References: <cover.1586468801.git.mhelsley@vmware.com>
 <3a3f70df-07b0-91d9-33e1-e997e72b0c5c@redhat.com>
 <20200414093506.7b91bbbb@gandalf.local.home>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <064f41bd-0dfe-e875-df7c-214184c29fa7@redhat.com>
Date:   Tue, 14 Apr 2020 15:17:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200414093506.7b91bbbb@gandalf.local.home>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 4/14/20 2:35 PM, Steven Rostedt wrote:
> On Tue, 14 Apr 2020 08:24:15 +0100
> Julien Thierry <jthierry@redhat.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.
> 

That makes sense, however, having each operation as an objtool 
subcommand doesn't solve that issue, right? Each invocation of objtool 
will re-read the elf object.

I guess having all the relevant code in objtool as subcommand would be a 
first step towards that goal.

> 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.
> 

I'm no maintainer nor know their feeling about this and I haven't been 
part of the initial discussion. My main concern was about the approach 
of moving existing subcommand code to arch specific folders.

Thanks for the explanations.

Cheers,

-- 
Julien Thierry