On Wed, 2 Jul 2025 14:57:22 +0200 Jens Remus <jremus@xxxxxxxxxxxxx> wrote: > Hello Steve! > > On 01.07.2025 20:49, Steven Rostedt wrote: > > This code is based on top of: > > > > https://lore.kernel.org/linux-trace-kernel/20250701005321.942306427@xxxxxxxxxxx/ > > git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git unwind/core > > > > This is the implementation of parsing the SFrame section in an ELF file. > > ... > > > The code for this patch series can be found here: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git unwind/sframe > > Wouldn't it make sense to include your related perf (tools) series [1] > in that branch to ease testing? Provided you also include the minor > fix [2] to make perf tools work. :-) I was planning on making a branch with perf and sframe merged (haven't pushed it out yet). Since sframe doesn't technically rely on it (I use tracing too test it too) I'm keeping them separate. > > Additionally it would make sense to include the patches from Josh that > add SFrame information to the vDSO on x86 [3]. > > [1]: [PATCH v12 00/11] perf: Support the deferred unwinding infrastructure, > https://lore.kernel.org/linux-trace-kernel/20250701180410.755491417@xxxxxxxxxxx/ > > [2]: https://lore.kernel.org/linux-trace-kernel/51903e66-56bc-42a4-b80c-9c3223e2a48a@xxxxxxxxxxxxx/ > > [3]: [PATCH v6 0/6] x86/vdso: VDSO updates and fixes for sframes, > https://lore.kernel.org/all/20250425023750.669174660@xxxxxxxxxxx/ I have them in separate branches too and will be posting them separately. Again, the "merged" branch will contain them all. > > > Changes since v6: https://lore.kernel.org/linux-trace-kernel/20250617225009.233007152@xxxxxxxxxxx/ > > > - Moved the addition of the prctl(), that allows libraries to add the elf > > sections to the kernel, to the last patch and labeled it as "DO NOT APPLY". > > This should instead be a proper system call and work to make it robust and > > flexible still needs to be done. The prctl() patch is added for debugging > > purposes only. > > Does PR_SET_VMA [4] create a precedent case for the SFrame prctls? > > [4]: https://man7.org/linux/man-pages/man2/pr_set_vma.2const.html > At the last sframe meeting we came to the decision to make it a proper system call. Just seems cleaner that way. If others feel prctl() is the way to go, we can definitely do that too. -- Steve
