Hello,

It used to have annotation_options for each command separately (for
example, perf report, annotate, and top), but we can make it global as
they never used together (with different settings).  This would save
some memory for each symbol when annotation is enabled.

This code is available at 'perf/annotate-option-v1' branch in

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (8):
  perf annotate: Introduce global annotation_options
  perf report: Convert to the global annotation_options
  perf top: Convert to the global annotation_options
  perf annotate: Use global annotation_options
  perf ui/browser/annotate: Use global annotation_options
  perf annotate: Ensure init/exit for global options
  perf annotate: Remove remaining usages of local annotation options
  perf annotate: Get rid of local annotation options

 tools/perf/builtin-annotate.c     |  43 +++++----
 tools/perf/builtin-report.c       |  37 ++++----
 tools/perf/builtin-top.c          |  45 +++++-----
 tools/perf/ui/browsers/annotate.c |  85 ++++++++----------
 tools/perf/ui/browsers/hists.c    |  34 +++----
 tools/perf/ui/browsers/hists.h    |   2 -
 tools/perf/util/annotate.c        | 142 +++++++++++++++---------------
 tools/perf/util/annotate.h        |  38 ++++----
 tools/perf/util/block-info.c      |   6 +-
 tools/perf/util/block-info.h      |   3 +-
 tools/perf/util/hist.h            |  25 ++----
 tools/perf/util/top.h             |   1 -
 12 files changed, 206 insertions(+), 255 deletions(-)


base-commit: 757489991f7c08603395b85037a981c31719c92c
-- 
2.43.0.rc1.413.gea7ed67945-goog

On Tue, Nov 28, 2023 at 9:54 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hello,
>
> It used to have annotation_options for each command separately (for
> example, perf report, annotate, and top), but we can make it global as
> they never used together (with different settings).  This would save
> some memory for each symbol when annotation is enabled.
>
> This code is available at 'perf/annotate-option-v1' branch in
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
>
> Thanks,
> Namhyung

Thanks for doing this and I think it is progress. I think there is a
common problem with having things be an option rather than say part of
session. Having a global variable seems unfortunate but I'm not sure
if in all locations we have easy access to the session. The rough
structure with annotations as I understand it is:

session has machines
a machine has dsos
a dso has symbols
a symbol has an annotation

Annotation is something of unfortunate abstraction as it covers things
like an IPC per symbol (why hard code to just IPC?) and things like
source files and line numbers.

A recent success story where we got rid of a configuration variable
was by switching to lazy allocation with sorting by name for symbols
within a dso. If we could have a lazy allocation model with
annotations then maybe we can do away with large hammers like global
options.

Thanks,
Ian




> Namhyung Kim (8):
>   perf annotate: Introduce global annotation_options
>   perf report: Convert to the global annotation_options
>   perf top: Convert to the global annotation_options
>   perf annotate: Use global annotation_options
>   perf ui/browser/annotate: Use global annotation_options
>   perf annotate: Ensure init/exit for global options
>   perf annotate: Remove remaining usages of local annotation options
>   perf annotate: Get rid of local annotation options
>
>  tools/perf/builtin-annotate.c     |  43 +++++----
>  tools/perf/builtin-report.c       |  37 ++++----
>  tools/perf/builtin-top.c          |  45 +++++-----
>  tools/perf/ui/browsers/annotate.c |  85 ++++++++----------
>  tools/perf/ui/browsers/hists.c    |  34 +++----
>  tools/perf/ui/browsers/hists.h    |   2 -
>  tools/perf/util/annotate.c        | 142 +++++++++++++++---------------
>  tools/perf/util/annotate.h        |  38 ++++----
>  tools/perf/util/block-info.c      |   6 +-
>  tools/perf/util/block-info.h      |   3 +-
>  tools/perf/util/hist.h            |  25 ++----
>  tools/perf/util/top.h             |   1 -
>  12 files changed, 206 insertions(+), 255 deletions(-)
>
>
> base-commit: 757489991f7c08603395b85037a981c31719c92c
> --
> 2.43.0.rc1.413.gea7ed67945-goog
>

Hi Ian,

On Tue, Nov 28, 2023 at 11:14 AM Ian Rogers <irogers@google.com> wrote:
>
> On Tue, Nov 28, 2023 at 9:54 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hello,
> >
> > It used to have annotation_options for each command separately (for
> > example, perf report, annotate, and top), but we can make it global as
> > they never used together (with different settings).  This would save
> > some memory for each symbol when annotation is enabled.
> >
> > This code is available at 'perf/annotate-option-v1' branch in
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> >
> > Thanks,
> > Namhyung
>
> Thanks for doing this and I think it is progress. I think there is a
> common problem with having things be an option rather than say part of
> session. Having a global variable seems unfortunate but I'm not sure
> if in all locations we have easy access to the session.

That's not the case when you deal with hist entry or TUI browser.
I think that's the reason we have the option in the annotation.


> The rough
> structure with annotations as I understand it is:
>
> session has machines
> a machine has dsos
> a dso has symbols
> a symbol has an annotation

That's true.  But the annotation struct is used only if
symbol__annotation_init() is called.

>
> Annotation is something of unfortunate abstraction as it covers things
> like an IPC per symbol (why hard code to just IPC?) and things like
> source files and line numbers.

Right, that's why I splitted the struct annotated_branch.

>
> A recent success story where we got rid of a configuration variable
> was by switching to lazy allocation with sorting by name for symbols
> within a dso. If we could have a lazy allocation model with
> annotations then maybe we can do away with large hammers like global
> options.

Maybe I can move the pointer to option into the annotated_source
which is allocated lazily.  But I don't think it needs to keep the option
for each symbol or annotation.  It's usually to control some display
behaviors in the disasm output globally.  So I think it's better to have
a global variable.

Thanks,
Namhyung

>
>
> > Namhyung Kim (8):
> >   perf annotate: Introduce global annotation_options
> >   perf report: Convert to the global annotation_options
> >   perf top: Convert to the global annotation_options
> >   perf annotate: Use global annotation_options
> >   perf ui/browser/annotate: Use global annotation_options
> >   perf annotate: Ensure init/exit for global options
> >   perf annotate: Remove remaining usages of local annotation options
> >   perf annotate: Get rid of local annotation options
> >
> >  tools/perf/builtin-annotate.c     |  43 +++++----
> >  tools/perf/builtin-report.c       |  37 ++++----
> >  tools/perf/builtin-top.c          |  45 +++++-----
> >  tools/perf/ui/browsers/annotate.c |  85 ++++++++----------
> >  tools/perf/ui/browsers/hists.c    |  34 +++----
> >  tools/perf/ui/browsers/hists.h    |   2 -
> >  tools/perf/util/annotate.c        | 142 +++++++++++++++---------------
> >  tools/perf/util/annotate.h        |  38 ++++----
> >  tools/perf/util/block-info.c      |   6 +-
> >  tools/perf/util/block-info.h      |   3 +-
> >  tools/perf/util/hist.h            |  25 ++----
> >  tools/perf/util/top.h             |   1 -
> >  12 files changed, 206 insertions(+), 255 deletions(-)
> >
> >
> > base-commit: 757489991f7c08603395b85037a981c31719c92c
> > --
> > 2.43.0.rc1.413.gea7ed67945-goog
> >

On Wed, Nov 29, 2023 at 3:56 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hi Ian,
>
> On Tue, Nov 28, 2023 at 11:14 AM Ian Rogers <irogers@google.com> wrote:
> >
> > On Tue, Nov 28, 2023 at 9:54 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > Hello,
> > >
> > > It used to have annotation_options for each command separately (for
> > > example, perf report, annotate, and top), but we can make it global as
> > > they never used together (with different settings).  This would save
> > > some memory for each symbol when annotation is enabled.
> > >
> > > This code is available at 'perf/annotate-option-v1' branch in
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> > >
> > > Thanks,
> > > Namhyung
> >
> > Thanks for doing this and I think it is progress. I think there is a
> > common problem with having things be an option rather than say part of
> > session. Having a global variable seems unfortunate but I'm not sure
> > if in all locations we have easy access to the session.
>
> That's not the case when you deal with hist entry or TUI browser.
> I think that's the reason we have the option in the annotation.
>
>
> > The rough
> > structure with annotations as I understand it is:
> >
> > session has machines
> > a machine has dsos
> > a dso has symbols
> > a symbol has an annotation
>
> That's true.  But the annotation struct is used only if
> symbol__annotation_init() is called.

Right. I find this approach likely to lead to errors, such as a symbol
created globally before symbol__annotation_init() was called breaking
the container_of assumptions.

> >
> > Annotation is something of unfortunate abstraction as it covers things
> > like an IPC per symbol (why hard code to just IPC?) and things like
> > source files and line numbers.
>
> Right, that's why I splitted the struct annotated_branch.
>
> >
> > A recent success story where we got rid of a configuration variable
> > was by switching to lazy allocation with sorting by name for symbols
> > within a dso. If we could have a lazy allocation model with
> > annotations then maybe we can do away with large hammers like global
> > options.
>
> Maybe I can move the pointer to option into the annotated_source
> which is allocated lazily.  But I don't think it needs to keep the option
> for each symbol or annotation.  It's usually to control some display
> behaviors in the disasm output globally.  So I think it's better to have
> a global variable.

Sgtm. My point wasn't to criticize, I think this is a good change, I
was just trying to imagine doing things in a way that could overall
reduce complexity

Thanks,
Ian

> Thanks,
> Namhyung
>
> >
> >
> > > Namhyung Kim (8):
> > >   perf annotate: Introduce global annotation_options
> > >   perf report: Convert to the global annotation_options
> > >   perf top: Convert to the global annotation_options
> > >   perf annotate: Use global annotation_options
> > >   perf ui/browser/annotate: Use global annotation_options
> > >   perf annotate: Ensure init/exit for global options
> > >   perf annotate: Remove remaining usages of local annotation options
> > >   perf annotate: Get rid of local annotation options
> > >
> > >  tools/perf/builtin-annotate.c     |  43 +++++----
> > >  tools/perf/builtin-report.c       |  37 ++++----
> > >  tools/perf/builtin-top.c          |  45 +++++-----
> > >  tools/perf/ui/browsers/annotate.c |  85 ++++++++----------
> > >  tools/perf/ui/browsers/hists.c    |  34 +++----
> > >  tools/perf/ui/browsers/hists.h    |   2 -
> > >  tools/perf/util/annotate.c        | 142 +++++++++++++++---------------
> > >  tools/perf/util/annotate.h        |  38 ++++----
> > >  tools/perf/util/block-info.c      |   6 +-
> > >  tools/perf/util/block-info.h      |   3 +-
> > >  tools/perf/util/hist.h            |  25 ++----
> > >  tools/perf/util/top.h             |   1 -
> > >  12 files changed, 206 insertions(+), 255 deletions(-)
> > >
> > >
> > > base-commit: 757489991f7c08603395b85037a981c31719c92c
> > > --
> > > 2.43.0.rc1.413.gea7ed67945-goog
> > >

On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
>
> On Wed, Nov 29, 2023 at 3:56 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > Hi Ian,
> >
> > On Tue, Nov 28, 2023 at 11:14 AM Ian Rogers <irogers@google.com> wrote:
> > >
> > > On Tue, Nov 28, 2023 at 9:54 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > > >
> > > > Hello,
> > > >
> > > > It used to have annotation_options for each command separately (for
> > > > example, perf report, annotate, and top), but we can make it global as
> > > > they never used together (with different settings).  This would save
> > > > some memory for each symbol when annotation is enabled.
> > > >
> > > > This code is available at 'perf/annotate-option-v1' branch in
> > > >
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> > > >
> > > > Thanks,
> > > > Namhyung
> > >
> > > Thanks for doing this and I think it is progress. I think there is a
> > > common problem with having things be an option rather than say part of
> > > session. Having a global variable seems unfortunate but I'm not sure
> > > if in all locations we have easy access to the session.
> >
> > That's not the case when you deal with hist entry or TUI browser.
> > I think that's the reason we have the option in the annotation.
> >
> >
> > > The rough
> > > structure with annotations as I understand it is:
> > >
> > > session has machines
> > > a machine has dsos
> > > a dso has symbols
> > > a symbol has an annotation
> >
> > That's true.  But the annotation struct is used only if
> > symbol__annotation_init() is called.
>
> Right. I find this approach likely to lead to errors, such as a symbol
> created globally before symbol__annotation_init() was called breaking
> the container_of assumptions.

Sure, but that's a different issue.  Maybe we can add a hash table
to map a symbol to annotation or annotated_source directly.  But
I don't think we need annotation_option for each symbol/annotation.

>
> > >
> > > Annotation is something of unfortunate abstraction as it covers things
> > > like an IPC per symbol (why hard code to just IPC?) and things like
> > > source files and line numbers.
> >
> > Right, that's why I splitted the struct annotated_branch.
> >
> > >
> > > A recent success story where we got rid of a configuration variable
> > > was by switching to lazy allocation with sorting by name for symbols
> > > within a dso. If we could have a lazy allocation model with
> > > annotations then maybe we can do away with large hammers like global
> > > options.
> >
> > Maybe I can move the pointer to option into the annotated_source
> > which is allocated lazily.  But I don't think it needs to keep the option
> > for each symbol or annotation.  It's usually to control some display
> > behaviors in the disasm output globally.  So I think it's better to have
> > a global variable.
>
> Sgtm. My point wasn't to criticize, I think this is a good change, I
> was just trying to imagine doing things in a way that could overall
> reduce complexity

Yep, thanks for your review.  Can I get your ACKs? :)
Namhyung

On Mon, Dec 4, 2023 at 2:46 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
> >
> > On Wed, Nov 29, 2023 at 3:56 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > Hi Ian,
> > >
> > > On Tue, Nov 28, 2023 at 11:14 AM Ian Rogers <irogers@google.com> wrote:
> > > >
> > > > On Tue, Nov 28, 2023 at 9:54 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > It used to have annotation_options for each command separately (for
> > > > > example, perf report, annotate, and top), but we can make it global as
> > > > > they never used together (with different settings).  This would save
> > > > > some memory for each symbol when annotation is enabled.
> > > > >
> > > > > This code is available at 'perf/annotate-option-v1' branch in
> > > > >
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> > > > >
> > > > > Thanks,
> > > > > Namhyung
> > > >
> > > > Thanks for doing this and I think it is progress. I think there is a
> > > > common problem with having things be an option rather than say part of
> > > > session. Having a global variable seems unfortunate but I'm not sure
> > > > if in all locations we have easy access to the session.
> > >
> > > That's not the case when you deal with hist entry or TUI browser.
> > > I think that's the reason we have the option in the annotation.
> > >
> > >
> > > > The rough
> > > > structure with annotations as I understand it is:
> > > >
> > > > session has machines
> > > > a machine has dsos
> > > > a dso has symbols
> > > > a symbol has an annotation
> > >
> > > That's true.  But the annotation struct is used only if
> > > symbol__annotation_init() is called.
> >
> > Right. I find this approach likely to lead to errors, such as a symbol
> > created globally before symbol__annotation_init() was called breaking
> > the container_of assumptions.
>
> Sure, but that's a different issue.  Maybe we can add a hash table
> to map a symbol to annotation or annotated_source directly.  But
> I don't think we need annotation_option for each symbol/annotation.

Agreed.

> >
> > > >
> > > > Annotation is something of unfortunate abstraction as it covers things
> > > > like an IPC per symbol (why hard code to just IPC?) and things like
> > > > source files and line numbers.
> > >
> > > Right, that's why I splitted the struct annotated_branch.
> > >
> > > >
> > > > A recent success story where we got rid of a configuration variable
> > > > was by switching to lazy allocation with sorting by name for symbols
> > > > within a dso. If we could have a lazy allocation model with
> > > > annotations then maybe we can do away with large hammers like global
> > > > options.
> > >
> > > Maybe I can move the pointer to option into the annotated_source
> > > which is allocated lazily.  But I don't think it needs to keep the option
> > > for each symbol or annotation.  It's usually to control some display
> > > behaviors in the disasm output globally.  So I think it's better to have
> > > a global variable.
> >
> > Sgtm. My point wasn't to criticize, I think this is a good change, I
> > was just trying to imagine doing things in a way that could overall
> > reduce complexity
>
> Yep, thanks for your review.  Can I get your ACKs? :)

For the series:
Reviewed-by: Ian Rogers <irogers@google.com>

Thanks,
Ian

> Namhyung

Em Tue, Dec 05, 2023 at 09:59:02AM -0800, Ian Rogers escreveu:
> On Mon, Dec 4, 2023 at 2:46 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
> > > Sgtm. My point wasn't to criticize, I think this is a good change, I
> > > was just trying to imagine doing things in a way that could overall
> > > reduce complexity

> > Yep, thanks for your review.  Can I get your ACKs? :)

> For the series:
> Reviewed-by: Ian Rogers <irogers@google.com>

Thanks, applied to perf-tools-next.

- Arnaldo

Em Thu, Dec 07, 2023 at 04:50:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Dec 05, 2023 at 09:59:02AM -0800, Ian Rogers escreveu:
> > On Mon, Dec 4, 2023 at 2:46 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > > On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
> > > > Sgtm. My point wasn't to criticize, I think this is a good change, I
> > > > was just trying to imagine doing things in a way that could overall
> > > > reduce complexity
> 
> > > Yep, thanks for your review.  Can I get your ACKs? :)
> 
> > For the series:
> > Reviewed-by: Ian Rogers <irogers@google.com>
> 
> Thanks, applied to perf-tools-next.


Now trying to fix this:

  CC      bench/numa.o
  CC      tests/hists_cumulate.o
ui/gtk/annotate.c: In function ‘symbol__gtk_annotate’:
ui/gtk/annotate.c:179:43: error: passing argument 3 of ‘symbol__annotate’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  179 |         err = symbol__annotate(ms, evsel, options, NULL);
      |                                           ^~~~~~~
      |                                           |
      |                                           struct annotation_options *
In file included from ui/gtk/annotate.c:5:
/home/acme/git/perf-tools-next/tools/perf/util/annotate.h:376:36: note: expected ‘struct arch **’ but argument is of type ‘struct annotation_options *’
  376 |                      struct arch **parch);
      |                      ~~~~~~~~~~~~~~^~~~~
ui/gtk/annotate.c:179:15: error: too many arguments to function ‘symbol__annotate’
  179 |         err = symbol__annotate(ms, evsel, options, NULL);
      |               ^~~~~~~~~~~~~~~~
/home/acme/git/perf-tools-next/tools/perf/util/annotate.h:374:5: note: declared here
  374 | int symbol__annotate(struct map_symbol *ms,
      |     ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
  CC      tests/python-use.o
  CC      trace/beauty/sockaddr.o
  CC      arch/x86/util/topdown.o
make[6]: *** [/home/acme/git/perf-tools-next/tools/build/Makefile.build:105: ui/gtk/annotate.o] Error 1
make[6]: *** Waiting for unfinished jobs....
  CC      arch/x86/util/machine.o

On Thu, Dec 7, 2023 at 11:52 AM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> Em Thu, Dec 07, 2023 at 04:50:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Tue, Dec 05, 2023 at 09:59:02AM -0800, Ian Rogers escreveu:
> > > On Mon, Dec 4, 2023 at 2:46 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > > > On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
> > > > > Sgtm. My point wasn't to criticize, I think this is a good change, I
> > > > > was just trying to imagine doing things in a way that could overall
> > > > > reduce complexity
> >
> > > > Yep, thanks for your review.  Can I get your ACKs? :)
> >
> > > For the series:
> > > Reviewed-by: Ian Rogers <irogers@google.com>
> >
> > Thanks, applied to perf-tools-next.
>
>
> Now trying to fix this:
>
>   CC      bench/numa.o
>   CC      tests/hists_cumulate.o
> ui/gtk/annotate.c: In function ‘symbol__gtk_annotate’:
> ui/gtk/annotate.c:179:43: error: passing argument 3 of ‘symbol__annotate’ from incompatible pointer type [-Werror=incompatible-pointer-types]
>   179 |         err = symbol__annotate(ms, evsel, options, NULL);
>       |                                           ^~~~~~~
>       |                                           |
>       |                                           struct annotation_options *
> In file included from ui/gtk/annotate.c:5:
> /home/acme/git/perf-tools-next/tools/perf/util/annotate.h:376:36: note: expected ‘struct arch **’ but argument is of type ‘struct annotation_options *’
>   376 |                      struct arch **parch);
>       |                      ~~~~~~~~~~~~~~^~~~~
> ui/gtk/annotate.c:179:15: error: too many arguments to function ‘symbol__annotate’
>   179 |         err = symbol__annotate(ms, evsel, options, NULL);
>       |               ^~~~~~~~~~~~~~~~
> /home/acme/git/perf-tools-next/tools/perf/util/annotate.h:374:5: note: declared here
>   374 | int symbol__annotate(struct map_symbol *ms,
>       |     ^~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>   CC      tests/python-use.o
>   CC      trace/beauty/sockaddr.o
>   CC      arch/x86/util/topdown.o
> make[6]: *** [/home/acme/git/perf-tools-next/tools/build/Makefile.build:105: ui/gtk/annotate.o] Error 1
> make[6]: *** Waiting for unfinished jobs....
>   CC      arch/x86/util/machine.o

Maybe a signal to remove the gtk support :-)

Ian

On Thu, Dec 7, 2023 at 12:14 PM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Dec 7, 2023 at 11:52 AM Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> >
> > Em Thu, Dec 07, 2023 at 04:50:30PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Dec 05, 2023 at 09:59:02AM -0800, Ian Rogers escreveu:
> > > > On Mon, Dec 4, 2023 at 2:46 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > > > > On Thu, Nov 30, 2023 at 10:37 AM Ian Rogers <irogers@google.com> wrote:
> > > > > > Sgtm. My point wasn't to criticize, I think this is a good change, I
> > > > > > was just trying to imagine doing things in a way that could overall
> > > > > > reduce complexity
> > >
> > > > > Yep, thanks for your review.  Can I get your ACKs? :)
> > >
> > > > For the series:
> > > > Reviewed-by: Ian Rogers <irogers@google.com>
> > >
> > > Thanks, applied to perf-tools-next.
> >
> >
> > Now trying to fix this:
> >
> >   CC      bench/numa.o
> >   CC      tests/hists_cumulate.o
> > ui/gtk/annotate.c: In function ‘symbol__gtk_annotate’:
> > ui/gtk/annotate.c:179:43: error: passing argument 3 of ‘symbol__annotate’ from incompatible pointer type [-Werror=incompatible-pointer-types]
> >   179 |         err = symbol__annotate(ms, evsel, options, NULL);
> >       |                                           ^~~~~~~
> >       |                                           |
> >       |                                           struct annotation_options *
> > In file included from ui/gtk/annotate.c:5:
> > /home/acme/git/perf-tools-next/tools/perf/util/annotate.h:376:36: note: expected ‘struct arch **’ but argument is of type ‘struct annotation_options *’
> >   376 |                      struct arch **parch);
> >       |                      ~~~~~~~~~~~~~~^~~~~
> > ui/gtk/annotate.c:179:15: error: too many arguments to function ‘symbol__annotate’
> >   179 |         err = symbol__annotate(ms, evsel, options, NULL);
> >       |               ^~~~~~~~~~~~~~~~
> > /home/acme/git/perf-tools-next/tools/perf/util/annotate.h:374:5: note: declared here
> >   374 | int symbol__annotate(struct map_symbol *ms,
> >       |     ^~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >   CC      tests/python-use.o
> >   CC      trace/beauty/sockaddr.o
> >   CC      arch/x86/util/topdown.o
> > make[6]: *** [/home/acme/git/perf-tools-next/tools/build/Makefile.build:105: ui/gtk/annotate.o] Error 1
> > make[6]: *** Waiting for unfinished jobs....
> >   CC      arch/x86/util/machine.o
>
> Maybe a signal to remove the gtk support :-)

+1

Thanks,
Namhyung