Message ID | 20220224163711.185308-1-tz.stoyanov@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | trace-cruncher: Initial support for perf | expand |
On Thu, Feb 24, 2022 at 8:37 AM Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com> wrote: > > Two major functionalities are introduced by this patch set: > - VMA <-> function name resolving, using bfd library. Just wanted to point out that perf is often not built against libbfd: Please build perf against libbfd - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815 where long running addr2line is now the best performance solution: https://lore.kernel.org/linux-perf-users/20210909112202.1947499-1-tonyg@leastfixedpoint.com/ The comment from the bug: perf can link against libbfd if available, but the result is undistributable as they are licenced under GPL v2 and v3+ respectively. Thanks, Ian > - Support for Linux kernel perf framework, using perf library. > > This is still a work in progress. Depends on this patch, not yet merged: > https://lore.kernel.org/linux-perf-users/20220221102628.43904-1-tz.stoyanov@gmail.com/ > > Tzvetomir Stoyanov (VMware) (3): > trace-cruncher: Logic for resolving address to function name > trace-cruncher: Support for perf > trace-cruncher: perf example > > examples/perf_sampling.py | 51 +++ > setup.py | 9 +- > src/perfpy-utils.c | 699 ++++++++++++++++++++++++++++++ > src/perfpy-utils.h | 41 ++ > src/perfpy.c | 141 ++++++ > src/trace-obj-debug.c | 873 ++++++++++++++++++++++++++++++++++++++ > src/trace-obj-debug.h | 52 +++ > 7 files changed, 1865 insertions(+), 1 deletion(-) > create mode 100755 examples/perf_sampling.py > create mode 100644 src/perfpy-utils.c > create mode 100644 src/perfpy-utils.h > create mode 100644 src/perfpy.c > create mode 100644 src/trace-obj-debug.c > create mode 100644 src/trace-obj-debug.h > > -- > 2.34.1 >
On Thu, Feb 24, 2022 at 6:53 PM Ian Rogers <irogers@google.com> wrote: > > On Thu, Feb 24, 2022 at 8:37 AM Tzvetomir Stoyanov (VMware) > <tz.stoyanov@gmail.com> wrote: > > > > Two major functionalities are introduced by this patch set: > > - VMA <-> function name resolving, using bfd library. > > Just wanted to point out that perf is often not built against libbfd: > Please build perf against libbfd - > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815 > > where long running addr2line is now the best performance solution: > https://lore.kernel.org/linux-perf-users/20210909112202.1947499-1-tonyg@leastfixedpoint.com/ > > The comment from the bug: > perf can link against libbfd if available, but the result is > undistributable as they are licenced under GPL v2 and v3+ > respectively. > Hi Ian, thank you for this note. Trace-cruncher is a library licensed under LGPLv2.1, so it should not be a problem to use libbfd. Is my understanding correct, as I'm not an expert in all these licences ? > Thanks, > Ian > > > - Support for Linux kernel perf framework, using perf library. > > > > This is still a work in progress. Depends on this patch, not yet merged: > > https://lore.kernel.org/linux-perf-users/20220221102628.43904-1-tz.stoyanov@gmail.com/ > > > > Tzvetomir Stoyanov (VMware) (3): > > trace-cruncher: Logic for resolving address to function name > > trace-cruncher: Support for perf > > trace-cruncher: perf example > > > > examples/perf_sampling.py | 51 +++ > > setup.py | 9 +- > > src/perfpy-utils.c | 699 ++++++++++++++++++++++++++++++ > > src/perfpy-utils.h | 41 ++ > > src/perfpy.c | 141 ++++++ > > src/trace-obj-debug.c | 873 ++++++++++++++++++++++++++++++++++++++ > > src/trace-obj-debug.h | 52 +++ > > 7 files changed, 1865 insertions(+), 1 deletion(-) > > create mode 100755 examples/perf_sampling.py > > create mode 100644 src/perfpy-utils.c > > create mode 100644 src/perfpy-utils.h > > create mode 100644 src/perfpy.c > > create mode 100644 src/trace-obj-debug.c > > create mode 100644 src/trace-obj-debug.h > > > > -- > > 2.34.1 > >
On Fri, 25 Feb 2022 12:21:22 +0200 Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote: > > The comment from the bug: > > perf can link against libbfd if available, but the result is > > undistributable as they are licenced under GPL v2 and v3+ > > respectively. > > > > Hi Ian, thank you for this note. Trace-cruncher is a library licensed > under LGPLv2.1, so it should not be a problem to use libbfd. Is my > understanding correct, as I'm not an expert in all these licences ? trace-cruncher can link with libbfd as LGPLv2.1 is compatible with GPLv3. But note, this will limit what can link with trace-cruncher if it is distributed and provides a library. That is, if you have a trace-cruncher library, even though it is LGPLv2.1, because it links to a GPLv3 library, then anything that links to the trace-cruncher library must be GPLv3 compatible. This is why I separated some code out of trace-cmd (although that code has since been removed). I took GPL code, and used it in the binary of trace-cmd. But I kept the libtracecmd code separate, where as, the distributed libtracecmd code (that is LGPLv2.1) never contained any GPL code, nor did it depend on any. And now thinking about this more, and that we are starting to include libraries into libtracecmd (for compression and other things), we need to look carefully at the licenses for those libraries to make sure they do not impose any more restrictions than what LGPL has. The general rule of thumb is that you are constrained by the strictest rules of everything provided by a library. If any part of the library imposes a restriction, whatever links to that library must follow that restriction. -- Steve