On Wed, Jan 18, 2023 at 03:01:19PM +0100, Florian Weimer wrote:
> > 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)
> >>
> >> … might encounter segmentation faults and terminate the process. So
> >> far, incorrect unwind information (whether it's a clobbered frame
> >> pointer, or missing DWARF information about clobbered registers) is not
> >> a problem, but it's kind of hard to validate this information from
> >> within the process itself. Maybe we'd have to add a magic memcpy first
> >> to the vDSO, which the kernel recognizes based on the code addresses,
> >> and suppresses sending the signal for it.
> >
> > Yeah, I am not too afraid of that happening with an .eh_frame based
> > unwinder unless someone deliberately produced a bad table (or dlcloses
> > a library which still has code on the call stack). You still have to be
> > careful about the stack bounds of course.
>
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines. We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if that's
> going to be useful for the desktop.
I think some JITs register their on the fly created unwind info using
__{,de}register_frame_info* APIs (at least I think that was the reason
of Thomas Neumann's libgcc unwinder changes).
Jakub
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
