On Mon, Dec 30, 2024 at 01:11:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > Not really :-\
> >
> > root@number:/home/acme/git/pahole# pfunct --decl_info -F dwarf evtchn_fifo_is_pending /lib/modules/6.13.0-rc2/build/vmlinux
> > /* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c */
> > /* <946502e> /home/acme/git/linux/drivers/xen/events/events_fifo.c:206 */
> > bool evtchn_fifo_is_pending(evtchn_port_t port);
> > /* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c */
> > /* <946502e> /home/acme/git/linux/drivers/xen/events/events_fifo.c:206 */
> > bool evtchn_fifo_is_pending(evtchn_port_t port);
> > root@number:/home/acme/git/pahole#
> >
> > So far I couldn't find an explanation for this oddity... Lets see if
> > after applying all patches we get past this.
> Its not related to this patch series, before we get two outputs for
> these (and other functions in
> /home/acme/git/linux/drivers/xen/events/events_fifo.c).
>
> Still investigating.
root@number:/home/acme/git/pahole# perf probe -x ~/bin/pfunct function__show
Added new event:
probe_pfunct:function_show (on function__show in /home/acme/git/pahole/build/pfunct)
You can now use it in all perf tools, such as:
perf record -e probe_pfunct:function_show -aR sleep 1
root@number:/home/acme/git/pahole# perf trace -e probe_pfunct:function_show --call-graph dwarf pfunct --decl_info -F dwarf evtchn_fifo_set_pending /lib/modules/6.13.0-rc2/build/vmlinux
/* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c */
/* <946517a> /home/acme/git/linux/drivers/xen/events/events_fifo.c:200 */
void evtchn_fifo_set_pending(evtchn_port_t port);
/* Used at: /home/acme/git/linux/drivers/xen/events/events_fifo.c */
/* <946517a> /home/acme/git/linux/drivers/xen/events/events_fifo.c:200 */
void evtchn_fifo_set_pending(evtchn_port_t port);
0.000 pfunct/2006089 probe_pfunct:function_show(__probe_ip: 4208235)
function__show (/home/acme/git/pahole/build/pfunct)
pfunct_stealer (/home/acme/git/pahole/build/pfunct)
cus__steal_now (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
dwarf_loader__worker_thread (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
start_thread (/usr/lib64/libc.so.6)
clone3 (/usr/lib64/libc.so.6)
0.134 pfunct/2006088 probe_pfunct:function_show(__probe_ip: 4208235)
function__show (/home/acme/git/pahole/build/pfunct)
cu_function_iterator (/home/acme/git/pahole/build/pfunct)
cus__for_each_cu (/home/acme/git/pahole/build/libdwarves.so.1.0.0)
main (/home/acme/git/pahole/build/pfunct)
__libc_start_call_main (/usr/lib64/libc.so.6)
__libc_start_main@@GLIBC_2.34 (/usr/lib64/libc.so.6)
_start (/home/acme/git/pahole/build/pfunct)
root@number:/home/acme/git/pahole#
With the following patch we get just one output for this case, but that
isn't the right solution... I'll look on removing the
cu_function_iterator() based printing, otherwise when printing all
matches we'll still duplicate the printings.
Anyway, doesn't seem related to the problem that tests/tests was
catching, that I'm not being able to reproduce anymore after having the
whole series applied, probably some race?
- Arnaldo
diff --git a/pfunct.c b/pfunct.c
index 55eafe8a8e790dcb..9645b004381a7e1e 100644
--- a/pfunct.c
+++ b/pfunct.c
@@ -518,7 +518,13 @@ static enum load_steal_kind pfunct_stealer(struct cu *cu,
if (tag) {
function__show(tag__function(tag), cu);
- return show_all_matches ? LSK__DELETE : LSK__STOP_LOADING;
+ if (!show_all_matches) {
+ // Expedite exit, since we already did what was requested:
+ // print the first occurrence of a given function
+ exit(0);
+ }
+
+ return LSK__DELETE;
}
} else if (class_name) {
cu_class_iterator(cu, class_name);
