On Thu, Oct 17, 2024, at 1:22 PM, Mark Wielaard wrote:
> I think (but haven't tried) only print_frame has to have a char *
> argument, print_inline_frames and print_frames can still pass around an
> Dwfl_Unwound_Source. Both print_frames and print_inline_frames can then
> call print_frame with t
Hi Serhei,
On Thu, 2024-10-17 at 13:13 -0400, Serhei Makarov wrote:
> On Thu, Oct 17, 2024, at 1:00 PM, Mark Wielaard wrote:
> > This part looks a little iffy IMHO.
> > It feels like a layering violation.
> > The meaning of DWFL_UNWOUND_INLINE is also different from the others.
> > There is no wor
On Thu, Oct 17, 2024, at 1:00 PM, Mark Wielaard wrote:
> This part looks a little iffy IMHO.
> It feels like a layering violation.
> The meaning of DWFL_UNWOUND_INLINE is also different from the others.
> There is no worst/best ordering here.
> They are not connected to frames.
>
> Is there a wa
Hi Serhei,
On Tue, 2024-10-15 at 11:26 -0400, Serhei Makarov wrote:
> Since we obtain diagnostics about unwind method, another logical place
> to show them is in eu-stack.
>
> This requires an additional pseudo-unwind type DWFL_UNWOUND_INLINE to
> clarify what happens with entries for inlined fun
Hi Serhei,
On Tue, Oct 15, 2024 at 11:29 AM Serhei Makarov wrote:
>
> Since we obtain diagnostics about unwind method, another logical place
> to show them is in eu-stack.
>
> This requires an additional pseudo-unwind type DWFL_UNWOUND_INLINE to
> clarify what happens with entries for inlined f
Since we obtain diagnostics about unwind method, another logical place
to show them is in eu-stack.
This requires an additional pseudo-unwind type DWFL_UNWOUND_INLINE to
clarify what happens with entries for inlined functions (which
eu-stacktrace does not display) based on the same Dwfl_Frame.
*
