Messages in this thread | | | Date | Tue, 14 Apr 2020 13:09:10 -0700 | From | Matt Helsley <> | Subject | Re: [RFC][PATCH 00/36] objtool: Make recordmcount a subcommand |
| |
On Tue, Apr 14, 2020 at 11:54:58AM -0400, Steven Rostedt wrote: > On Tue, 14 Apr 2020 15:17:39 +0100 > Julien Thierry <jthierry@redhat.com> wrote: > > > > 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. > > Exactly. I believe the goal (it's been a while since we discussed this), > was that we could "batch" the sub commands into a single command. That way, > the executable will be executed once per object file, load all the elf > headers, than iterate over all the sub commands that we set on the command > line.
Yup. The idea is it's somewhat like a pipe but instead of reloading the file and re-creating the linked data structures each time, each sub command would simply hand off the ELF section/symbol/relocation structures to the next tool.
If we look in scripts/Makefile.build for example we can see the rule_cc_o_c definition, after producing the initial .o with the compiler, does:
$(call cmd,gen_ksymdeps) $(call cmd,checkdoc) $(call cmd,objtool) $(call cmd,modversions_c) $(call cmd,record_mcount)
The latter 3 all deal with loading and walking the ELF file output from the previous step. If we could merge that into a single "call" to objtool then we can avoid the extra write-close-open-read cycles. I also wonder if we could move "checkdoc" because then 4 tools in a row could be relevant to convert (genksyms makes simple use of nm).
I also noticed that, for example, sorttable uses the same ELF code / patterns as recordmcount -- like the double-include trick. Of course it operates on a larger scale than per-object-file and so there might only be code maintenance savings there...
Also, the follow-on is definitely more speculative -- these patches show that things like recordmcount can be converted to share the same ELF code as objtool. The benefits of chaining commands together, how easy/hard that would be, etc. haven't been fully fleshed out. For instance, I was only looking at "check" and "mcount" chained together.
But even aside from those changes, having all of the tools use the same ELF code and keeping that ELF code in one place rather than copy-paste it seems like it would be useful for maintenance.
Cheers, -Matt
| |