kernel/linux.git/scripts/sorttable.c, branch v6.19.11

sorttable: Move ELF parsing into scripts/elf-parse.[ch]

2025-10-24T20:43:14+00:00

In order to share the elf parsing that is in sorttable.c so that other programs could use the same code, move it into elf-parse.c and elf-parse.h. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Arnd Bergmann Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Nick Desaulniers Cc: Catalin Marinas Cc: Linus Torvalds Cc: Randy Dunlap Cc: Stephen Rothwell Link: https://lore.kernel.org/20251022004452.752298788@kernel.org Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Fix endianness handling in build-time mcount sort

2025-04-02T13:51:26+00:00

Kernel cross-compilation with BUILDTIME_MCOUNT_SORT produces zeroed mcount values if the build-host endianness does not match the ELF file endianness. The mcount values array is converted from ELF file endianness to build-host endianness during initialization in fill_relocs()/fill_addrs(). Avoid extra conversion of these values during weak-function zeroing; otherwise, they do not match nm-parsed addresses and all mcount values are zeroed out. Cc: Masami Hiramatsu Cc: Catalin Marinas Cc: Nathan Chancellor Cc: Heiko Carstens Cc: Alexander Gordeev Link: https://lore.kernel.org/patch.git-dca31444b0f1.your-ad-here.call-01743554658-ext-8692@work.hours Fixes: ef378c3b8233 ("scripts/sorttable: Zero out weak functions in mcount_loc table") Reported-by: Ilya Leoshkevich Reported-by: Ihor Solodrai Closes: https://lore.kernel.org/all/your-ad-here.call-01743522822-ext-4975@work.hours/ Signed-off-by: Vasily Gorbik Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Allow matches to functions before function entry

2025-02-25T18:25:13+00:00

ARM 64 uses -fpatchable-function-entry=4,2 which adds padding before the function and the addresses in the mcount_loc point there instead of the function entry that is returned by nm. In order to find a function from nm to make sure it's not an unused weak function, the entries in the mcount_loc section needs to match the entries from nm. Since it can be an instruction before the entry, add a before_func variable that ARM 64 can set to 8, and if the mcount_loc entry is within 8 bytes of the nm function entry, then it will be considered a match. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Masahiro Yamada Cc: Catalin Marinas Cc: Will Deacon Cc: "Arnd Bergmann" Cc: Mark Brown Link: https://lore.kernel.org/20250225182054.815536219@goodmis.org Fixes: ef378c3b82338 ("scripts/sorttable: Zero out weak functions in mcount_loc table") Tested-by: Nathan Chancellor Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Use normal sort if theres no relocs in the mcount section

2025-02-25T18:25:13+00:00

When ARM 64 is compiled with gcc, the mcount_loc section will be filled with zeros and the addresses will be located in the Elf_Rela sections. To sort the mcount_loc section, the addresses from the Elf_Rela need to be placed into an array and that is sorted. But when ARM 64 is compiled with clang, it does it the same way as other architectures and leaves the addresses as is in the mcount_loc section. To handle both cases, ARM 64 will first try to sort the Elf_Rela section, and if it doesn't find any functions, it will then fall back to the sorting of the addresses in the mcount_loc section itself. Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Masahiro Yamada Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Brown Link: https://lore.kernel.org/20250225182054.648398403@goodmis.org Fixes: b3d09d06e052 ("arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64") Reported-by: "Arnd Bergmann" Tested-by: Nathan Chancellor Closes: https://lore.kernel.org/all/893cd8f1-8585-4d25-bf0f-4197bf872465@app.fastmail.com/ Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Zero out weak functions in mcount_loc table

2025-02-18T22:12:03+00:00

When a function is annotated as "weak" and is overridden, the code is not removed. If it is traced, the fentry/mcount location in the weak function will be referenced by the "__mcount_loc" section. This will then be added to the available_filter_functions list. Since only the address of the functions are listed, to find the name to show, a search of kallsyms is used. Since kallsyms will return the function by simply finding the function that the address is after but before the next function, an address of a weak function will show up as the function before it. This is because kallsyms does not save names of weak functions. This has caused issues in the past, as now the traced weak function will be listed in available_filter_functions with the name of the function before it. At best, this will cause the previous function's name to be listed twice. At worse, if the previous function was marked notrace, it will now show up as a function that can be traced. Note that it only shows up that it can be traced but will not be if enabled, which causes confusion. https://lore.kernel.org/all/20220412094923.0abe90955e5db486b7bca279@kernel.org/ The commit b39181f7c6907 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function") was a workaround to this by checking the function address before printing its name. If the address was too far from the function given by the name then instead of printing the name it would print: __ftrace_invalid_address___ The real issue is that these invalid addresses are listed in the ftrace table look up which available_filter_functions is derived from. A place holder must be listed in that file because set_ftrace_filter may take a series of indexes into that file instead of names to be able to do O(1) lookups to enable filtering (many tools use this method). Even if kallsyms saved the size of the function, it does not remove the need of having these place holders. The real solution is to not add a weak function into the ftrace table in the first place. To solve this, the sorttable.c code that sorts the mcount regions during the build is modified to take a "nm -S vmlinux" input, sort it, and any function listed in the mcount_loc section that is not within a boundary of the function list given by nm is considered a weak function and is zeroed out. Note, this does not mean they will remain zero when booting as KASLR will still shift those addresses. To handle this, the entries in the mcount_loc section will be ignored if they are zero or match the kaslr_offset() value. Before: ~# grep __ftrace_invalid_address___ /sys/kernel/tracing/available_filter_functions | wc -l 551 After: ~# grep __ftrace_invalid_address___ /sys/kernel/tracing/available_filter_functions | wc -l 0 Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Cc: Heiko Carstens Cc: Catalin Marinas Cc: Will Deacon Cc: Vasily Gorbik Cc: Alexander Gordeev Link: https://lore.kernel.org/20250218200022.883095980@goodmis.org Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Always use an array for the mcount_loc sorting

2025-02-18T22:12:03+00:00

The sorting of the mcount_loc section is done directly to the section for x86 and arm32 but it uses a separate array for arm64 as arm64 has the values for the mcount_loc stored in the rela sections of the vmlinux ELF file. In order to use the same code to remove weak functions, always use a separate array to do the sorting. This requires splitting up the filling of the array into one function and the placing the contents of the array back into the rela sections or into the mcount_loc section into a separate file. Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Cc: Heiko Carstens Cc: Catalin Marinas Cc: Will Deacon Cc: Vasily Gorbik Cc: Alexander Gordeev Link: https://lore.kernel.org/20250218200022.710676551@goodmis.org Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Have mcount rela sort use direct values

2025-02-18T22:12:03+00:00

The mcount_loc sorting for when the values are stored in the Elf_Rela entries uses the compare_extable() function to do the compares in the qsort(). That function does handle byte swapping if the machine being compiled for is a different endian than the host machine. But the sort_relocs() function sorts an array that pulled in the values from the Elf_Rela section and has already done the swapping. Create two new compare functions that will sort the direct values. One will sort 32 bit values and the other will sort the 64 bit value. One of these will be assigned to a compare_values function pointer and that will be used for sorting the Elf_Rela mcount values. Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Cc: Heiko Carstens Cc: Catalin Marinas Cc: Will Deacon Cc: Vasily Gorbik Cc: Alexander Gordeev Link: https://lore.kernel.org/20250218200022.538888594@goodmis.org Signed-off-by: Steven Rostedt (Google)

arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64

2025-02-18T22:12:03+00:00

The mcount_loc section holds the addresses of the functions that get patched by ftrace when enabling function callbacks. It can contain tens of thousands of entries. These addresses must be sorted. If they are not sorted at compile time, they are sorted at boot. Sorting at boot does take some time and does have a small impact on boot performance. x86 and arm32 have the addresses in the mcount_loc section of the ELF file. But for arm64, the section just contains zeros. The .rela.dyn Elf_Rela section holds the addresses and they get patched at boot during the relocation phase. In order to sort these addresses, the Elf_Rela needs to be updated instead of the location in the binary that holds the mcount_loc section. Have the sorttable code, allocate an array to hold the functions, load the addresses from the Elf_Rela entries, sort them, then put them back in order into the Elf_rela entries so that they will be sorted at boot up without having to sort them during boot up. Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Cc: Heiko Carstens Cc: Will Deacon Cc: Vasily Gorbik Cc: Alexander Gordeev Link: https://lore.kernel.org/20250218200022.373319428@goodmis.org Acked-by: Catalin Marinas Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Use a structure of function pointers for elf helpers

2025-01-10T12:59:04+00:00

Instead of having a series of function pointers that gets assigned to the Elf64 or Elf32 versions, put them all into a single structure and use that. Add the helper function that chooses the structure into the macros that build the different versions of the elf functions. Link: https://lore.kernel.org/all/CAHk-=wiafEyX7UgOeZgvd6fvuByE5WXUPh9599kwOc_d-pdeug@mail.gmail.com/ Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Cc: Stephen Rothwell Link: https://lore.kernel.org/20250110075459.13d4b94c@gandalf.local.home Suggested-by: Linus Torvalds Signed-off-by: Steven Rostedt (Google)

scripts/sorttable: Get start/stop_mcount_loc from ELF file directly

2025-01-08T03:36:39+00:00

The get_mcount_loc() does a cheesy trick to find the start_mcount_loc and stop_mcount_loc values. That trick is: file_start = popen(" grep start_mcount System.map | awk '{print $1}' ", "r"); and file_stop = popen(" grep stop_mcount System.map | awk '{print $1}' ", "r"); Those values are stored in the Elf symbol table. Use that to capture those values. Using the symbol table is more efficient and more robust. The above could fail if another variable had "start_mcount" or "stop_mcount" as part of its name. Cc: bpf Cc: Masami Hiramatsu Cc: Mark Rutland Cc: Mathieu Desnoyers Cc: Andrew Morton Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nicolas Schier Cc: Zheng Yejian Cc: Martin Kelly Cc: Christophe Leroy Cc: Josh Poimboeuf Link: https://lore.kernel.org/20250105162346.817157047@goodmis.org Signed-off-by: Steven Rostedt (Google)