[PATCH dwarves] libbpf: allow to use packaged version

[PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
embedded version and the system version (searched via pkg-config)
of libbpf. Set the system version as the default.

Signed-off-by: Luca Boccassi <bluca@debian.org>
---
Note: I can switch the default around if you prefer.

 CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++-------------
 btf_encoder.c    |  5 +++++
 btf_loader.c     |  4 ++++
 libbtf.c         |  6 ++++++
 libbtf.h         |  4 ++++
 pahole.c         |  4 ++++
 pahole_strings.h |  4 ++++
 strings.c        |  4 ++++
 8 files changed, 67 insertions(+), 13 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 857487a..4c6b079 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,9 +2,23 @@ project(pahole C)
 cmake_minimum_required(VERSION 2.8.8)
 cmake_policy(SET CMP0005 NEW)
 
+option(LIBBPF_EMBEDDED "Use the embedded version of libbpf instead of searching it via pkg-config" OFF)
+if (NOT LIBBPF_EMBEDDED)
+	find_package(PkgConfig)
+	if(PKGCONFIG_FOUND)
+		pkg_check_modules(LIBBPF libbpf>=0.3.0)
+	endif()
+endif()
+
 INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+		    ${CMAKE_CURRENT_SOURCE_DIR})
+if(NOT LIBBPF_FOUND)
+	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+else()
+	INCLUDE_DIRECTORIES(${LIBBPF_INCLUDE_DIRS})
+	LINK_DIRECTORIES(${LIBBPF_LIBRARY_DIRS})
+	ADD_DEFINITIONS(-DLIBBPF_FOUND)
+endif()
 
 # Try to parse this later, Helio just showed me a KDE4 example to support
 # x86-64 builds.
@@ -56,7 +70,7 @@ if(GIT_FOUND AND EXISTS "${PROJECT_SOURCE_DIR}/.git")
 		endif()
 	endif()
 endif()
-if(NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
+if(NOT LIBBPF_FOUND AND NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
 	message(FATAL_ERROR "The submodules were not downloaded! GIT_SUBMODULE was turned off or failed. Please update submodules and try again.")
 endif()
 
@@ -81,22 +95,31 @@ endif()
 
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64")
 
-file(GLOB libbpf_sources "lib/bpf/src/*.c")
-add_library(bpf OBJECT ${libbpf_sources})
-set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
-target_include_directories(bpf PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+if (NOT LIBBPF_FOUND)
+	file(GLOB libbpf_sources "lib/bpf/src/*.c")
+	add_library(bpf OBJECT ${libbpf_sources})
+	set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
+	target_include_directories(bpf PRIVATE
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+endif()
 
 set(dwarves_LIB_SRCS dwarves.c dwarves_fprintf.c gobuffer strings
 		     ctf_encoder.c ctf_loader.c libctf.c btf_encoder.c btf_loader.c libbtf.c
 		     dwarf_loader.c dutil.c elf_symtab.c rbtree.c)
-add_library(dwarves SHARED ${dwarves_LIB_SRCS} $<TARGET_OBJECTS:bpf>)
+if (NOT LIBBPF_FOUND)
+	list(APPEND dwarves_LIB_SRCS $<TARGET_OBJECTS:bpf>)
+endif()
+add_library(dwarves SHARED ${dwarves_LIB_SRCS})
 set_target_properties(dwarves PROPERTIES VERSION 1.0.0 SOVERSION 1)
 set_target_properties(dwarves PROPERTIES INTERFACE_LINK_LIBRARIES "")
-target_include_directories(dwarves PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
-target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES})
+if (NOT LIBBPF_FOUND)
+	target_include_directories(dwarves PRIVATE
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+else()
+	target_include_directories(dwarves PRIVATE ${LIBBPF_INCLUDE_DIRS})
+endif()
+target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES} ${LIBBPF_LIBRARIES})
 
 set(dwarves_emit_LIB_SRCS dwarves_emit.c)
 add_library(dwarves_emit SHARED ${dwarves_emit_LIB_SRCS})
diff --git a/btf_encoder.c b/btf_encoder.c
index 3339730..c13dc7e 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -11,8 +11,13 @@
 
 #include "dwarves.h"
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
 #include "lib/bpf/src/libbpf.h"
+#endif
 #include "hash.h"
 #include "elf_symtab.h"
 #include "btf_encoder.h"
diff --git a/btf_loader.c b/btf_loader.c
index ec286f4..744abc6 100644
--- a/btf_loader.c
+++ b/btf_loader.c
@@ -25,7 +25,11 @@
 #include <gelf.h>
 
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
+#endif
 #include "dutil.h"
 #include "dwarves.h"
 
diff --git a/libbtf.c b/libbtf.c
index 16e1d45..840d2a1 100644
--- a/libbtf.c
+++ b/libbtf.c
@@ -18,10 +18,16 @@
 #include <stdarg.h>
 
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#include <bpf/btf.h>
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
 #include "lib/bpf/include/linux/err.h"
 #include "lib/bpf/src/btf.h"
 #include "lib/bpf/src/libbpf.h"
+#endif
 #include "dutil.h"
 #include "gobuffer.h"
 #include "dwarves.h"
diff --git a/libbtf.h b/libbtf.h
index 191f586..c01764e 100644
--- a/libbtf.h
+++ b/libbtf.h
@@ -11,7 +11,11 @@
 
 #include <stdbool.h>
 #include <stdint.h>
+#ifdef LIBBPF_FOUND
+#include <bpf/btf.h>
+#else
 #include "lib/bpf/src/btf.h"
+#endif
 
 struct btf_elf {
 	void		  *priv;
diff --git a/pahole.c b/pahole.c
index 4a34ba5..cfcf829 100644
--- a/pahole.c
+++ b/pahole.c
@@ -23,7 +23,11 @@
 #include "ctf_encoder.h"
 #include "btf_encoder.h"
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/src/libbpf.h"
+#endif
 
 static bool btf_encode;
 static bool ctf_encode;
diff --git a/pahole_strings.h b/pahole_strings.h
index 522fbf2..8fc0648 100644
--- a/pahole_strings.h
+++ b/pahole_strings.h
@@ -6,7 +6,11 @@
   Copyright (C) 2008 Arnaldo Carvalho de Melo <acme@redhat.com>
 */
 
+#ifdef LIBBPF_FOUND
+#include <bpf/btf.h>
+#else
 #include "lib/bpf/src/btf.h"
+#endif
 
 typedef unsigned int strings_t;
 
diff --git a/strings.c b/strings.c
index d37f49d..507aaa1 100644
--- a/strings.c
+++ b/strings.c
@@ -15,7 +15,11 @@
 #include <zlib.h>
 
 #include "dutil.h"
+#ifdef LIBBPF_FOUND
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/src/libbpf.h"
+#endif
 
 struct strings *strings__new(void)
 {
-- 
2.29.2

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Andrii Nakryiko]

On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org> wrote:
>
> Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> embedded version and the system version (searched via pkg-config)
> of libbpf. Set the system version as the default.
>

There's been a lot of arguments about libbpf as a submodule, so I
don't think we need to go about pros and cons again, but I just wanted
to cast my vote against doing this at all. Having pahole built with
libbpf statically (only) was a great thing for me so far with
iterating quickly and adopting new APIs without overcomplicating the
source code with all sorts of feature detection code. Without it,
adopting libbpf's faster string deduplication, BTF writing APIs,
module/split BTFs, etc, etc, would be much bigger PITA and/or would
prolong such changes. To the point that I personally wouldn't bother
with some of them at all. Distro maintainers obviously don't care
about such inconveniences for developers, but it's a real factor in
determining what kind of functionality is implemented in pahole, so I
hope Arnaldo won't dismiss this without thinking about this carefully.

> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> Note: I can switch the default around if you prefer.

With BCC you seem to go with the default preserving existing behavior
(using libbpf from a submodule), so if we do this, I think the default
should be flipped.

>
>  CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++-------------
>  btf_encoder.c    |  5 +++++
>  btf_loader.c     |  4 ++++
>  libbtf.c         |  6 ++++++
>  libbtf.h         |  4 ++++
>  pahole.c         |  4 ++++
>  pahole_strings.h |  4 ++++
>  strings.c        |  4 ++++
>  8 files changed, 67 insertions(+), 13 deletions(-)
>

[...]

>  #include "dutil.h"
> +#ifdef LIBBPF_FOUND
> +#include <bpf/libbpf.h>
> +#else
>  #include "lib/bpf/src/libbpf.h"
> +#endif

this is horrible, are you sure there is no way to make <bpf/libbpf.h>
work for both cases?

>
>  struct strings *strings__new(void)
>  {
> --
> 2.29.2
>

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> wrote:
> > 
> > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > embedded version and the system version (searched via pkg-config)
> > of libbpf. Set the system version as the default.
> > 
> 
> There's been a lot of arguments about libbpf as a submodule, so I
> don't think we need to go about pros and cons again, but I just
> wanted
> to cast my vote against doing this at all. Having pahole built with
> libbpf statically (only) was a great thing for me so far with
> iterating quickly and adopting new APIs without overcomplicating the
> source code with all sorts of feature detection code. Without it,
> adopting libbpf's faster string deduplication, BTF writing APIs,
> module/split BTFs, etc, etc, would be much bigger PITA and/or would
> prolong such changes. To the point that I personally wouldn't bother
> with some of them at all. Distro maintainers obviously don't care
> about such inconveniences for developers, but it's a real factor in
> determining what kind of functionality is implemented in pahole, so I
> hope Arnaldo won't dismiss this without thinking about this
> carefully.

You know very well that it's not about caring or not caring :-) There
are simply conflicting interests, and both sides are valid.
I believe we can have best of both worlds with this. The user who does
the build is empowered to choose what they prefer. The additional cost
would be to set the correct minimum version required in the CMake file,
as it's done with other dependencies, including CMake itself.

> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> > Note: I can switch the default around if you prefer.
> 
> With BCC you seem to go with the default preserving existing behavior
> (using libbpf from a submodule), so if we do this, I think the
> default
> should be flipped.

Sure, sent v2.

> > 
> >  CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++---------
> > ----
> >  btf_encoder.c    |  5 +++++
> >  btf_loader.c     |  4 ++++
> >  libbtf.c         |  6 ++++++
> >  libbtf.h         |  4 ++++
> >  pahole.c         |  4 ++++
> >  pahole_strings.h |  4 ++++
> >  strings.c        |  4 ++++
> >  8 files changed, 67 insertions(+), 13 deletions(-)
> > 
> 
> [...]
> 
> >  #include "dutil.h"
> > +#ifdef LIBBPF_FOUND
> > +#include <bpf/libbpf.h>
> > +#else
> >  #include "lib/bpf/src/libbpf.h"
> > +#endif
> 
> this is horrible, are you sure there is no way to make <bpf/libbpf.h>
> work for both cases?

It really is, but unfortunately I don't see other ways that are not
just as horrible. Suggestions welcome. The only thing I can think of,
is if libbpf used the same directory hierarchy in-tree as it does in
the installed tree. Ie: move those headers from libbpf/src/foo.h to
libbpf/include/bpf/foo.h. Then we would just have the -Ilib/bpf/include
in CPPFLAGS for the embedded build defined in the CMake files, and the
sources would only use the "system" includes everywhere, without
ifdeffery.

Given you maintain libbpf, would that be something you'd accept? It's
quite a common pattern for libraries to store their public headers in a
separate directory in the git tree, after all.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Andrii Nakryiko]

On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org> wrote:
>
> On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > wrote:
> > >
> > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > embedded version and the system version (searched via pkg-config)
> > > of libbpf. Set the system version as the default.
> > >
> >
> > There's been a lot of arguments about libbpf as a submodule, so I
> > don't think we need to go about pros and cons again, but I just
> > wanted
> > to cast my vote against doing this at all. Having pahole built with
> > libbpf statically (only) was a great thing for me so far with
> > iterating quickly and adopting new APIs without overcomplicating the
> > source code with all sorts of feature detection code. Without it,
> > adopting libbpf's faster string deduplication, BTF writing APIs,
> > module/split BTFs, etc, etc, would be much bigger PITA and/or would
> > prolong such changes. To the point that I personally wouldn't bother
> > with some of them at all. Distro maintainers obviously don't care
> > about such inconveniences for developers, but it's a real factor in
> > determining what kind of functionality is implemented in pahole, so I
> > hope Arnaldo won't dismiss this without thinking about this
> > carefully.
>
> You know very well that it's not about caring or not caring :-) There
> are simply conflicting interests, and both sides are valid.

I didn't mean it in a negative way. Different priorities and interests
is a better way to put it, sure.

> I believe we can have best of both worlds with this. The user who does
> the build is empowered to choose what they prefer. The additional cost
> would be to set the correct minimum version required in the CMake file,
> as it's done with other dependencies, including CMake itself.
>
> > > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > > ---
> > > Note: I can switch the default around if you prefer.
> >
> > With BCC you seem to go with the default preserving existing behavior
> > (using libbpf from a submodule), so if we do this, I think the
> > default
> > should be flipped.
>
> Sure, sent v2.
>
> > >
> > >  CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++---------
> > > ----
> > >  btf_encoder.c    |  5 +++++
> > >  btf_loader.c     |  4 ++++
> > >  libbtf.c         |  6 ++++++
> > >  libbtf.h         |  4 ++++
> > >  pahole.c         |  4 ++++
> > >  pahole_strings.h |  4 ++++
> > >  strings.c        |  4 ++++
> > >  8 files changed, 67 insertions(+), 13 deletions(-)
> > >
> >
> > [...]
> >
> > >  #include "dutil.h"
> > > +#ifdef LIBBPF_FOUND
> > > +#include <bpf/libbpf.h>
> > > +#else
> > >  #include "lib/bpf/src/libbpf.h"
> > > +#endif
> >
> > this is horrible, are you sure there is no way to make <bpf/libbpf.h>
> > work for both cases?
>
> It really is, but unfortunately I don't see other ways that are not
> just as horrible. Suggestions welcome. The only thing I can think of,
> is if libbpf used the same directory hierarchy in-tree as it does in
> the installed tree. Ie: move those headers from libbpf/src/foo.h to
> libbpf/include/bpf/foo.h. Then we would just have the -Ilib/bpf/include
> in CPPFLAGS for the embedded build defined in the CMake files, and the
> sources would only use the "system" includes everywhere, without
> ifdeffery.
>
> Given you maintain libbpf, would that be something you'd accept? It's
> quite a common pattern for libraries to store their public headers in a
> separate directory in the git tree, after all.

It's quite risky, as there are plenty of (sometimes private)
integrations that assume such a layout of libbpf, so we'll be breaking
them badly. Makefile-based projects do `make install_headers` to put
*only exported* headers into the desired location. I'm not sure what's
the best way to achieve the same with Cmake, though.

One quick and easy hack would be to put a symlink lib/include/bpf ->
lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
handle <bpf/*.h> properly.

>
> --
> Kind regards,
> Luca Boccassi

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org>
> wrote:
> > 
> > On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > > wrote:
> > > > 
> > > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > > embedded version and the system version (searched via pkg-
> > > > config)
> > > > of libbpf. Set the system version as the default.
> > > > 
> > > 
> > > There's been a lot of arguments about libbpf as a submodule, so I
> > > don't think we need to go about pros and cons again, but I just
> > > wanted
> > > to cast my vote against doing this at all. Having pahole built
> > > with
> > > libbpf statically (only) was a great thing for me so far with
> > > iterating quickly and adopting new APIs without overcomplicating
> > > the
> > > source code with all sorts of feature detection code. Without it,
> > > adopting libbpf's faster string deduplication, BTF writing APIs,
> > > module/split BTFs, etc, etc, would be much bigger PITA and/or
> > > would
> > > prolong such changes. To the point that I personally wouldn't
> > > bother
> > > with some of them at all. Distro maintainers obviously don't care
> > > about such inconveniences for developers, but it's a real factor
> > > in
> > > determining what kind of functionality is implemented in pahole,
> > > so I
> > > hope Arnaldo won't dismiss this without thinking about this
> > > carefully.
> > 
> > You know very well that it's not about caring or not caring :-)
> > There
> > are simply conflicting interests, and both sides are valid.
> 
> I didn't mean it in a negative way. Different priorities and
> interests
> is a better way to put it, sure.
> 
> > I believe we can have best of both worlds with this. The user who
> > does
> > the build is empowered to choose what they prefer. The additional
> > cost
> > would be to set the correct minimum version required in the CMake
> > file,
> > as it's done with other dependencies, including CMake itself.
> > 
> > > > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > > > ---
> > > > Note: I can switch the default around if you prefer.
> > > 
> > > With BCC you seem to go with the default preserving existing
> > > behavior
> > > (using libbpf from a submodule), so if we do this, I think the
> > > default
> > > should be flipped.
> > 
> > Sure, sent v2.
> > 
> > > > 
> > > >  CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++-----
> > > > ----
> > > > ----
> > > >  btf_encoder.c    |  5 +++++
> > > >  btf_loader.c     |  4 ++++
> > > >  libbtf.c         |  6 ++++++
> > > >  libbtf.h         |  4 ++++
> > > >  pahole.c         |  4 ++++
> > > >  pahole_strings.h |  4 ++++
> > > >  strings.c        |  4 ++++
> > > >  8 files changed, 67 insertions(+), 13 deletions(-)
> > > > 
> > > 
> > > [...]
> > > 
> > > >  #include "dutil.h"
> > > > +#ifdef LIBBPF_FOUND
> > > > +#include <bpf/libbpf.h>
> > > > +#else
> > > >  #include "lib/bpf/src/libbpf.h"
> > > > +#endif
> > > 
> > > this is horrible, are you sure there is no way to make
> > > <bpf/libbpf.h>
> > > work for both cases?
> > 
> > It really is, but unfortunately I don't see other ways that are not
> > just as horrible. Suggestions welcome. The only thing I can think
> > of,
> > is if libbpf used the same directory hierarchy in-tree as it does
> > in
> > the installed tree. Ie: move those headers from libbpf/src/foo.h to
> > libbpf/include/bpf/foo.h. Then we would just have the -
> > Ilib/bpf/include
> > in CPPFLAGS for the embedded build defined in the CMake files, and
> > the
> > sources would only use the "system" includes everywhere, without
> > ifdeffery.
> > 
> > Given you maintain libbpf, would that be something you'd accept?
> > It's
> > quite a common pattern for libraries to store their public headers
> > in a
> > separate directory in the git tree, after all.
> 
> It's quite risky, as there are plenty of (sometimes private)
> integrations that assume such a layout of libbpf, so we'll be
> breaking
> them badly. Makefile-based projects do `make install_headers` to put
> *only exported* headers into the desired location. I'm not sure
> what's
> the best way to achieve the same with Cmake, though.
> 
> One quick and easy hack would be to put a symlink lib/include/bpf ->
> lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> handle <bpf/*.h> properly.

Sure, that works for me if it's acceptable as a solution. Sent v3 that
implements it. Thanks for the suggestion.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org>
> > > > >  #include "dutil.h"
> > > > > +#ifdef LIBBPF_FOUND
> > > > > +#include <bpf/libbpf.h>
> > > > > +#else
> > > > >  #include "lib/bpf/src/libbpf.h"
> > > > > +#endif

> > > > this is horrible, are you sure there is no way to make
> > > > <bpf/libbpf.h>
> > > > work for both cases?

> > > It really is, but unfortunately I don't see other ways that are
> > > not just as horrible. Suggestions welcome. The only thing I can
> > > think of, is if libbpf used the same directory hierarchy in-tree
> > > as it does in the installed tree. Ie: move those headers from
> > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just
> > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build
> > > defined in the CMake files, and the sources would only use the
> > > "system" includes everywhere, without ifdeffery.

> > > Given you maintain libbpf, would that be something you'd accept?
> > > It's quite a common pattern for libraries to store their public
> > > headers in a separate directory in the git tree, after all.
 
> > It's quite risky, as there are plenty of (sometimes private)
> > integrations that assume such a layout of libbpf, so we'll be
> > breaking them badly. Makefile-based projects do `make
> > install_headers` to put *only exported* headers into the desired
> > location. I'm not sure what's the best way to achieve the same with
> > Cmake, though.
 
> > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > handle <bpf/*.h> properly.
 
> Sure, that works for me if it's acceptable as a solution. Sent v3 that
> implements it. Thanks for the suggestion.

Andrii, can I have your Reviewed-by or Acked-by for v3?

I have it in my local repo and will push publicly later today after I
perform tests.

- Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Andrii Nakryiko]

On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo
<arnaldo.melo@gmail.com> wrote:
>
> Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org>
> > > > > >  #include "dutil.h"
> > > > > > +#ifdef LIBBPF_FOUND
> > > > > > +#include <bpf/libbpf.h>
> > > > > > +#else
> > > > > >  #include "lib/bpf/src/libbpf.h"
> > > > > > +#endif
>
> > > > > this is horrible, are you sure there is no way to make
> > > > > <bpf/libbpf.h>
> > > > > work for both cases?
>
> > > > It really is, but unfortunately I don't see other ways that are
> > > > not just as horrible. Suggestions welcome. The only thing I can
> > > > think of, is if libbpf used the same directory hierarchy in-tree
> > > > as it does in the installed tree. Ie: move those headers from
> > > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just
> > > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build
> > > > defined in the CMake files, and the sources would only use the
> > > > "system" includes everywhere, without ifdeffery.
>
> > > > Given you maintain libbpf, would that be something you'd accept?
> > > > It's quite a common pattern for libraries to store their public
> > > > headers in a separate directory in the git tree, after all.
>
> > > It's quite risky, as there are plenty of (sometimes private)
> > > integrations that assume such a layout of libbpf, so we'll be
> > > breaking them badly. Makefile-based projects do `make
> > > install_headers` to put *only exported* headers into the desired
> > > location. I'm not sure what's the best way to achieve the same with
> > > Cmake, though.
>
> > > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > > handle <bpf/*.h> properly.
>
> > Sure, that works for me if it's acceptable as a solution. Sent v3 that
> > implements it. Thanks for the suggestion.
>
> Andrii, can I have your Reviewed-by or Acked-by for v3?

Well, I still think it's not good and not necessary for pahole. pahole
doesn't run under root. It's not a networking application open to the
world either. So I don't buy security arguments in this case at all.
So no, feel free to push this, but without my ack.

>
> I have it in my local repo and will push publicly later today after I
> perform tests.

While on the subject, do you have plans to release 1.20 any time soon?
I'm holding off until 1.20 is available to sync it internally to be
used for our kernels. Would be nice to get this off my head :)

>
> - Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Thu, Jan 21, 2021 at 12:02:53PM -0800, Andrii Nakryiko escreveu:
> On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo
> <arnaldo.melo@gmail.com> wrote:
> >
> > Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> > > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org>
> > > > > > >  #include "dutil.h"
> > > > > > > +#ifdef LIBBPF_FOUND
> > > > > > > +#include <bpf/libbpf.h>
> > > > > > > +#else
> > > > > > >  #include "lib/bpf/src/libbpf.h"
> > > > > > > +#endif
> >
> > > > > > this is horrible, are you sure there is no way to make
> > > > > > <bpf/libbpf.h>
> > > > > > work for both cases?
> >
> > > > > It really is, but unfortunately I don't see other ways that are
> > > > > not just as horrible. Suggestions welcome. The only thing I can
> > > > > think of, is if libbpf used the same directory hierarchy in-tree
> > > > > as it does in the installed tree. Ie: move those headers from
> > > > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just
> > > > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build
> > > > > defined in the CMake files, and the sources would only use the
> > > > > "system" includes everywhere, without ifdeffery.
> >
> > > > > Given you maintain libbpf, would that be something you'd accept?
> > > > > It's quite a common pattern for libraries to store their public
> > > > > headers in a separate directory in the git tree, after all.
> >
> > > > It's quite risky, as there are plenty of (sometimes private)
> > > > integrations that assume such a layout of libbpf, so we'll be
> > > > breaking them badly. Makefile-based projects do `make
> > > > install_headers` to put *only exported* headers into the desired
> > > > location. I'm not sure what's the best way to achieve the same with
> > > > Cmake, though.
> >
> > > > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > > > handle <bpf/*.h> properly.
> >
> > > Sure, that works for me if it's acceptable as a solution. Sent v3 that
> > > implements it. Thanks for the suggestion.
> >
> > Andrii, can I have your Reviewed-by or Acked-by for v3?
> 
> Well, I still think it's not good and not necessary for pahole. pahole
> doesn't run under root. It's not a networking application open to the
> world either. So I don't buy security arguments in this case at all.
> So no, feel free to push this, but without my ack.
> 
> >
> > I have it in my local repo and will push publicly later today after I
> > perform tests.
> 
> While on the subject, do you have plans to release 1.20 any time soon?
> I'm holding off until 1.20 is available to sync it internally to be
> used for our kernels. Would be nice to get this off my head :)

I planed to do it as quick release, but then holidays and my vacation
got in the way, now there are some issues to solve, but I think I should
release a version and then get back to those DWARF5 and 32-bit issues
:-\

- Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Thu, Jan 21, 2021 at 12:02:53PM -0800, Andrii Nakryiko escreveu:
> On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> > > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > > > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > > > handle <bpf/*.h> properly.
> >
> > > Sure, that works for me if it's acceptable as a solution. Sent v3 that
> > > implements it. Thanks for the suggestion.
> >
> > Andrii, can I have your Reviewed-by or Acked-by for v3?
> 
> Well, I still think it's not good and not necessary for pahole. pahole
> doesn't run under root. It's not a networking application open to the
> world either. So I don't buy security arguments in this case at all.
> So no, feel free to push this, but without my ack.

Ok, fair enough, I applied the patch, the default behaviour is the one
we like, so should be no problem for us :-)

- Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

On Thu, 2021-01-21 at 17:34 -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 21, 2021 at 12:02:53PM -0800, Andrii Nakryiko escreveu:
> > On Thu, Jan 21, 2021 at 5:29 AM Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com> wrote:
> > > Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu:
> > > > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote:
> > > > > One quick and easy hack would be to put a symlink lib/include/bpf ->
> > > > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> > > > > handle <bpf/*.h> properly.
> > > > Sure, that works for me if it's acceptable as a solution. Sent v3 that
> > > > implements it. Thanks for the suggestion.
> > > 
> > > Andrii, can I have your Reviewed-by or Acked-by for v3?
> > 
> > Well, I still think it's not good and not necessary for pahole. pahole
> > doesn't run under root. It's not a networking application open to the
> > world either. So I don't buy security arguments in this case at all.
> > So no, feel free to push this, but without my ack.
> 
> Ok, fair enough, I applied the patch, the default behaviour is the one
> we like, so should be no problem for us :-)

Thank you!

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Mon, Jan 04, 2021 at 12:23:25PM -0800, Andrii Nakryiko escreveu:
> On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > > wrote:
> > > >
> > > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > > embedded version and the system version (searched via pkg-config)
> > > > of libbpf. Set the system version as the default.
> > > >
> > >
> > > There's been a lot of arguments about libbpf as a submodule, so I
> > > don't think we need to go about pros and cons again, but I just
> > > wanted
> > > to cast my vote against doing this at all. Having pahole built with
> > > libbpf statically (only) was a great thing for me so far with
> > > iterating quickly and adopting new APIs without overcomplicating the
> > > source code with all sorts of feature detection code. Without it,
> > > adopting libbpf's faster string deduplication, BTF writing APIs,
> > > module/split BTFs, etc, etc, would be much bigger PITA and/or would
> > > prolong such changes. To the point that I personally wouldn't bother
> > > with some of them at all. Distro maintainers obviously don't care
> > > about such inconveniences for developers, but it's a real factor in
> > > determining what kind of functionality is implemented in pahole, so I
> > > hope Arnaldo won't dismiss this without thinking about this
> > > carefully.

Hey, having tools/perf/ and tools/lib/perf, tools/lib/bpf, etc all in
one place is really nice :-)

> > You know very well that it's not about caring or not caring :-) There
> > are simply conflicting interests, and both sides are valid.
 
> I didn't mean it in a negative way. Different priorities and interests
> is a better way to put it, sure.

I think the default should be submodules as we're still very much in
flux, adding new features, etc.

Disto maintainers can make sure they know what they're doing when making
tools use libbpf as a separate package.

I'm coming back from vacation, so trying to zip thru a lot of emails, so
just thought about sharing my first reaction to this in a quick way.

Regards,

- Arnaldo
 
> > I believe we can have best of both worlds with this. The user who does
> > the build is empowered to choose what they prefer. The additional cost
> > would be to set the correct minimum version required in the CMake file,
> > as it's done with other dependencies, including CMake itself.
> >
> > > > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > > > ---
> > > > Note: I can switch the default around if you prefer.
> > >
> > > With BCC you seem to go with the default preserving existing behavior
> > > (using libbpf from a submodule), so if we do this, I think the
> > > default
> > > should be flipped.
> >
> > Sure, sent v2.
> >
> > > >
> > > >  CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++---------
> > > > ----
> > > >  btf_encoder.c    |  5 +++++
> > > >  btf_loader.c     |  4 ++++
> > > >  libbtf.c         |  6 ++++++
> > > >  libbtf.h         |  4 ++++
> > > >  pahole.c         |  4 ++++
> > > >  pahole_strings.h |  4 ++++
> > > >  strings.c        |  4 ++++
> > > >  8 files changed, 67 insertions(+), 13 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > >  #include "dutil.h"
> > > > +#ifdef LIBBPF_FOUND
> > > > +#include <bpf/libbpf.h>
> > > > +#else
> > > >  #include "lib/bpf/src/libbpf.h"
> > > > +#endif
> > >
> > > this is horrible, are you sure there is no way to make <bpf/libbpf.h>
> > > work for both cases?
> >
> > It really is, but unfortunately I don't see other ways that are not
> > just as horrible. Suggestions welcome. The only thing I can think of,
> > is if libbpf used the same directory hierarchy in-tree as it does in
> > the installed tree. Ie: move those headers from libbpf/src/foo.h to
> > libbpf/include/bpf/foo.h. Then we would just have the -Ilib/bpf/include
> > in CPPFLAGS for the embedded build defined in the CMake files, and the
> > sources would only use the "system" includes everywhere, without
> > ifdeffery.
> >
> > Given you maintain libbpf, would that be something you'd accept? It's
> > quite a common pattern for libraries to store their public headers in a
> > separate directory in the git tree, after all.
> 
> It's quite risky, as there are plenty of (sometimes private)
> integrations that assume such a layout of libbpf, so we'll be breaking
> them badly. Makefile-based projects do `make install_headers` to put
> *only exported* headers into the desired location. I'm not sure what's
> the best way to achieve the same with Cmake, though.
> 
> One quick and easy hack would be to put a symlink lib/include/bpf ->
> lib/bpf/src into pahole repo. And add -Ilib/include to let compiler
> handle <bpf/*.h> properly.
> 
> >
> > --
> > Kind regards,
> > Luca Boccassi

-- 

- Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

On Fri, 2021-01-15 at 12:29 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jan 04, 2021 at 12:23:25PM -0800, Andrii Nakryiko escreveu:
> > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org> wrote:
> > > On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > > > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > > > wrote:
> > > > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > > > embedded version and the system version (searched via pkg-config)
> > > > > of libbpf. Set the system version as the default.
> > > > > 
> > > > 
> > > > There's been a lot of arguments about libbpf as a submodule, so I
> > > > don't think we need to go about pros and cons again, but I just
> > > > wanted
> > > > to cast my vote against doing this at all. Having pahole built with
> > > > libbpf statically (only) was a great thing for me so far with
> > > > iterating quickly and adopting new APIs without overcomplicating the
> > > > source code with all sorts of feature detection code. Without it,
> > > > adopting libbpf's faster string deduplication, BTF writing APIs,
> > > > module/split BTFs, etc, etc, would be much bigger PITA and/or would
> > > > prolong such changes. To the point that I personally wouldn't bother
> > > > with some of them at all. Distro maintainers obviously don't care
> > > > about such inconveniences for developers, but it's a real factor in
> > > > determining what kind of functionality is implemented in pahole, so I
> > > > hope Arnaldo won't dismiss this without thinking about this
> > > > carefully.
> 
> Hey, having tools/perf/ and tools/lib/perf, tools/lib/bpf, etc all in
> one place is really nice :-)
> 
> > > You know very well that it's not about caring or not caring :-) There
> > > are simply conflicting interests, and both sides are valid.
>  
> > I didn't mean it in a negative way. Different priorities and interests
> > is a better way to put it, sure.
> 
> I think the default should be submodules as we're still very much in
> flux, adding new features, etc.
> 
> Disto maintainers can make sure they know what they're doing when making
> tools use libbpf as a separate package.

Sure, v3 has the option as default-disabled already, not a problem at
all.

> I'm coming back from vacation, so trying to zip thru a lot of emails, so
> just thought about sharing my first reaction to this in a quick way.

No worries and no rush.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Fri, Jan 15, 2021 at 03:40:34PM +0000, Luca Boccassi escreveu:
> On Fri, 2021-01-15 at 12:29 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jan 04, 2021 at 12:23:25PM -0800, Andrii Nakryiko escreveu:
> > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org> wrote:
> > > > On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > > > > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > > > > wrote:
> > > > > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > > > > embedded version and the system version (searched via pkg-config)
> > > > > > of libbpf. Set the system version as the default.
> > > > > > 
> > > > > 
> > > > > There's been a lot of arguments about libbpf as a submodule, so I
> > > > > don't think we need to go about pros and cons again, but I just
> > > > > wanted
> > > > > to cast my vote against doing this at all. Having pahole built with
> > > > > libbpf statically (only) was a great thing for me so far with
> > > > > iterating quickly and adopting new APIs without overcomplicating the
> > > > > source code with all sorts of feature detection code. Without it,
> > > > > adopting libbpf's faster string deduplication, BTF writing APIs,
> > > > > module/split BTFs, etc, etc, would be much bigger PITA and/or would
> > > > > prolong such changes. To the point that I personally wouldn't bother
> > > > > with some of them at all. Distro maintainers obviously don't care
> > > > > about such inconveniences for developers, but it's a real factor in
> > > > > determining what kind of functionality is implemented in pahole, so I
> > > > > hope Arnaldo won't dismiss this without thinking about this
> > > > > carefully.
> > 
> > Hey, having tools/perf/ and tools/lib/perf, tools/lib/bpf, etc all in
> > one place is really nice :-)
> > 
> > > > You know very well that it's not about caring or not caring :-) There
> > > > are simply conflicting interests, and both sides are valid.
> >  
> > > I didn't mean it in a negative way. Different priorities and interests
> > > is a better way to put it, sure.
> > 
> > I think the default should be submodules as we're still very much in
> > flux, adding new features, etc.
> > 
> > Disto maintainers can make sure they know what they're doing when making
> > tools use libbpf as a separate package.
> 
> Sure, v3 has the option as default-disabled already, not a problem at
> all.

Does this mean that if I have libbpf-devel installed in my system the
default build will _not_ link with it?

I have libbpf-devel installed in my machine but, by default, I _don't_
want pahole to build with it, libbpf-devel is there for other needs.

- Arnaldo

Re: [PATCH dwarves] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 3043 bytes --]

On Wed, 2021-06-09 at 13:07 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 15, 2021 at 03:40:34PM +0000, Luca Boccassi escreveu:
> > On Fri, 2021-01-15 at 12:29 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Jan 04, 2021 at 12:23:25PM -0800, Andrii Nakryiko escreveu:
> > > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@debian.org> wrote:
> > > > > On Sun, 2021-01-03 at 11:10 -0800, Andrii Nakryiko wrote:
> > > > > > On Sat, Jan 2, 2021 at 10:25 AM Luca Boccassi <bluca@debian.org>
> > > > > > wrote:
> > > > > > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > > > > > embedded version and the system version (searched via pkg-config)
> > > > > > > of libbpf. Set the system version as the default.
> > > > > > > 
> > > > > > 
> > > > > > There's been a lot of arguments about libbpf as a submodule, so I
> > > > > > don't think we need to go about pros and cons again, but I just
> > > > > > wanted
> > > > > > to cast my vote against doing this at all. Having pahole built with
> > > > > > libbpf statically (only) was a great thing for me so far with
> > > > > > iterating quickly and adopting new APIs without overcomplicating the
> > > > > > source code with all sorts of feature detection code. Without it,
> > > > > > adopting libbpf's faster string deduplication, BTF writing APIs,
> > > > > > module/split BTFs, etc, etc, would be much bigger PITA and/or would
> > > > > > prolong such changes. To the point that I personally wouldn't bother
> > > > > > with some of them at all. Distro maintainers obviously don't care
> > > > > > about such inconveniences for developers, but it's a real factor in
> > > > > > determining what kind of functionality is implemented in pahole, so I
> > > > > > hope Arnaldo won't dismiss this without thinking about this
> > > > > > carefully.
> > > 
> > > Hey, having tools/perf/ and tools/lib/perf, tools/lib/bpf, etc all in
> > > one place is really nice :-)
> > > 
> > > > > You know very well that it's not about caring or not caring :-) There
> > > > > are simply conflicting interests, and both sides are valid.
> > >  
> > > > I didn't mean it in a negative way. Different priorities and interests
> > > > is a better way to put it, sure.
> > > 
> > > I think the default should be submodules as we're still very much in
> > > flux, adding new features, etc.
> > > 
> > > Disto maintainers can make sure they know what they're doing when making
> > > tools use libbpf as a separate package.
> > 
> > Sure, v3 has the option as default-disabled already, not a problem at
> > all.
> 
> Does this mean that if I have libbpf-devel installed in my system the
> default build will _not_ link with it?
> 
> I have libbpf-devel installed in my machine but, by default, I _don't_
> want pahole to build with it, libbpf-devel is there for other needs.
> 

Hi,

Yes, that's correct - you have to explicitly pass -DLIBBPF_EMBEDDED=off
to CMake to use libbpf-devel.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH dwarves v2] libbpf: allow to use packaged version

[Luca Boccassi]

Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
embedded version and the system version (searched via pkg-config)
of libbpf. Set the system version as the default.

Signed-off-by: Luca Boccassi <bluca@debian.org>
---
v2: switched default to use embedded version

 CMakeLists.txt   | 49 +++++++++++++++++++++++++++++++++++-------------
 btf_encoder.c    |  5 +++++
 btf_loader.c     |  4 ++++
 libbtf.c         |  6 ++++++
 libbtf.h         |  4 ++++
 pahole.c         |  4 ++++
 pahole_strings.h |  4 ++++
 strings.c        |  4 ++++
 8 files changed, 67 insertions(+), 13 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 857487a..188f334 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,9 +2,23 @@ project(pahole C)
 cmake_minimum_required(VERSION 2.8.8)
 cmake_policy(SET CMP0005 NEW)
 
+option(LIBBPF_EMBEDDED "Use the embedded version of libbpf instead of searching it via pkg-config" ON)
+if (NOT LIBBPF_EMBEDDED)
+	find_package(PkgConfig)
+	if(PKGCONFIG_FOUND)
+		pkg_check_modules(LIBBPF libbpf>=0.3.0)
+	endif()
+endif()
+
 INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+		    ${CMAKE_CURRENT_SOURCE_DIR})
+if(NOT LIBBPF_FOUND)
+	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+else()
+	INCLUDE_DIRECTORIES(${LIBBPF_INCLUDE_DIRS})
+	LINK_DIRECTORIES(${LIBBPF_LIBRARY_DIRS})
+	ADD_DEFINITIONS(-DLIBBPF_FOUND)
+endif()
 
 # Try to parse this later, Helio just showed me a KDE4 example to support
 # x86-64 builds.
@@ -56,7 +70,7 @@ if(GIT_FOUND AND EXISTS "${PROJECT_SOURCE_DIR}/.git")
 		endif()
 	endif()
 endif()
-if(NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
+if(NOT LIBBPF_FOUND AND NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
 	message(FATAL_ERROR "The submodules were not downloaded! GIT_SUBMODULE was turned off or failed. Please update submodules and try again.")
 endif()
 
@@ -81,22 +95,31 @@ endif()
 
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64")
 
-file(GLOB libbpf_sources "lib/bpf/src/*.c")
-add_library(bpf OBJECT ${libbpf_sources})
-set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
-target_include_directories(bpf PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+if (NOT LIBBPF_FOUND)
+	file(GLOB libbpf_sources "lib/bpf/src/*.c")
+	add_library(bpf OBJECT ${libbpf_sources})
+	set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
+	target_include_directories(bpf PRIVATE
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+endif()
 
 set(dwarves_LIB_SRCS dwarves.c dwarves_fprintf.c gobuffer strings
 		     ctf_encoder.c ctf_loader.c libctf.c btf_encoder.c btf_loader.c libbtf.c
 		     dwarf_loader.c dutil.c elf_symtab.c rbtree.c)
-add_library(dwarves SHARED ${dwarves_LIB_SRCS} $<TARGET_OBJECTS:bpf>)
+if (NOT LIBBPF_FOUND)
+	list(APPEND dwarves_LIB_SRCS $<TARGET_OBJECTS:bpf>)
+endif()
+add_library(dwarves SHARED ${dwarves_LIB_SRCS})
 set_target_properties(dwarves PROPERTIES VERSION 1.0.0 SOVERSION 1)
 set_target_properties(dwarves PROPERTIES INTERFACE_LINK_LIBRARIES "")
-target_include_directories(dwarves PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
-target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES})
+if (NOT LIBBPF_FOUND)
+	target_include_directories(dwarves PRIVATE
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+else()
+	target_include_directories(dwarves PRIVATE ${LIBBPF_INCLUDE_DIRS})
+endif()
+target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES} ${LIBBPF_LIBRARIES})
 
 set(dwarves_emit_LIB_SRCS dwarves_emit.c)
 add_library(dwarves_emit SHARED ${dwarves_emit_LIB_SRCS})
diff --git a/btf_encoder.c b/btf_encoder.c
index 3339730..c13dc7e 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -11,8 +11,13 @@
 
 #include "dwarves.h"
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
 #include "lib/bpf/src/libbpf.h"
+#endif
 #include "hash.h"
 #include "elf_symtab.h"
 #include "btf_encoder.h"
diff --git a/btf_loader.c b/btf_loader.c
index ec286f4..744abc6 100644
--- a/btf_loader.c
+++ b/btf_loader.c
@@ -25,7 +25,11 @@
 #include <gelf.h>
 
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
+#endif
 #include "dutil.h"
 #include "dwarves.h"
 
diff --git a/libbtf.c b/libbtf.c
index 16e1d45..840d2a1 100644
--- a/libbtf.c
+++ b/libbtf.c
@@ -18,10 +18,16 @@
 #include <stdarg.h>
 
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <linux/btf.h>
+#include <bpf/btf.h>
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/include/uapi/linux/btf.h"
 #include "lib/bpf/include/linux/err.h"
 #include "lib/bpf/src/btf.h"
 #include "lib/bpf/src/libbpf.h"
+#endif
 #include "dutil.h"
 #include "gobuffer.h"
 #include "dwarves.h"
diff --git a/libbtf.h b/libbtf.h
index 191f586..c01764e 100644
--- a/libbtf.h
+++ b/libbtf.h
@@ -11,7 +11,11 @@
 
 #include <stdbool.h>
 #include <stdint.h>
+#ifdef LIBBPF_FOUND
+#include <bpf/btf.h>
+#else
 #include "lib/bpf/src/btf.h"
+#endif
 
 struct btf_elf {
 	void		  *priv;
diff --git a/pahole.c b/pahole.c
index 4a34ba5..cfcf829 100644
--- a/pahole.c
+++ b/pahole.c
@@ -23,7 +23,11 @@
 #include "ctf_encoder.h"
 #include "btf_encoder.h"
 #include "libbtf.h"
+#ifdef LIBBPF_FOUND
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/src/libbpf.h"
+#endif
 
 static bool btf_encode;
 static bool ctf_encode;
diff --git a/pahole_strings.h b/pahole_strings.h
index 522fbf2..8fc0648 100644
--- a/pahole_strings.h
+++ b/pahole_strings.h
@@ -6,7 +6,11 @@
   Copyright (C) 2008 Arnaldo Carvalho de Melo <acme@redhat.com>
 */
 
+#ifdef LIBBPF_FOUND
+#include <bpf/btf.h>
+#else
 #include "lib/bpf/src/btf.h"
+#endif
 
 typedef unsigned int strings_t;
 
diff --git a/strings.c b/strings.c
index d37f49d..507aaa1 100644
--- a/strings.c
+++ b/strings.c
@@ -15,7 +15,11 @@
 #include <zlib.h>
 
 #include "dutil.h"
+#ifdef LIBBPF_FOUND
+#include <bpf/libbpf.h>
+#else
 #include "lib/bpf/src/libbpf.h"
+#endif
 
 struct strings *strings__new(void)
 {
-- 
2.29.2

[PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
embedded version and the system version (searched via pkg-config)
of libbpf. Set the embedded version as the default.

Signed-off-by: Luca Boccassi <bluca@debian.org>
---
v2: switched default to use embedded version
v3: add lib/include/bpf -> lib/bpf/src symlink to allow using 'system'
    style #include everywhere, rather than #ifdefs.
    Thanks Andrii for the suggestion!

 CMakeLists.txt   | 43 ++++++++++++++++++++++++++++++-------------
 btf_encoder.c    |  4 ++--
 btf_loader.c     |  2 +-
 lib/include/bpf  |  1 +
 libbtf.c         |  7 +++----
 libbtf.h         |  2 +-
 pahole.c         |  2 +-
 pahole_strings.h |  2 +-
 strings.c        |  2 +-
 9 files changed, 41 insertions(+), 24 deletions(-)
 create mode 120000 lib/include/bpf

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 857487a..eefdebe 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -2,9 +2,24 @@ project(pahole C)
 cmake_minimum_required(VERSION 2.8.8)
 cmake_policy(SET CMP0005 NEW)
 
+option(LIBBPF_EMBEDDED "Use the embedded version of libbpf instead of searching it via pkg-config" ON)
+if (NOT LIBBPF_EMBEDDED)
+	find_package(PkgConfig)
+	if(PKGCONFIG_FOUND)
+		pkg_check_modules(LIBBPF libbpf>=0.3.0)
+	endif()
+endif()
+
 INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}
-		    ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+		    ${CMAKE_CURRENT_SOURCE_DIR})
+if(NOT LIBBPF_FOUND)
+	# Allows to use 'system' style #include with both embedded and system libbpf
+	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/include)
+	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+else()
+	INCLUDE_DIRECTORIES(${LIBBPF_INCLUDE_DIRS})
+	LINK_DIRECTORIES(${LIBBPF_LIBRARY_DIRS})
+endif()
 
 # Try to parse this later, Helio just showed me a KDE4 example to support
 # x86-64 builds.
@@ -56,7 +71,7 @@ if(GIT_FOUND AND EXISTS "${PROJECT_SOURCE_DIR}/.git")
 		endif()
 	endif()
 endif()
-if(NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
+if(NOT LIBBPF_FOUND AND NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
 	message(FATAL_ERROR "The submodules were not downloaded! GIT_SUBMODULE was turned off or failed. Please update submodules and try again.")
 endif()
 
@@ -81,22 +96,24 @@ endif()
 
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64")
 
-file(GLOB libbpf_sources "lib/bpf/src/*.c")
-add_library(bpf OBJECT ${libbpf_sources})
-set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
-target_include_directories(bpf PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
+if (NOT LIBBPF_FOUND)
+	file(GLOB libbpf_sources "lib/bpf/src/*.c")
+	add_library(bpf OBJECT ${libbpf_sources})
+	set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
+	target_include_directories(bpf PRIVATE
+				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include)
+endif()
 
 set(dwarves_LIB_SRCS dwarves.c dwarves_fprintf.c gobuffer strings
 		     ctf_encoder.c ctf_loader.c libctf.c btf_encoder.c btf_loader.c libbtf.c
 		     dwarf_loader.c dutil.c elf_symtab.c rbtree.c)
-add_library(dwarves SHARED ${dwarves_LIB_SRCS} $<TARGET_OBJECTS:bpf>)
+if (NOT LIBBPF_FOUND)
+	list(APPEND dwarves_LIB_SRCS $<TARGET_OBJECTS:bpf>)
+endif()
+add_library(dwarves SHARED ${dwarves_LIB_SRCS})
 set_target_properties(dwarves PROPERTIES VERSION 1.0.0 SOVERSION 1)
 set_target_properties(dwarves PROPERTIES INTERFACE_LINK_LIBRARIES "")
-target_include_directories(dwarves PRIVATE
-			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
-target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES})
+target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES} ${LIBBPF_LIBRARIES})
 
 set(dwarves_emit_LIB_SRCS dwarves_emit.c)
 add_library(dwarves_emit SHARED ${dwarves_emit_LIB_SRCS})
diff --git a/btf_encoder.c b/btf_encoder.c
index 3339730..76e7d43 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -11,12 +11,12 @@
 
 #include "dwarves.h"
 #include "libbtf.h"
-#include "lib/bpf/include/uapi/linux/btf.h"
-#include "lib/bpf/src/libbpf.h"
 #include "hash.h"
 #include "elf_symtab.h"
 #include "btf_encoder.h"
 
+#include <linux/btf.h>
+#include <bpf/libbpf.h>
 #include <ctype.h> /* for isalpha() and isalnum() */
 #include <stdlib.h> /* for qsort() and bsearch() */
 #include <inttypes.h>
diff --git a/btf_loader.c b/btf_loader.c
index ec286f4..fa85d06 100644
--- a/btf_loader.c
+++ b/btf_loader.c
@@ -20,12 +20,12 @@
 #include <string.h>
 #include <limits.h>
 #include <libgen.h>
+#include <linux/btf.h>
 #include <zlib.h>
 
 #include <gelf.h>
 
 #include "libbtf.h"
-#include "lib/bpf/include/uapi/linux/btf.h"
 #include "dutil.h"
 #include "dwarves.h"
 
diff --git a/lib/include/bpf b/lib/include/bpf
new file mode 120000
index 0000000..4c41b71
--- /dev/null
+++ b/lib/include/bpf
@@ -0,0 +1 @@
+../bpf/src
\ No newline at end of file
diff --git a/libbtf.c b/libbtf.c
index 16e1d45..3cc2ac5 100644
--- a/libbtf.c
+++ b/libbtf.c
@@ -16,12 +16,11 @@
 #include <sys/stat.h>
 #include <unistd.h>
 #include <stdarg.h>
+#include <linux/btf.h>
+#include <bpf/btf.h>
+#include <bpf/libbpf.h>
 
 #include "libbtf.h"
-#include "lib/bpf/include/uapi/linux/btf.h"
-#include "lib/bpf/include/linux/err.h"
-#include "lib/bpf/src/btf.h"
-#include "lib/bpf/src/libbpf.h"
 #include "dutil.h"
 #include "gobuffer.h"
 #include "dwarves.h"
diff --git a/libbtf.h b/libbtf.h
index 191f586..0b99767 100644
--- a/libbtf.h
+++ b/libbtf.h
@@ -11,7 +11,7 @@
 
 #include <stdbool.h>
 #include <stdint.h>
-#include "lib/bpf/src/btf.h"
+#include <bpf/btf.h>
 
 struct btf_elf {
 	void		  *priv;
diff --git a/pahole.c b/pahole.c
index 4a34ba5..68dd166 100644
--- a/pahole.c
+++ b/pahole.c
@@ -16,6 +16,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <bpf/libbpf.h>
 
 #include "dwarves_reorganize.h"
 #include "dwarves.h"
@@ -23,7 +24,6 @@
 #include "ctf_encoder.h"
 #include "btf_encoder.h"
 #include "libbtf.h"
-#include "lib/bpf/src/libbpf.h"
 
 static bool btf_encode;
 static bool ctf_encode;
diff --git a/pahole_strings.h b/pahole_strings.h
index 522fbf2..657701b 100644
--- a/pahole_strings.h
+++ b/pahole_strings.h
@@ -6,7 +6,7 @@
   Copyright (C) 2008 Arnaldo Carvalho de Melo <acme@redhat.com>
 */
 
-#include "lib/bpf/src/btf.h"
+#include <bpf/btf.h>
 
 typedef unsigned int strings_t;
 
diff --git a/strings.c b/strings.c
index d37f49d..8244c49 100644
--- a/strings.c
+++ b/strings.c
@@ -13,9 +13,9 @@
 #include <stdio.h>
 #include <string.h>
 #include <zlib.h>
+#include <bpf/libbpf.h>
 
 #include "dutil.h"
-#include "lib/bpf/src/libbpf.h"
 
 struct strings *strings__new(void)
 {
-- 
2.29.2

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Mon, Jan 04, 2021 at 10:16:22PM +0000, Luca Boccassi escreveu:
> Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> embedded version and the system version (searched via pkg-config)
> of libbpf. Set the embedded version as the default.

I'm coming back from vacation, will try to check this soon.

Thanks,

- Arnaldo
 
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> v2: switched default to use embedded version
> v3: add lib/include/bpf -> lib/bpf/src symlink to allow using 'system'
>     style #include everywhere, rather than #ifdefs.
>     Thanks Andrii for the suggestion!
> 
>  CMakeLists.txt   | 43 ++++++++++++++++++++++++++++++-------------
>  btf_encoder.c    |  4 ++--
>  btf_loader.c     |  2 +-
>  lib/include/bpf  |  1 +
>  libbtf.c         |  7 +++----
>  libbtf.h         |  2 +-
>  pahole.c         |  2 +-
>  pahole_strings.h |  2 +-
>  strings.c        |  2 +-
>  9 files changed, 41 insertions(+), 24 deletions(-)
>  create mode 120000 lib/include/bpf
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 857487a..eefdebe 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -2,9 +2,24 @@ project(pahole C)
>  cmake_minimum_required(VERSION 2.8.8)
>  cmake_policy(SET CMP0005 NEW)
>  
> +option(LIBBPF_EMBEDDED "Use the embedded version of libbpf instead of searching it via pkg-config" ON)
> +if (NOT LIBBPF_EMBEDDED)
> +	find_package(PkgConfig)
> +	if(PKGCONFIG_FOUND)
> +		pkg_check_modules(LIBBPF libbpf>=0.3.0)
> +	endif()
> +endif()
> +
>  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}
> -		    ${CMAKE_CURRENT_SOURCE_DIR}
> -		    ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
> +		    ${CMAKE_CURRENT_SOURCE_DIR})
> +if(NOT LIBBPF_FOUND)
> +	# Allows to use 'system' style #include with both embedded and system libbpf
> +	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/include)
> +	INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
> +else()
> +	INCLUDE_DIRECTORIES(${LIBBPF_INCLUDE_DIRS})
> +	LINK_DIRECTORIES(${LIBBPF_LIBRARY_DIRS})
> +endif()
>  
>  # Try to parse this later, Helio just showed me a KDE4 example to support
>  # x86-64 builds.
> @@ -56,7 +71,7 @@ if(GIT_FOUND AND EXISTS "${PROJECT_SOURCE_DIR}/.git")
>  		endif()
>  	endif()
>  endif()
> -if(NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
> +if(NOT LIBBPF_FOUND AND NOT EXISTS "${PROJECT_SOURCE_DIR}/lib/bpf/src/btf.h")
>  	message(FATAL_ERROR "The submodules were not downloaded! GIT_SUBMODULE was turned off or failed. Please update submodules and try again.")
>  endif()
>  
> @@ -81,22 +96,24 @@ endif()
>  
>  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64")
>  
> -file(GLOB libbpf_sources "lib/bpf/src/*.c")
> -add_library(bpf OBJECT ${libbpf_sources})
> -set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
> -target_include_directories(bpf PRIVATE
> -			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include
> -			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
> +if (NOT LIBBPF_FOUND)
> +	file(GLOB libbpf_sources "lib/bpf/src/*.c")
> +	add_library(bpf OBJECT ${libbpf_sources})
> +	set_property(TARGET bpf PROPERTY POSITION_INDEPENDENT_CODE 1)
> +	target_include_directories(bpf PRIVATE
> +				   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include)
> +endif()
>  
>  set(dwarves_LIB_SRCS dwarves.c dwarves_fprintf.c gobuffer strings
>  		     ctf_encoder.c ctf_loader.c libctf.c btf_encoder.c btf_loader.c libbtf.c
>  		     dwarf_loader.c dutil.c elf_symtab.c rbtree.c)
> -add_library(dwarves SHARED ${dwarves_LIB_SRCS} $<TARGET_OBJECTS:bpf>)
> +if (NOT LIBBPF_FOUND)
> +	list(APPEND dwarves_LIB_SRCS $<TARGET_OBJECTS:bpf>)
> +endif()
> +add_library(dwarves SHARED ${dwarves_LIB_SRCS})
>  set_target_properties(dwarves PROPERTIES VERSION 1.0.0 SOVERSION 1)
>  set_target_properties(dwarves PROPERTIES INTERFACE_LINK_LIBRARIES "")
> -target_include_directories(dwarves PRIVATE
> -			   ${CMAKE_CURRENT_SOURCE_DIR}/lib/bpf/include/uapi)
> -target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES})
> +target_link_libraries(dwarves ${DWARF_LIBRARIES} ${ZLIB_LIBRARIES} ${LIBBPF_LIBRARIES})
>  
>  set(dwarves_emit_LIB_SRCS dwarves_emit.c)
>  add_library(dwarves_emit SHARED ${dwarves_emit_LIB_SRCS})
> diff --git a/btf_encoder.c b/btf_encoder.c
> index 3339730..76e7d43 100644
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -11,12 +11,12 @@
>  
>  #include "dwarves.h"
>  #include "libbtf.h"
> -#include "lib/bpf/include/uapi/linux/btf.h"
> -#include "lib/bpf/src/libbpf.h"
>  #include "hash.h"
>  #include "elf_symtab.h"
>  #include "btf_encoder.h"
>  
> +#include <linux/btf.h>
> +#include <bpf/libbpf.h>
>  #include <ctype.h> /* for isalpha() and isalnum() */
>  #include <stdlib.h> /* for qsort() and bsearch() */
>  #include <inttypes.h>
> diff --git a/btf_loader.c b/btf_loader.c
> index ec286f4..fa85d06 100644
> --- a/btf_loader.c
> +++ b/btf_loader.c
> @@ -20,12 +20,12 @@
>  #include <string.h>
>  #include <limits.h>
>  #include <libgen.h>
> +#include <linux/btf.h>
>  #include <zlib.h>
>  
>  #include <gelf.h>
>  
>  #include "libbtf.h"
> -#include "lib/bpf/include/uapi/linux/btf.h"
>  #include "dutil.h"
>  #include "dwarves.h"
>  
> diff --git a/lib/include/bpf b/lib/include/bpf
> new file mode 120000
> index 0000000..4c41b71
> --- /dev/null
> +++ b/lib/include/bpf
> @@ -0,0 +1 @@
> +../bpf/src
> \ No newline at end of file
> diff --git a/libbtf.c b/libbtf.c
> index 16e1d45..3cc2ac5 100644
> --- a/libbtf.c
> +++ b/libbtf.c
> @@ -16,12 +16,11 @@
>  #include <sys/stat.h>
>  #include <unistd.h>
>  #include <stdarg.h>
> +#include <linux/btf.h>
> +#include <bpf/btf.h>
> +#include <bpf/libbpf.h>
>  
>  #include "libbtf.h"
> -#include "lib/bpf/include/uapi/linux/btf.h"
> -#include "lib/bpf/include/linux/err.h"
> -#include "lib/bpf/src/btf.h"
> -#include "lib/bpf/src/libbpf.h"
>  #include "dutil.h"
>  #include "gobuffer.h"
>  #include "dwarves.h"
> diff --git a/libbtf.h b/libbtf.h
> index 191f586..0b99767 100644
> --- a/libbtf.h
> +++ b/libbtf.h
> @@ -11,7 +11,7 @@
>  
>  #include <stdbool.h>
>  #include <stdint.h>
> -#include "lib/bpf/src/btf.h"
> +#include <bpf/btf.h>
>  
>  struct btf_elf {
>  	void		  *priv;
> diff --git a/pahole.c b/pahole.c
> index 4a34ba5..68dd166 100644
> --- a/pahole.c
> +++ b/pahole.c
> @@ -16,6 +16,7 @@
>  #include <stdlib.h>
>  #include <string.h>
>  #include <unistd.h>
> +#include <bpf/libbpf.h>
>  
>  #include "dwarves_reorganize.h"
>  #include "dwarves.h"
> @@ -23,7 +24,6 @@
>  #include "ctf_encoder.h"
>  #include "btf_encoder.h"
>  #include "libbtf.h"
> -#include "lib/bpf/src/libbpf.h"
>  
>  static bool btf_encode;
>  static bool ctf_encode;
> diff --git a/pahole_strings.h b/pahole_strings.h
> index 522fbf2..657701b 100644
> --- a/pahole_strings.h
> +++ b/pahole_strings.h
> @@ -6,7 +6,7 @@
>    Copyright (C) 2008 Arnaldo Carvalho de Melo <acme@redhat.com>
>  */
>  
> -#include "lib/bpf/src/btf.h"
> +#include <bpf/btf.h>
>  
>  typedef unsigned int strings_t;
>  
> diff --git a/strings.c b/strings.c
> index d37f49d..8244c49 100644
> --- a/strings.c
> +++ b/strings.c
> @@ -13,9 +13,9 @@
>  #include <stdio.h>
>  #include <string.h>
>  #include <zlib.h>
> +#include <bpf/libbpf.h>
>  
>  #include "dutil.h"
> -#include "lib/bpf/src/libbpf.h"
>  
>  struct strings *strings__new(void)
>  {
> -- 
> 2.29.2
> 

-- 

- Arnaldo

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Dominique Martinet]

Hi,

I see this commit has been reverted just before the 1.20 release in Feb:
---
Revert "libbpf: allow to use packaged version"

This reverts commit 82749180b23d3c9c060108bc290ae26507fc324e.

Getting in the way of releasing 1.20, breaking the build of a dwarves
rpm when a libbpf package is installed in a fedora 33 system:

In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
/home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
    9 | #include <bpf/btf.h>
      |          ^~~~~~~~~~~

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---

I can understand reverting due to other pressure to get a release out
but most distros (including fedora) frown upon vendoring code so I think
it would be good to have back ultimately.

Did you or someone else (Luca?) ever take the time to look at it?

I don't see what would be so different with fedora to make this
unfixable, I'd be happy taking a look if nobody has so far.
Would you take the patch back in if I somehow fix rpmbuild with a libbpf
package installed on fedora33?


Thanks,
-- 
Dominique

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Tue, 2021-03-30 at 13:47 +0900, Dominique Martinet wrote:
> Hi,
> 
> I see this commit has been reverted just before the 1.20 release in Feb:
> ---
> Revert "libbpf: allow to use packaged version"
> 
> This reverts commit 82749180b23d3c9c060108bc290ae26507fc324e.
> 
> Getting in the way of releasing 1.20, breaking the build of a dwarves
> rpm when a libbpf package is installed in a fedora 33 system:
> 
> In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
> /home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
>     9 | #include <bpf/btf.h>
>       |          ^~~~~~~~~~~
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
> 
> I can understand reverting due to other pressure to get a release out
> but most distros (including fedora) frown upon vendoring code so I think
> it would be good to have back ultimately.
> 
> Did you or someone else (Luca?) ever take the time to look at it?
> 
> I don't see what would be so different with fedora to make this
> unfixable, I'd be happy taking a look if nobody has so far.
> Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> package installed on fedora33?
> 
> 
> Thanks,

Hi,

I did not realise it was reverted (if I was pinged and I missed it:
sorry about that) - what was the issue precisely? This has been used on
Ubuntu and Debian for a few months now, no problems reported.
Happy to have a look too if needed.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 8261 bytes --]

On Tue, 2021-03-30 at 11:50 +0100, Luca Boccassi wrote:
> On Tue, 2021-03-30 at 13:47 +0900, Dominique Martinet wrote:
> > Hi,
> > 
> > I see this commit has been reverted just before the 1.20 release in Feb:
> > ---
> > Revert "libbpf: allow to use packaged version"
> > 
> > This reverts commit 82749180b23d3c9c060108bc290ae26507fc324e.
> > 
> > Getting in the way of releasing 1.20, breaking the build of a dwarves
> > rpm when a libbpf package is installed in a fedora 33 system:
> > 
> > In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
> > /home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
> >     9 | #include <bpf/btf.h>
> >       |          ^~~~~~~~~~~
> > 
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > ---
> > 
> > I can understand reverting due to other pressure to get a release out
> > but most distros (including fedora) frown upon vendoring code so I think
> > it would be good to have back ultimately.
> > 
> > Did you or someone else (Luca?) ever take the time to look at it?
> > 
> > I don't see what would be so different with fedora to make this
> > unfixable, I'd be happy taking a look if nobody has so far.
> > Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> > package installed on fedora33?
> > 
> > 
> > Thanks,
> 
> Hi,
> 
> I did not realise it was reverted (if I was pinged and I missed it:
> sorry about that) - what was the issue precisely? This has been used on
> Ubuntu and Debian for a few months now, no problems reported.
> Happy to have a look too if needed.

As far as I can see, on Fedora 33 the only CMake option used is '-
DCMAKE_BUILD_TYPE=Release':

https://src.fedoraproject.org/rpms/dwarves/blob/f33/f/dwarves.spec

On my Debian system, with libbpf-dev installed and after re-instating
the patch on an up-to-date master branch of pahole.git, this builds
just fine:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
Cloning into 'pahole'...
remote: Enumerating objects: 6367, done.
remote: Total 6367 (delta 0), reused 0 (delta 0), pack-reused 6367
Receiving objects: 100% (6367/6367), 1.59 MiB | 11.49 MiB/s, done.
Resolving deltas: 100% (4450/4450), done.
$ cd pahole/
$ git revert 7943374
Auto-merging pahole.c
Auto-merging libbtf.h
Auto-merging libbtf.c
Auto-merging btf_loader.c
Auto-merging btf_encoder.c
Auto-merging CMakeLists.txt
[master 44b9227] Revert "Revert "libbpf: allow to use packaged version""
 9 files changed, 41 insertions(+), 24 deletions(-)
 create mode 120000 lib/include/bpf
$ mkdir b
$ cd b
$ cmake .. -DCMAKE_BUILD_TYPE=Release
-- The C compiler identification is GNU 8.3.0
-- Check for working C compiler: /usr/bin/ccache
-- Check for working C compiler: /usr/bin/ccache -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib/x86_64-linux-gnu/libdw.so
-- Found libelf library: /usr/lib/x86_64-linux-gnu/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11") 
-- Submodule update
Submodule 'lib/bpf' (https://github.com/libbpf/libbpf) registered for path 'lib/bpf'
Cloning into '/home/bluca/git/pahole/lib/bpf'...
Submodule path 'lib/bpf': checked out '986962fade5dfa89c2890f3854eb040d2a64ab38'
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/bluca/git/pahole/b
$ make -j5
Scanning dependencies of target bpf
[  1%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o
[  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o
[  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o
[  7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o
[  9%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o
[ 11%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o
[ 13%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o
[ 15%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o
[ 16%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o
[ 18%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o
[ 20%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o
[ 22%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o
[ 24%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o
[ 24%] Built target bpf
Scanning dependencies of target dwarves
[ 28%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
[ 28%] Building C object CMakeFiles/dwarves.dir/strings.c.o
[ 30%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
[ 32%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
[ 33%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
[ 35%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
[ 37%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
[ 39%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
[ 41%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
[ 43%] Building C object CMakeFiles/dwarves.dir/libbtf.c.o
[ 47%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
[ 47%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
[ 49%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
[ 50%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
[ 52%] Linking C shared library libdwarves.so
[ 52%] Built target dwarves
Scanning dependencies of target pglobal
Scanning dependencies of target dwarves_emit
Scanning dependencies of target codiff
Scanning dependencies of target dwarves_reorganize
Scanning dependencies of target dtagnames
[ 54%] Building C object CMakeFiles/pglobal.dir/pglobal.c.o
[ 56%] Building C object CMakeFiles/dwarves_emit.dir/dwarves_emit.c.o
[ 58%] Building C object CMakeFiles/codiff.dir/codiff.c.o
[ 60%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.c.o
[ 62%] Building C object CMakeFiles/dtagnames.dir/dtagnames.c.o
[ 64%] Linking C executable pglobal
[ 66%] Linking C shared library libdwarves_emit.so
[ 67%] Linking C executable codiff
[ 69%] Linking C shared library libdwarves_reorganize.so
[ 71%] Linking C executable dtagnames
[ 71%] Built target pglobal
[ 71%] Built target codiff
[ 71%] Built target dtagnames
Scanning dependencies of target prefcnt
[ 71%] Built target dwarves_emit
Scanning dependencies of target scncopy
Scanning dependencies of target syscse
[ 71%] Built target dwarves_reorganize
[ 73%] Building C object CMakeFiles/prefcnt.dir/prefcnt.c.o
Scanning dependencies of target pdwtags
[ 75%] Building C object CMakeFiles/scncopy.dir/scncopy.c.o
[ 77%] Building C object CMakeFiles/syscse.dir/syscse.c.o
[ 79%] Building C object CMakeFiles/scncopy.dir/elfcreator.c.o
[ 81%] Linking C executable prefcnt
[ 83%] Building C object CMakeFiles/pdwtags.dir/pdwtags.c.o
Scanning dependencies of target ctracer
[ 86%] Linking C executable scncopy
[ 86%] Linking C executable syscse
[ 88%] Linking C executable pdwtags
[ 90%] Building C object CMakeFiles/ctracer.dir/ctracer.c.o
[ 92%] Linking C executable ctracer
[ 92%] Built target prefcnt
[ 92%] Built target syscse
[ 92%] Built target scncopy
Scanning dependencies of target pfunct
Scanning dependencies of target pahole
[ 92%] Built target pdwtags
[ 94%] Building C object CMakeFiles/pfunct.dir/pfunct.c.o
[ 96%] Building C object CMakeFiles/pahole.dir/pahole.c.o
[ 96%] Built target ctracer
[ 98%] Linking C executable pfunct
[100%] Linking C executable pahole
[100%] Built target pahole
[100%] Built target pfunct

Is there anything else/some other steps that I am missing?

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Dominique Martinet]

Luca Boccassi wrote on Tue, Mar 30, 2021 at 12:06:09PM +0100:
> > I did not realise it was reverted (if I was pinged and I missed it:
> > sorry about that) - what was the issue precisely? This has been used on
> > Ubuntu and Debian for a few months now, no problems reported.
> > Happy to have a look too if needed.

(FWIW I also have used that patch for alpine linux, and got rebuked for
expliciting there is a vendored lib when pushing a nixos update so will
probably need it there as well)

> As far as I can see, on Fedora 33 the only CMake option used is '-
> DCMAKE_BUILD_TYPE=Release':
> 
> https://src.fedoraproject.org/rpms/dwarves/blob/f33/f/dwarves.spec
> 
> On my Debian system, with libbpf-dev installed and after re-instating
> the patch on an up-to-date master branch of pahole.git, this builds
> just fine:

I just got home where I have a fedora 33 machine and can confirm it
works for me on f33 as well.

I tried:
 - normal rpmbuild with libbpf + libbpf-devel / libbpf-static installed
 - just libbpf installed
 in both these cases it rebuilds the local libbpf (if the git tree is
 in the tarball it does the submodule checkout, if it's not it
 complains if libbpf wasn't previously checked out but uses it
 properly if it's there)
 
 - just to make sure I've done an extra build from the tarball obtained
with `fedpkg sources` and applying just the reverted patch manually;
this also worked as expected.

- I figured it might be a problem on another arch but I don't see
any failure on koji[1], so can't really test that easily.
[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=5540

 - For completeness I also tried building with fedora's libbpf-devel and
`-DLIBBPF_EMBEDDED=OFF` without any problem (it will obviously need a
libbpf update for the float types, but as of 1.20 it works fine with
libbpf 0.3)
----------
diff --git a/rpm/SPECS/dwarves.spec b/rpm/SPECS/dwarves.spec
index 98433e395b6c..f28bca0fa088 100644
--- a/rpm/SPECS/dwarves.spec
+++ b/rpm/SPECS/dwarves.spec
@@ -13,6 +13,7 @@ BuildRequires: gcc
 BuildRequires: cmake >= 2.8.12
 BuildRequires: zlib-devel
 BuildRequires: elfutils-devel >= 0.130
+BuildRequires: libbpf-devel
 
 %description
 dwarves is a set of tools that use the debugging information inserted in
@@ -67,7 +68,7 @@ Debugging information processing library development files.
 %setup -q
 
 %build
-%cmake -DCMAKE_BUILD_TYPE=Release .
+%cmake -DCMAKE_BUILD_TYPE=Release -DLIBBPF_EMBEDDED=OFF .
 %cmake_build
 
 %install
----------

Would appreciate more details if there's anything we can do; my guess is
that there might have been leftovers from a previous cmake run maybe
(potentially with previous versions of the patch) and just trying to
reproduce from a fresh build doesn't get us anywhere... cmake can be
annoying with its cache sometimes.


Thanks,
-- 
Dominique

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Tue, Mar 30, 2021 at 01:47:05PM +0900, Dominique Martinet escreveu:
> Hi,
> 
> I see this commit has been reverted just before the 1.20 release in Feb:
> ---
> Revert "libbpf: allow to use packaged version"
> 
> This reverts commit 82749180b23d3c9c060108bc290ae26507fc324e.
> 
> Getting in the way of releasing 1.20, breaking the build of a dwarves
> rpm when a libbpf package is installed in a fedora 33 system:
> 
> In file included from /home/acme/rpmbuild/BUILD/dwarves-1.20/strings.c:7:
> /home/acme/rpmbuild/BUILD/dwarves-1.20/pahole_strings.h:9:10: fatal error: bpf/btf.h: No such file or directory
>     9 | #include <bpf/btf.h>
>       |          ^~~~~~~~~~~
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> ---
> 
> I can understand reverting due to other pressure to get a release out
> but most distros (including fedora) frown upon vendoring code so I think
> it would be good to have back ultimately.
> 
> Did you or someone else (Luca?) ever take the time to look at it?

Not yet, I'm right now working on it, testing patches to support clang's
thin-LTO being used to build the kernel, so busy with it.
 
> I don't see what would be so different with fedora to make this
> unfixable, I'd be happy taking a look if nobody has so far.

Please do.

> Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> package installed on fedora33?

Sure. I had it merged, as, IIRC, it was a opt-in procedure.

- Arnaldo

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Dominique Martinet]

Arnaldo Carvalho de Melo wrote on Tue, Mar 30, 2021 at 12:12:07PM -0300:
> > I can understand reverting due to other pressure to get a release out
> > but most distros (including fedora) frown upon vendoring code so I think
> > it would be good to have back ultimately.
> > 
> > Did you or someone else (Luca?) ever take the time to look at it?
> 
> Not yet, I'm right now working on it, testing patches to support clang's
> thin-LTO being used to build the kernel, so busy with it.

Thanks


> > I don't see what would be so different with fedora to make this
> > unfixable, I'd be happy taking a look if nobody has so far.
> 
> Please do.

As said in my previous mail (in reply to Luca's), I cannot reproduce on
fedora 33 so I'm not sure where to look at.
Was the problem specific to one architecture (I only tried x86_64), or
maybe the build dir was tainted by a previous run of cmake with another
version of the patch? (if rpmbuild, build dir somehow included in the
tarball?)

Looking at the timing the libbpf version should have been identical but
it's possible that system wasn't up to date or some other version change
since Feb?

Either way I would appreciate if you could confirm you still have the
problem when you have a moment, and if so provide a bit more details on
your setup.


> > Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> > package installed on fedora33?
> 
> Sure. I had it merged, as, IIRC, it was a opt-in procedure.

Yes, strictly opt-in and shouldn't affect developers or people building
from git without explicitly requiring to use the system's version.

-- 
Dominique

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

On Wed, 2021-03-31 at 10:05 +0900, Dominique Martinet wrote:
> Arnaldo Carvalho de Melo wrote on Tue, Mar 30, 2021 at 12:12:07PM -0300:
> > > I can understand reverting due to other pressure to get a release out
> > > but most distros (including fedora) frown upon vendoring code so I think
> > > it would be good to have back ultimately.
> > > 
> > > Did you or someone else (Luca?) ever take the time to look at it?
> > 
> > Not yet, I'm right now working on it, testing patches to support clang's
> > thin-LTO being used to build the kernel, so busy with it.
> 
> Thanks
> 
> 
> > > I don't see what would be so different with fedora to make this
> > > unfixable, I'd be happy taking a look if nobody has so far.
> > 
> > Please do.
> 
> As said in my previous mail (in reply to Luca's), I cannot reproduce on
> fedora 33 so I'm not sure where to look at.
> Was the problem specific to one architecture (I only tried x86_64), or
> maybe the build dir was tainted by a previous run of cmake with another
> version of the patch? (if rpmbuild, build dir somehow included in the
> tarball?)
> 
> Looking at the timing the libbpf version should have been identical but
> it's possible that system wasn't up to date or some other version change
> since Feb?
> 
> Either way I would appreciate if you could confirm you still have the
> problem when you have a moment, and if so provide a bit more details on
> your setup.
> 
> 
> > > Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> > > package installed on fedora33?
> > 
> > Sure. I had it merged, as, IIRC, it was a opt-in procedure.
> 
> Yes, strictly opt-in and shouldn't affect developers or people building
> from git without explicitly requiring to use the system's version.
> 

Hello Arnaldo,

Any update on this?

Thanks!

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

On Tue, 2021-04-13 at 14:42 +0100, Luca Boccassi wrote:
> On Wed, 2021-03-31 at 10:05 +0900, Dominique Martinet wrote:
> > Arnaldo Carvalho de Melo wrote on Tue, Mar 30, 2021 at 12:12:07PM -0300:
> > > > I can understand reverting due to other pressure to get a release out
> > > > but most distros (including fedora) frown upon vendoring code so I think
> > > > it would be good to have back ultimately.
> > > > 
> > > > Did you or someone else (Luca?) ever take the time to look at it?
> > > 
> > > Not yet, I'm right now working on it, testing patches to support clang's
> > > thin-LTO being used to build the kernel, so busy with it.
> > 
> > Thanks
> > 
> > 
> > > > I don't see what would be so different with fedora to make this
> > > > unfixable, I'd be happy taking a look if nobody has so far.
> > > 
> > > Please do.
> > 
> > As said in my previous mail (in reply to Luca's), I cannot reproduce on
> > fedora 33 so I'm not sure where to look at.
> > Was the problem specific to one architecture (I only tried x86_64), or
> > maybe the build dir was tainted by a previous run of cmake with another
> > version of the patch? (if rpmbuild, build dir somehow included in the
> > tarball?)
> > 
> > Looking at the timing the libbpf version should have been identical but
> > it's possible that system wasn't up to date or some other version change
> > since Feb?
> > 
> > Either way I would appreciate if you could confirm you still have the
> > problem when you have a moment, and if so provide a bit more details on
> > your setup.
> > 
> > 
> > > > Would you take the patch back in if I somehow fix rpmbuild with a libbpf
> > > > package installed on fedora33?
> > > 
> > > Sure. I had it merged, as, IIRC, it was a opt-in procedure.
> > 
> > Yes, strictly opt-in and shouldn't affect developers or people building
> > from git without explicitly requiring to use the system's version.
> > 
> 
> Hello Arnaldo,
> 
> Any update on this?
> 
> Thanks!

Gentle ping. Anything we can do to help?

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Dominique Martinet]

Hello Arnaldo,

Luca Boccassi wrote on Tue, May 18, 2021 at 03:07:50PM +0100:
> On Tue, 2021-04-13 at 14:42 +0100, Luca Boccassi wrote:
>>>>> Would you take the patch back in if I somehow fix rpmbuild with a libbpf
>>>>> package installed on fedora33?
>>>> 
>>>> Sure. I had it merged, as, IIRC, it was a opt-in procedure.
>>> 
>>> Yes, strictly opt-in and shouldn't affect developers or people building
>>> from git without explicitly requiring to use the system's version.
>> 
>> Any update on this?
> 
> Gentle ping. Anything we can do to help?

I know we're being annoying, but would really appreciate if you could
find some time to look at this again.

I couldn't reproduce any build failure in various combinaisons on fedora
so would either need more input from you on how to reproduce or maybe it
was just a flake?
Either way please let us know if there's anything we can do.

Thanks,
-- 
Dominique

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Mon, Jan 04, 2021 at 10:16:22PM +0000, Luca Boccassi escreveu:
> Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> embedded version and the system version (searched via pkg-config)
> of libbpf. Set the embedded version as the default.
> 
> Signed-off-by: Luca Boccassi <bluca@debian.org>
> ---
> v2: switched default to use embedded version
> v3: add lib/include/bpf -> lib/bpf/src symlink to allow using 'system'
>     style #include everywhere, rather than #ifdefs.
>     Thanks Andrii for the suggestion!

I've updated it as I did a lot of refactorings, and here is why its
better to have it default to using the embedded libbpf:

⬢[acme@toolbox pahole]$ rpm -q libbpf-devel
libbpf-devel-0.3.0-2.fc34.x86_64
⬢[acme@toolbox pahole]$ cat /etc/redhat-release
Fedora release 34 (Thirty Four)
⬢[acme@toolbox pahole]$

⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release -DLIBBPF_EMBEDDED=Off .. ; cd ..
-- The C compiler identification is GNU 11.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3") 
-- Checking for module 'libbpf>=0.3.0'
--   Found libbpf, version 0.3.0
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib64/libdw.so
-- Found libelf library: /usr/lib64/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") 
-- Submodule update
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /var/home/acme/git/pahole/build
⬢[acme@toolbox pahole]$ m
make: Entering directory '/var/home/acme/git/pahole/build'
make[1]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target dwarves
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[  5%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
[  5%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
[ 10%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
[ 10%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
[ 12%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
[ 15%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
[ 17%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
[ 20%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
[ 25%] Building C object CMakeFiles/dwarves.dir/strings.c.o
[ 25%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
[ 28%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
[ 33%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
[ 33%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
/var/home/acme/git/pahole/btf_encoder.c:84:10: error: ‘BTF_KIND_FLOAT’ undeclared here (not in a function); did you mean ‘BTF_KIND_INT’?
   84 |         [BTF_KIND_FLOAT]        = "FLOAT",
      |          ^~~~~~~~~~~~~~
      |          BTF_KIND_INT
/var/home/acme/git/pahole/btf_encoder.c:84:10: error: array index in initializer not of integer type
/var/home/acme/git/pahole/btf_encoder.c:84:10: note: (near initialization for ‘btf_kind_str’)
/var/home/acme/git/pahole/btf_encoder.c:84:35: warning: excess elements in array initializer
   84 |         [BTF_KIND_FLOAT]        = "FLOAT",
      |                                   ^~~~~~~
/var/home/acme/git/pahole/btf_encoder.c:84:35: note: (near initialization for ‘btf_kind_str’)
/var/home/acme/git/pahole/btf_loader.c: In function ‘btf__load_types’:
/var/home/acme/git/pahole/btf_loader.c:455:22: error: ‘BTF_KIND_FLOAT’ undeclared (first use in this function); did you mean ‘BTF_KIND_INT’?
  455 |                 case BTF_KIND_FLOAT:
      |                      ^~~~~~~~~~~~~~
      |                      BTF_KIND_INT
/var/home/acme/git/pahole/btf_loader.c:455:22: note: each undeclared identifier is reported only once for each function it appears in
/var/home/acme/git/pahole/btf_encoder.c: In function ‘btf_encoder__add_float’:
/var/home/acme/git/pahole/btf_encoder.c:224:22: warning: implicit declaration of function ‘btf__add_float’; did you mean ‘btf__add_var’? [-Wimplicit-function-declaration]
  224 |         int32_t id = btf__add_float(encoder->btf, name, BITS_ROUNDUP_BYTES(bt->bit_size));
      |                      ^~~~~~~~~~~~~~
      |                      btf__add_var
make[2]: *** [CMakeFiles/dwarves.dir/build.make:186: CMakeFiles/dwarves.dir/btf_loader.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/dwarves.dir/build.make:173: CMakeFiles/dwarves.dir/btf_encoder.c.o] Error 1
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[1]: *** [CMakeFiles/Makefile2:173: CMakeFiles/dwarves.dir/all] Error 2
make[1]: Leaving directory '/var/home/acme/git/pahole/build'
make: *** [Makefile:149: all] Error 2
make: Leaving directory '/var/home/acme/git/pahole/build'
⬢[acme@toolbox pahole]$ 



With it off, the default, it works, so I'm applying this patch, will soon
appear in the tmp.master branch and then move to master.

⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release .. ; cd ..
-- The C compiler identification is GNU 11.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking availability of DWARF and ELF development libraries
-- Looking for dwfl_module_build_id in elf
-- Looking for dwfl_module_build_id in elf - found
-- Found dwarf.h header: /usr/include
-- Found elfutils/libdw.h header: /usr/include
-- Found libdw library: /usr/lib64/libdw.so
-- Found libelf library: /usr/lib64/libelf.so
-- Checking availability of DWARF and ELF development libraries - done
-- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") 
-- Submodule update
-- Submodule update - done
-- Performing Test HAVE_REALLOCARRAY_SUPPORT
-- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /var/home/acme/git/pahole/build
⬢[acme@toolbox pahole]$ m
make: Entering directory '/var/home/acme/git/pahole/build'
make[1]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target bpf
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[  3%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o
[  3%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o
[  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o
[  7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o
[  9%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o
[ 11%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o
[ 13%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o
[ 15%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o
[ 17%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o
[ 19%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o
[ 21%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o
[ 23%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o
[ 25%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 25%] Built target bpf
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target dwarves
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[ 28%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
[ 28%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
[ 30%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
[ 32%] Building C object CMakeFiles/dwarves.dir/strings.c.o
[ 34%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
[ 36%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
[ 38%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
[ 42%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
[ 42%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
[ 44%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
[ 48%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
[ 48%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
[ 50%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
[ 51%] Linking C shared library libdwarves.so
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 51%] Built target dwarves
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target codiff
Scanning dependencies of target syscse
Scanning dependencies of target dtagnames
Scanning dependencies of target scncopy
Scanning dependencies of target dwarves_reorganize
Scanning dependencies of target dwarves_emit
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target prefcnt
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target pdwtags
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target pglobal
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[ 55%] Building C object CMakeFiles/codiff.dir/codiff.c.o
[ 55%] Building C object CMakeFiles/dtagnames.dir/dtagnames.c.o
[ 57%] Building C object CMakeFiles/dwarves_emit.dir/dwarves_emit.c.o
[ 61%] Building C object CMakeFiles/scncopy.dir/elfcreator.c.o
[ 63%] Building C object CMakeFiles/prefcnt.dir/prefcnt.c.o
[ 63%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.c.o
[ 65%] Building C object CMakeFiles/pdwtags.dir/pdwtags.c.o
[ 69%] Building C object CMakeFiles/syscse.dir/syscse.c.o
[ 69%] Building C object CMakeFiles/pglobal.dir/pglobal.c.o
[ 71%] Building C object CMakeFiles/scncopy.dir/scncopy.c.o
[ 73%] Linking C executable dtagnames
[ 75%] Linking C executable prefcnt
[ 76%] Linking C executable syscse
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 80%] Linking C executable pdwtags
[ 80%] Linking C executable pglobal
[ 82%] Linking C executable scncopy
[ 82%] Built target dtagnames
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 82%] Built target prefcnt
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 82%] Built target syscse
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 84%] Linking C shared library libdwarves_reorganize.so
[ 86%] Linking C shared library libdwarves_emit.so
[ 86%] Built target pglobal
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 86%] Built target pdwtags
[ 86%] Built target scncopy
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 86%] Built target dwarves_reorganize
[ 86%] Built target dwarves_emit
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
Scanning dependencies of target pahole
Scanning dependencies of target ctracer
Scanning dependencies of target pfunct
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
make[2]: Entering directory '/var/home/acme/git/pahole/build'
[ 88%] Building C object CMakeFiles/pahole.dir/pahole.c.o
[ 90%] Building C object CMakeFiles/ctracer.dir/ctracer.c.o
[ 92%] Building C object CMakeFiles/pfunct.dir/pfunct.c.o
[ 94%] Linking C executable codiff
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 94%] Built target codiff
[ 96%] Linking C executable pfunct
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 98%] Linking C executable ctracer
[ 98%] Built target pfunct
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[ 98%] Built target ctracer
[100%] Linking C executable pahole
make[2]: Leaving directory '/var/home/acme/git/pahole/build'
[100%] Built target pahole
make[1]: Leaving directory '/var/home/acme/git/pahole/build'
make: Leaving directory '/var/home/acme/git/pahole/build'
⬢[acme@toolbox pahole]$

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Arnaldo Carvalho de Melo]

Em Wed, Jun 09, 2021 at 01:25:41PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 04, 2021 at 10:16:22PM +0000, Luca Boccassi escreveu:
> > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > embedded version and the system version (searched via pkg-config)
> > of libbpf. Set the embedded version as the default.
> > 
> > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > ---
> > v2: switched default to use embedded version
> > v3: add lib/include/bpf -> lib/bpf/src symlink to allow using 'system'
> >     style #include everywhere, rather than #ifdefs.
> >     Thanks Andrii for the suggestion!
> 
> I've updated it as I did a lot of refactorings, and here is why its
> better to have it default to using the embedded libbpf:

It is now at:

https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=tmp.master&id=ae2581647e84948810ba209f3891359dd4540110

After some more tests I'll move it to master.

- Arnaldo
 
> ⬢[acme@toolbox pahole]$ rpm -q libbpf-devel
> libbpf-devel-0.3.0-2.fc34.x86_64
> ⬢[acme@toolbox pahole]$ cat /etc/redhat-release
> Fedora release 34 (Thirty Four)
> ⬢[acme@toolbox pahole]$
> 
> ⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release -DLIBBPF_EMBEDDED=Off .. ; cd ..
> -- The C compiler identification is GNU 11.1.1
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3") 
> -- Checking for module 'libbpf>=0.3.0'
> --   Found libbpf, version 0.3.0
> -- Checking availability of DWARF and ELF development libraries
> -- Looking for dwfl_module_build_id in elf
> -- Looking for dwfl_module_build_id in elf - found
> -- Found dwarf.h header: /usr/include
> -- Found elfutils/libdw.h header: /usr/include
> -- Found libdw library: /usr/lib64/libdw.so
> -- Found libelf library: /usr/lib64/libelf.so
> -- Checking availability of DWARF and ELF development libraries - done
> -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") 
> -- Submodule update
> -- Submodule update - done
> -- Performing Test HAVE_REALLOCARRAY_SUPPORT
> -- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /var/home/acme/git/pahole/build
> ⬢[acme@toolbox pahole]$ m
> make: Entering directory '/var/home/acme/git/pahole/build'
> make[1]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target dwarves
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> [  5%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
> [  5%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
> [ 10%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
> [ 10%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
> [ 12%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
> [ 15%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
> [ 17%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
> [ 20%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
> [ 25%] Building C object CMakeFiles/dwarves.dir/strings.c.o
> [ 25%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
> [ 28%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
> [ 33%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
> [ 33%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
> /var/home/acme/git/pahole/btf_encoder.c:84:10: error: ‘BTF_KIND_FLOAT’ undeclared here (not in a function); did you mean ‘BTF_KIND_INT’?
>    84 |         [BTF_KIND_FLOAT]        = "FLOAT",
>       |          ^~~~~~~~~~~~~~
>       |          BTF_KIND_INT
> /var/home/acme/git/pahole/btf_encoder.c:84:10: error: array index in initializer not of integer type
> /var/home/acme/git/pahole/btf_encoder.c:84:10: note: (near initialization for ‘btf_kind_str’)
> /var/home/acme/git/pahole/btf_encoder.c:84:35: warning: excess elements in array initializer
>    84 |         [BTF_KIND_FLOAT]        = "FLOAT",
>       |                                   ^~~~~~~
> /var/home/acme/git/pahole/btf_encoder.c:84:35: note: (near initialization for ‘btf_kind_str’)
> /var/home/acme/git/pahole/btf_loader.c: In function ‘btf__load_types’:
> /var/home/acme/git/pahole/btf_loader.c:455:22: error: ‘BTF_KIND_FLOAT’ undeclared (first use in this function); did you mean ‘BTF_KIND_INT’?
>   455 |                 case BTF_KIND_FLOAT:
>       |                      ^~~~~~~~~~~~~~
>       |                      BTF_KIND_INT
> /var/home/acme/git/pahole/btf_loader.c:455:22: note: each undeclared identifier is reported only once for each function it appears in
> /var/home/acme/git/pahole/btf_encoder.c: In function ‘btf_encoder__add_float’:
> /var/home/acme/git/pahole/btf_encoder.c:224:22: warning: implicit declaration of function ‘btf__add_float’; did you mean ‘btf__add_var’? [-Wimplicit-function-declaration]
>   224 |         int32_t id = btf__add_float(encoder->btf, name, BITS_ROUNDUP_BYTES(bt->bit_size));
>       |                      ^~~~~~~~~~~~~~
>       |                      btf__add_var
> make[2]: *** [CMakeFiles/dwarves.dir/build.make:186: CMakeFiles/dwarves.dir/btf_loader.c.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [CMakeFiles/dwarves.dir/build.make:173: CMakeFiles/dwarves.dir/btf_encoder.c.o] Error 1
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[1]: *** [CMakeFiles/Makefile2:173: CMakeFiles/dwarves.dir/all] Error 2
> make[1]: Leaving directory '/var/home/acme/git/pahole/build'
> make: *** [Makefile:149: all] Error 2
> make: Leaving directory '/var/home/acme/git/pahole/build'
> ⬢[acme@toolbox pahole]$ 
> 
> 
> 
> With it off, the default, it works, so I'm applying this patch, will soon
> appear in the tmp.master branch and then move to master.
> 
> ⬢[acme@toolbox pahole]$ rm -rf build ; mkdir build ; cd build ; cmake -DCMAKE_BUILD_TYPE=Release .. ; cd ..
> -- The C compiler identification is GNU 11.1.1
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Checking availability of DWARF and ELF development libraries
> -- Looking for dwfl_module_build_id in elf
> -- Looking for dwfl_module_build_id in elf - found
> -- Found dwarf.h header: /usr/include
> -- Found elfutils/libdw.h header: /usr/include
> -- Found libdw library: /usr/lib64/libdw.so
> -- Found libelf library: /usr/lib64/libelf.so
> -- Checking availability of DWARF and ELF development libraries - done
> -- Found ZLIB: /usr/lib64/libz.so (found version "1.2.11") 
> -- Submodule update
> -- Submodule update - done
> -- Performing Test HAVE_REALLOCARRAY_SUPPORT
> -- Performing Test HAVE_REALLOCARRAY_SUPPORT - Success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /var/home/acme/git/pahole/build
> ⬢[acme@toolbox pahole]$ m
> make: Entering directory '/var/home/acme/git/pahole/build'
> make[1]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target bpf
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> [  3%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf.c.o
> [  3%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf.c.o
> [  5%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/bpf_prog_linfo.c.o
> [  7%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/btf_dump.c.o
> [  9%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/hashmap.c.o
> [ 11%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf.c.o
> [ 13%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_errno.c.o
> [ 15%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/ringbuf.c.o
> [ 17%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/libbpf_probes.c.o
> [ 19%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/netlink.c.o
> [ 21%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/nlattr.c.o
> [ 23%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/str_error.c.o
> [ 25%] Building C object CMakeFiles/bpf.dir/lib/bpf/src/xsk.c.o
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 25%] Built target bpf
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target dwarves
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> [ 28%] Building C object CMakeFiles/dwarves.dir/dwarves.c.o
> [ 28%] Building C object CMakeFiles/dwarves.dir/dwarves_fprintf.c.o
> [ 30%] Building C object CMakeFiles/dwarves.dir/gobuffer.c.o
> [ 32%] Building C object CMakeFiles/dwarves.dir/strings.c.o
> [ 34%] Building C object CMakeFiles/dwarves.dir/ctf_encoder.c.o
> [ 36%] Building C object CMakeFiles/dwarves.dir/libctf.c.o
> [ 38%] Building C object CMakeFiles/dwarves.dir/dutil.c.o
> [ 42%] Building C object CMakeFiles/dwarves.dir/btf_encoder.c.o
> [ 42%] Building C object CMakeFiles/dwarves.dir/btf_loader.c.o
> [ 44%] Building C object CMakeFiles/dwarves.dir/ctf_loader.c.o
> [ 48%] Building C object CMakeFiles/dwarves.dir/elf_symtab.c.o
> [ 48%] Building C object CMakeFiles/dwarves.dir/rbtree.c.o
> [ 50%] Building C object CMakeFiles/dwarves.dir/dwarf_loader.c.o
> [ 51%] Linking C shared library libdwarves.so
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 51%] Built target dwarves
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target codiff
> Scanning dependencies of target syscse
> Scanning dependencies of target dtagnames
> Scanning dependencies of target scncopy
> Scanning dependencies of target dwarves_reorganize
> Scanning dependencies of target dwarves_emit
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target prefcnt
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target pdwtags
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target pglobal
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> [ 55%] Building C object CMakeFiles/codiff.dir/codiff.c.o
> [ 55%] Building C object CMakeFiles/dtagnames.dir/dtagnames.c.o
> [ 57%] Building C object CMakeFiles/dwarves_emit.dir/dwarves_emit.c.o
> [ 61%] Building C object CMakeFiles/scncopy.dir/elfcreator.c.o
> [ 63%] Building C object CMakeFiles/prefcnt.dir/prefcnt.c.o
> [ 63%] Building C object CMakeFiles/dwarves_reorganize.dir/dwarves_reorganize.c.o
> [ 65%] Building C object CMakeFiles/pdwtags.dir/pdwtags.c.o
> [ 69%] Building C object CMakeFiles/syscse.dir/syscse.c.o
> [ 69%] Building C object CMakeFiles/pglobal.dir/pglobal.c.o
> [ 71%] Building C object CMakeFiles/scncopy.dir/scncopy.c.o
> [ 73%] Linking C executable dtagnames
> [ 75%] Linking C executable prefcnt
> [ 76%] Linking C executable syscse
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 80%] Linking C executable pdwtags
> [ 80%] Linking C executable pglobal
> [ 82%] Linking C executable scncopy
> [ 82%] Built target dtagnames
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 82%] Built target prefcnt
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 82%] Built target syscse
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 84%] Linking C shared library libdwarves_reorganize.so
> [ 86%] Linking C shared library libdwarves_emit.so
> [ 86%] Built target pglobal
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 86%] Built target pdwtags
> [ 86%] Built target scncopy
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 86%] Built target dwarves_reorganize
> [ 86%] Built target dwarves_emit
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> Scanning dependencies of target pahole
> Scanning dependencies of target ctracer
> Scanning dependencies of target pfunct
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> make[2]: Entering directory '/var/home/acme/git/pahole/build'
> [ 88%] Building C object CMakeFiles/pahole.dir/pahole.c.o
> [ 90%] Building C object CMakeFiles/ctracer.dir/ctracer.c.o
> [ 92%] Building C object CMakeFiles/pfunct.dir/pfunct.c.o
> [ 94%] Linking C executable codiff
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 94%] Built target codiff
> [ 96%] Linking C executable pfunct
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 98%] Linking C executable ctracer
> [ 98%] Built target pfunct
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [ 98%] Built target ctracer
> [100%] Linking C executable pahole
> make[2]: Leaving directory '/var/home/acme/git/pahole/build'
> [100%] Built target pahole
> make[1]: Leaving directory '/var/home/acme/git/pahole/build'
> make: Leaving directory '/var/home/acme/git/pahole/build'
> ⬢[acme@toolbox pahole]$

-- 

- Arnaldo

Re: [PATCH dwarves v3] libbpf: allow to use packaged version

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Wed, 2021-06-09 at 13:38 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jun 09, 2021 at 01:25:41PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Jan 04, 2021 at 10:16:22PM +0000, Luca Boccassi escreveu:
> > > Add a new CMake option, LIBBPF_EMBEDDED, to switch between the
> > > embedded version and the system version (searched via pkg-config)
> > > of libbpf. Set the embedded version as the default.
> > > 
> > > Signed-off-by: Luca Boccassi <bluca@debian.org>
> > > ---
> > > v2: switched default to use embedded version
> > > v3: add lib/include/bpf -> lib/bpf/src symlink to allow using 'system'
> > >     style #include everywhere, rather than #ifdefs.
> > >     Thanks Andrii for the suggestion!
> > 
> > I've updated it as I did a lot of refactorings, and here is why its
> > better to have it default to using the embedded libbpf:
> 
> It is now at:
> 
> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?h=tmp.master&id=ae2581647e84948810ba209f3891359dd4540110
> 
> After some more tests I'll move it to master.
> 
> - Arnaldo

Fantastic, thank you very much!

If there are any issues encountered during testing, please do not
hesitate to contact myself or Dominique.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]