public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* Re: [PATCH] Fix BPF check for kernels < 3.20
@ 2016-08-31 14:21 Mark Wielaard
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Wielaard @ 2016-08-31 14:21 UTC (permalink / raw)
  To: elfutils-devel

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

On Tue, 2016-08-30 at 23:38 +0200, Julian Ospald wrote:
> -dnl Check if we have <linux/bpf.h> for EM_BPF disassembly.
> -AC_CHECK_HEADERS(linux/bpf.h)
> -AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "x$ac_cv_header_linux_bpf_h" = "xyes"])
> +dnl Check if we have <linux/bpf.h> for EM_BPF disassembly and it has the required defines
> +AC_COMPILE_IFELSE(
> +	[AC_LANG_PROGRAM(
> +		[#include <linux/bpf.h>],
> +		[int foo=BPF_PSEUDO_MAP_FD; return 0;]
> +		)],
> +	[have_bpf="true"],
> +	[have_bpf="false"]
> +)
> +
> +if test "$have_bpf" = "true" ; then
> +	AC_DEFINE([HAVE_LINUX_BPF_H], [1], [if we have <linux/bpf.h> for EM_BPF disassembly])
> +fi
> +AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "$have_bpf" = "true"])

Thanks, that does look like the correct configure check.

But it seems that BPF_PSEUDO_MAP_FD is the only missing constant
introduced since 3.18 (when linux/bpf.h was added) that we use.
So maybe we could simply define it ourselves when not found. So we can
build against any linux/bpf.h out there.

What do people think of the following?

diff --git a/libcpu/bpf_disasm.c b/libcpu/bpf_disasm.c
index 153dba9..e4bbae4 100644
--- a/libcpu/bpf_disasm.c
+++ b/libcpu/bpf_disasm.c
@@ -40,6 +40,10 @@
 #include "../libelf/common.h"
 #include "../libebl/libeblP.h"
 
+/* BPF_PSEUDO_MAP_FD was only introduced in linux 3.20.  */
+#ifndef BPF_PSEUDO_MAP_FD
+  #define BPF_PSEUDO_MAP_FD 1
+#endif
 
 static const char class_string[8][8] = {
   [BPF_LD]    = "ld",

Thanks,

Mark

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Fix BPF check for kernels < 3.20
@ 2016-09-07 10:13 Mark Wielaard
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Wielaard @ 2016-09-07 10:13 UTC (permalink / raw)
  To: elfutils-devel

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

On Tue, 2016-09-06 at 10:00 -0700, Richard Henderson wrote:
> On 09/05/2016 02:21 AM, Mark Wielaard wrote:
> > On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
> >> > Thanks, that does look like the correct configure check.
> >> >
> >> > But it seems that BPF_PSEUDO_MAP_FD is the only missing constant
> >> > introduced since 3.18 (when linux/bpf.h was added) that we use.
> >> > So maybe we could simply define it ourselves when not found. So we can
> >> > build against any linux/bpf.h out there.
> >> >
> >> > What do people think of the following?
> > I tested it against the latest stable kernel and headers from the 3.18
> > kernel and it seems to work fine. Any objections to commit the attached?
> 
> None.

Thanks. Pushed to master.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Fix BPF check for kernels < 3.20
@ 2016-09-06 17:00 Richard Henderson
  0 siblings, 0 replies; 5+ messages in thread
From: Richard Henderson @ 2016-09-06 17:00 UTC (permalink / raw)
  To: elfutils-devel

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

On 09/05/2016 02:21 AM, Mark Wielaard wrote:
> On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
>> > Thanks, that does look like the correct configure check.
>> >
>> > But it seems that BPF_PSEUDO_MAP_FD is the only missing constant
>> > introduced since 3.18 (when linux/bpf.h was added) that we use.
>> > So maybe we could simply define it ourselves when not found. So we can
>> > build against any linux/bpf.h out there.
>> >
>> > What do people think of the following?
> I tested it against the latest stable kernel and headers from the 3.18
> kernel and it seems to work fine. Any objections to commit the attached?

None.


r~

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Fix BPF check for kernels < 3.20
@ 2016-09-05  9:21 Mark Wielaard
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Wielaard @ 2016-09-05  9:21 UTC (permalink / raw)
  To: elfutils-devel

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

On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
> Thanks, that does look like the correct configure check.
> 
> But it seems that BPF_PSEUDO_MAP_FD is the only missing constant
> introduced since 3.18 (when linux/bpf.h was added) that we use.
> So maybe we could simply define it ourselves when not found. So we can
> build against any linux/bpf.h out there.
> 
> What do people think of the following?

I tested it against the latest stable kernel and headers from the 3.18
kernel and it seems to work fine. Any objections to commit the attached?

Thanks,

Mark

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-libcpu-Fix-build-of-bpf_disasm.c-for-kernels-3.20.patch --]
[-- Type: text/x-patch, Size: 1272 bytes --]

From 4f7b5ba9624489b5a2f714569c29ef865d4dcd6f Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mjw@redhat.com>
Date: Mon, 5 Sep 2016 11:15:50 +0200
Subject: [PATCH] libcpu: Fix build of bpf_disasm.c for kernels < 3.20.

Before linux 3.20 the BPF_PSEUDO_MAP_FD constant wasn't defined.

Reported-by: Julian Ospald <hasufell@posteo.de>
Signed-off-by: Mark Wielaard <mjw@redhat.com>
---
 libcpu/ChangeLog    | 4 ++++
 libcpu/bpf_disasm.c | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/libcpu/ChangeLog b/libcpu/ChangeLog
index 9f3566c..9cce4e7 100644
--- a/libcpu/ChangeLog
+++ b/libcpu/ChangeLog
@@ -1,3 +1,7 @@
+2016-09-05  Mark Wielaard  <mjw@redhat.com>
+
+	* bpf_disasm.c: Define BPF_PSEUDO_MAP_FD if undefined.
+
 2016-08-10  Richard Henderson  <rth@redhat.com>
 
 	* bpf_disasm.c (bpf_disasm): Rearrange the printing of instructions
diff --git a/libcpu/bpf_disasm.c b/libcpu/bpf_disasm.c
index 153dba9..e4bbae4 100644
--- a/libcpu/bpf_disasm.c
+++ b/libcpu/bpf_disasm.c
@@ -40,6 +40,10 @@
 #include "../libelf/common.h"
 #include "../libebl/libeblP.h"
 
+/* BPF_PSEUDO_MAP_FD was only introduced in linux 3.20.  */
+#ifndef BPF_PSEUDO_MAP_FD
+  #define BPF_PSEUDO_MAP_FD 1
+#endif
 
 static const char class_string[8][8] = {
   [BPF_LD]    = "ld",
-- 
1.8.3.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [PATCH] Fix BPF check for kernels < 3.20
@ 2016-08-30 21:38 Julian Ospald
  0 siblings, 0 replies; 5+ messages in thread
From: Julian Ospald @ 2016-08-30 21:38 UTC (permalink / raw)
  To: elfutils-devel

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

Signed-off-by: Julian Ospald <hasufell@posteo.de>
---
 configure.ac | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index e5503f1..a69e2dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -331,9 +331,20 @@ else
 fi
 AC_SUBST([argp_LDADD])
 
-dnl Check if we have <linux/bpf.h> for EM_BPF disassembly.
-AC_CHECK_HEADERS(linux/bpf.h)
-AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "x$ac_cv_header_linux_bpf_h" = "xyes"])
+dnl Check if we have <linux/bpf.h> for EM_BPF disassembly and it has the required defines
+AC_COMPILE_IFELSE(
+	[AC_LANG_PROGRAM(
+		[#include <linux/bpf.h>],
+		[int foo=BPF_PSEUDO_MAP_FD; return 0;]
+		)],
+	[have_bpf="true"],
+	[have_bpf="false"]
+)
+
+if test "$have_bpf" = "true" ; then
+	AC_DEFINE([HAVE_LINUX_BPF_H], [1], [if we have <linux/bpf.h> for EM_BPF disassembly])
+fi
+AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "$have_bpf" = "true"])
 
 dnl The directories with content.
 
-- 
2.9.3

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-09-07 10:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-31 14:21 [PATCH] Fix BPF check for kernels < 3.20 Mark Wielaard
  -- strict thread matches above, loose matches on Subject: below --
2016-09-07 10:13 Mark Wielaard
2016-09-06 17:00 Richard Henderson
2016-09-05  9:21 Mark Wielaard
2016-08-30 21:38 Julian Ospald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).