On 2018-11-02, Masami Hiramatsu wrote:
> On Thu, 1 Nov 2018 21:49:48 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-01, Masami Hiramatsu wrote:
> > > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > > this issue for generic solution (e.g. for the arch which
On 2018-11-02, Masami Hiramatsu wrote:
> On Thu, 1 Nov 2018 21:49:48 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-01, Masami Hiramatsu wrote:
> > > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > > this issue for generic solution (e.g. for the arch which
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> On 2018-11-01, Masami Hiramatsu wrote:
> > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > > supports retstack).
> > > >
> > > > I
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> On 2018-11-01, Masami Hiramatsu wrote:
> > > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > > supports retstack).
> > > >
> > > > I
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> > > Should I continue working on this patchset?
> >
> > Yes, until we finally introduce Steven's algorithm on all arch (yeah, we
> > still
> > have some archs which don't support graph-tracer but supports kprobes),
> > I think your
On Thu, 1 Nov 2018 21:49:48 +1100
Aleksa Sarai wrote:
> > > Should I continue working on this patchset?
> >
> > Yes, until we finally introduce Steven's algorithm on all arch (yeah, we
> > still
> > have some archs which don't support graph-tracer but supports kprobes),
> > I think your
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
On Thu, 1 Nov 2018 00:39:12 +1100
Aleksa Sarai wrote:
> On 2018-10-31, Steven Rostedt wrote:
> > > Anyway, until that merge happens, this patch looks good to avoid
> > > this issue for generic solution (e.g. for the arch which doesn't
> > > supports retstack).
> >
> > I think its time to come
On Thu, 1 Nov 2018 00:39:12 +1100
Aleksa Sarai wrote:
> On 2018-10-31, Steven Rostedt wrote:
> > > Anyway, until that merge happens, this patch looks good to avoid
> > > this issue for generic solution (e.g. for the arch which doesn't
> > > supports retstack).
> >
> > I think its time to come
On Tue, 30 Oct 2018 14:19:53 +1100
Aleksa Sarai wrote:
> On 2018-10-30, Masami Hiramatsu wrote:
> > > Historically, kretprobe has always produced unusable stack traces
> > > (kretprobe_trampoline is the only entry in most cases, because of the
> > > funky stack pointer overwriting). This has
On Tue, 30 Oct 2018 14:19:53 +1100
Aleksa Sarai wrote:
> On 2018-10-30, Masami Hiramatsu wrote:
> > > Historically, kretprobe has always produced unusable stack traces
> > > (kretprobe_trampoline is the only entry in most cases, because of the
> > > funky stack pointer overwriting). This has
On 2018-10-31, Steven Rostedt wrote:
> > Anyway, until that merge happens, this patch looks good to avoid
> > this issue for generic solution (e.g. for the arch which doesn't
> > supports retstack).
>
> I think its time to come up with an algorithm that makes function graph
> work with multiple
On 2018-10-31, Steven Rostedt wrote:
> > Anyway, until that merge happens, this patch looks good to avoid
> > this issue for generic solution (e.g. for the arch which doesn't
> > supports retstack).
>
> I think its time to come up with an algorithm that makes function graph
> work with multiple
On Tue, 30 Oct 2018 10:12:06 +0900
Masami Hiramatsu wrote:
> Anyway, until that merge happens, this patch looks good to avoid
> this issue for generic solution (e.g. for the arch which doesn't
> supports retstack).
I think its time to come up with an algorithm that makes function graph
work
On Tue, 30 Oct 2018 10:12:06 +0900
Masami Hiramatsu wrote:
> Anyway, until that merge happens, this patch looks good to avoid
> this issue for generic solution (e.g. for the arch which doesn't
> supports retstack).
I think its time to come up with an algorithm that makes function graph
work
On 2018-10-30, Masami Hiramatsu wrote:
> > Historically, kretprobe has always produced unusable stack traces
> > (kretprobe_trampoline is the only entry in most cases, because of the
> > funky stack pointer overwriting). This has caused quite a few annoyances
> > when using tracing to debug
On 2018-10-30, Masami Hiramatsu wrote:
> > Historically, kretprobe has always produced unusable stack traces
> > (kretprobe_trampoline is the only entry in most cases, because of the
> > funky stack pointer overwriting). This has caused quite a few annoyances
> > when using tracing to debug
Hi Aleksa,
On Sat, 27 Oct 2018 00:22:10 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using
Hi Aleksa,
On Sat, 27 Oct 2018 00:22:10 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using
Historically, kretprobe has always produced unusable stack traces
(kretprobe_trampoline is the only entry in most cases, because of the
funky stack pointer overwriting). This has caused quite a few annoyances
when using tracing to debug problems[1] -- since return values are only
available with
Historically, kretprobe has always produced unusable stack traces
(kretprobe_trampoline is the only entry in most cases, because of the
funky stack pointer overwriting). This has caused quite a few annoyances
when using tracing to debug problems[1] -- since return values are only
available with
22 matches
Mail list logo
