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:     Matt Helsley <mhelsley@vmware.com>, linux-kernel@vger.kernel.org
Cc:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Miroslav Benes <mbenes@suse.cz>
References: <cover.1586468801.git.mhelsley@vmware.com>
From:   Julien Thierry <jthierry@redhat.com>
Message-ID: <3a3f70df-07b0-91d9-33e1-e997e72b0c5c@redhat.com>
Date:   Tue, 14 Apr 2020 08:24:15 +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: <cover.1586468801.git.mhelsley@vmware.com>
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

Hi Matt,

On 4/10/20 8:35 PM, Matt Helsley wrote:
> recordmcount has its own ELF wrapper code and could utilize
> objtool's ELF code to more-portably handle architecture variations.
> This series makes recordmcount a subcommand of objtool.
> 
> The initial 5 patches make objtool compilable for more than x86.
> Unlike recordmcount the check command and orc tools are not currently
> checking other architectures so we need a way to cleanly build
> objtool for those architectures that don't support check / orc. I
> went with using weak symbols and added a "missing" architecture
> which can be used to indicate the tool is not implemented while
> avoiding the need for every architecture to explicitly specify
> which subcommands / features are not implemented. I'm curious if
> there are better approaches folks recommend though -- this is the
> one I landed on. The patches do not add HAVE_OBJTOOL to all
> architectures.
> 

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?

Cheers,

-- 
Julien Thierry