On Sat, 30 Apr 2022 01:03:01 +0530 "Naveen N. Rao" <naveen.n....@linux.vnet.ibm.com> wrote:
> > The point of this section is to know which functions in __mcount_loc may > > have been overridden, as they would be found in the __mcount_loc_weak > > section. And then we can do something "special" to them. > > I'm not sure I follow that. How are you intending to figure out which > functions were overridden by looking at entries in the __mcount_loc_weak > section? If there's duplicates (or something strange with the offset) then we could delete the one that has the match in the weak section. > > In the final vmlinux image, we only get offsets into .text for all > mcount locations, but no symbol information. The only hint is the fact > that a single kallsym symbol has multiple mcount locations within it. > Even then, the symbol with duplicate mcount entries won't be the > function that was overridden. > > We could do a kallsyms_lookup() on each entry and consult the > __mcount_loc_weak section to identify duplicates, but that looks to be > very expensive. > > Did you have a different approach in mind? We only need to look at the ones in the weak section. How many that is may determine if that's feasible or not. > > > > >> > >> As an example, in the issue described in this patch set, if powerpc > >> starts over-riding kexec_arch_apply_relocations(), then the current weak > >> implementation in kexec_file.o gets carried over to the final vmlinux, > >> but the instructions will instead appear under the previous function in > >> kexec_file.o: crash_prepare_elf64_headers(). This function may or may > >> not be traced to begin with, so we won't be able to figure out if this > >> is valid or not. > > > > If it was overridden, then there would be two entries for function that > > overrides the weak function in the __mcount_loc section, right? One for the > > new function, and one that was overridden. > > In the final vmlinux, we will have two entries: one pointing at the > correct function, while the other will point to some other function > name. So, at least from kallsym perspective, duplicate mcount entries > won't be for the function that was overridden, but some arbitrary > function that came before the weak function in the object file. Right, and we should be able to find them. > > > Of course this could be more > > complex if the new function had been marked notrace. > > > > I was thinking of doing this just so that we know what functions are weak > > and perhaps need extra processing. > > > > Another issue with weak functions and ftrace just came up here: > > > > https://lore.kernel.org/all/20220428095803.66c17...@gandalf.local.home/ > > I noticed this just yesterday: > > # cat available_filter_functions | sort | uniq -d | wc -l > 430 > > I'm fairly certain that some of those are due to weak functions -- I > just wasn't sure if all of those were. Probably :-/ > > I suppose this will now also be a problem with ftrace_location(), given > that it was recently changed to look at an entire function for mcount > locations? > Maybe. I have to focus on other things at the moment, but I'll try to find some time to look at this deeper. -- Steve
