[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250305104749.15e57b19@gandalf.local.home>
Date: Wed, 5 Mar 2025 10:47:49 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Huang Shijie <shijie@...amperecomputing.com>,
patches@...erecomputing.com, cl@...ux.com, yang@...amperecomputing.com,
peterz@...radead.org, jpoimboe@...nel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH resend ] tracepoint: Print the function symbol when
tracepoint_debug is set
On Wed, 5 Mar 2025 08:53:43 -0500
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> On 2025-03-04 20:55, Huang Shijie wrote:
> > When tracepoint_debug is set, we may get the output in kernel log:
> > [ 380.013843] Probe 0 : 00000000f0d68cda
> >
> > It is not readable, so change to print the function symbol.
> > After this patch, the output may becomes:
> > [ 54.930567] Probe 0 : perf_trace_sched_wakeup_template
>
> What would it print if the address is corrupted ?
>
> Perhaps we could do like the backtrace code and print e.g.
>
> [<00000000f0d68cda>] perf_trace_sched_wakeup_template+0xNN/0xMM
>
> ?
>
> I don't care about the actual layout, but removing the address
> from the formatted output appears to be removing useful data
> in debug situations.
>
Perhaps this can use "%pS" which shows both the function entry and the
offset. If no function is found, it ends up being the same as "%p".
Also, it's likely that the "%p" is hashed here and one couldn't use it to
debug either.
-- Steve
Powered by blists - more mailing lists