Florian Weimer writes:
> * Mark Wielaard:
>
>> On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
>
>>> If the unwind information is incomplete, this …
>>>
>>> > 7) signal handler unwinds the calling thread however it wants (and can
>>> > sleep and take page faults if needed)
>>>
>>> … m
Mark Wielaard writes:
> Hi Florian,
>
> On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>> > See, both pro-FP and anti-FP camps think that it's the kernel that has
>> > to do the unwinding unless we copy whole
Florian Weimer writes:
> * Daniel Colascione:
>
>> See, both pro-FP and anti-FP camps think that it's the kernel that has
>> to do the unwinding unless we copy whole stacks into traces.
>
> Well, I think we should explore hardware-assisted backtraces (shadow
> st
> Having the vDSO do the unwinding allows the unwinding to be entirely
transparent to userspace programs and libraries
Why *should* unwinding be transparent to userspace programs and libraries?
Userspace can contribute to making unwinding better, especially in the managed
case, by hooking into t
> Could the vDSO do the unwinding?
The vDSO is just userspace code that happens to be provided by the kernel, so,
sure, a function in vDSO *could* unwind. But why would it? What would be the
advantage of doing that over putting the unwinding in libc? To change the vDSO,
you have to change the k
> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione wrote:
>
> This sounds great, but how is it going to get made?
Someone has to do it. :-) I've been thinking about adding this mechanism for a
few years, but haven't had time so far. I suppose the first step would be
rai
Frame pointers also have the disadvantage of working only with AOT-compiled
languages for which a trace analysis tool can associate an instruction pointer
with a semantically-relevant bit of code. If you try to use frame pointers to
profile a Python program, all you're going to get is a profile
