On Fri, 29 Aug 2025 19:09:35 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> Yeah, we could add an optimization to store vma's in the callchain walk to
> see if the next call chain belongs to a previous one. Could even just cache
> the previous vma, as it's not as common to have one library calling into
> another and back again.
Although, it does happen with libc. :-p
cookie=300000004
=> <000000000008f687> : 0x666220af
=> <0000000000014560> : 0x88512fee
=> <000000000001f94a> : 0x88512fee
=> <000000000001fc9e> : 0x88512fee
=> <000000000001fcfa> : 0x88512fee
=> <000000000000ebae> : 0x88512fee
=> <0000000000029ca8> : 0x666220af
The 0x666220af is libc, where the first item is (according to objdump):
000000000008f570 <__libc_alloca_cutoff@@GLIBC_PRIVATE>:
And the last one (top of the stack) is:
0000000000029c20 <__libc_init_first@@GLIBC_2.2.5>:
Of course libc starts the application, and then the application will likely
call back into libc. We could optimize for this case with:
first_vma = NULL;
vma = NULL;
foreach addr in callchain
if (!first_vma)
vma = first_vma = vma_alloc()
else if (addr in range of first_vma)
vma = first_vma
else (addr not in range of vma)
vma = vma_lookup(addr);
-- Steve
