| Message ID | 20170405101410.27980-1-arnout@mind.be |
|---|---|
| State | Accepted |
| Headers | show |
Hello, On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle (Essensium/Mind) wrote: > On the br-arm-cortex-m4-full toolchain, the build fails with a > segmentation fault in elf2flt, so add an exception for ARM FLAT > toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > --- > I tried to debug the elf2flt segfault but elf2flt isn't exactly the > most low-entry-bar source code... I think we have a regression here, which I would point to the bump of binutils from 2.26 to 2.27. Indeed, several packages are now causing segfaults in elf2flt on ARM: Busybox: http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log pcre: http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log and I'm sure the list will grow. So I believe that binutils 2.27 produces binaries that are a bit different, and confuse elf2flt. Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I don't see anything that particular stands out. Best regards, Thomas
Hello, On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle (Essensium/Mind) wrote: > On the br-arm-cortex-m4-full toolchain, the build fails with a > segmentation fault in elf2flt, so add an exception for ARM FLAT > toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > --- > I tried to debug the elf2flt segfault but elf2flt isn't exactly the > most low-entry-bar source code... Applied to master, thanks. However, I've dropped the elf2flt related exception, since it really isn't a bug with this package, but a bug with binutils/elf2flt, which we encounter with other packages as well. Thanks! Thomas
On 05-04-17 18:34, Thomas Petazzoni wrote: > Hello, > > On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle > (Essensium/Mind) wrote: >> On the br-arm-cortex-m4-full toolchain, the build fails with a >> segmentation fault in elf2flt, so add an exception for ARM FLAT >> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. >> >> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> >> --- >> I tried to debug the elf2flt segfault but elf2flt isn't exactly the >> most low-entry-bar source code... > > I think we have a regression here, which I would point to the bump of > binutils from 2.26 to 2.27. Indeed, several packages are now causing > segfaults in elf2flt on ARM: > > Busybox: > > http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log > > pcre: > > http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log > > and I'm sure the list will grow. So I believe that binutils 2.27 > produces binaries that are a bit different, and confuse elf2flt. > > Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I > don't see anything that particular stands out. Since it was caused by the bump of binutils, you should probably look at the binutils repo, not the elf2flt repo... Probably needs bisecting to find the culprit. Or we could try bumping to current 2_27_branch head and see if it solves the issue. Regards, Arnout
Hello, On Thu, 6 Apr 2017 10:26:58 +0200, Arnout Vandecappelle wrote: > Since it was caused by the bump of binutils, you should probably look at the > binutils repo, not the elf2flt repo... That was not my reasoning. My reasoning was that the new binutils version does not have a bug, but generates a binary that is slightly different than previous binutils version, and elf2flt does not handle that correctly. Of course, that's complete guess, but binutils is IMO a much better maintained set of tools than elf2flt, so I would first and foremost suspect a bug in elf2flt. Best regards, Thomas
On 06-04-17 10:33, Thomas Petazzoni wrote: > Hello, > > On Thu, 6 Apr 2017 10:26:58 +0200, Arnout Vandecappelle wrote: > >> Since it was caused by the bump of binutils, you should probably look at the >> binutils repo, not the elf2flt repo... > > That was not my reasoning. My reasoning was that the new binutils > version does not have a bug, but generates a binary that is slightly > different than previous binutils version, and elf2flt does not handle > that correctly. > > Of course, that's complete guess, but binutils is IMO a much better > maintained set of tools than elf2flt, so I would first and foremost > suspect a bug in elf2flt. Of course, but it would be a bug that is triggered by a change in binutils. Looking at the commits in elf2flt is not going to help. And reading elf2flt.c is a challenge, I would say... Regards, Arnout
Hello, On Thu, 6 Apr 2017 10:42:38 +0200, Arnout Vandecappelle wrote: > Of course, but it would be a bug that is triggered by a change in binutils. > Looking at the commits in elf2flt is not going to help. Except if someone has already noticed and fixed the binutils 2.27 compatibility bug. Best regards, Thomas
Hi Thomas, Thomas Petazzoni wrote, > Hello, > > On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle > (Essensium/Mind) wrote: > > On the br-arm-cortex-m4-full toolchain, the build fails with a > > segmentation fault in elf2flt, so add an exception for ARM FLAT > > toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. > > > > Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> > > --- > > I tried to debug the elf2flt segfault but elf2flt isn't exactly the > > most low-entry-bar source code... > > I think we have a regression here, which I would point to the bump of > binutils from 2.26 to 2.27. Indeed, several packages are now causing > segfaults in elf2flt on ARM: > > Busybox: > > http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log > > pcre: > > http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log > > and I'm sure the list will grow. So I believe that binutils 2.27 > produces binaries that are a bit different, and confuse elf2flt. > > Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I > don't see anything that particular stands out. It seems this is somehow fixed with binutils 2.28. But I have no idea in which commit(s). Should we blacklist binutils 2.27 for ARM noMMU? best regards Waldemar
On 08-04-17 20:03, Waldemar Brodkorb wrote: > Hi Thomas, > Thomas Petazzoni wrote, > >> Hello, >> >> On Wed, 5 Apr 2017 12:14:10 +0200, Arnout Vandecappelle >> (Essensium/Mind) wrote: >>> On the br-arm-cortex-m4-full toolchain, the build fails with a >>> segmentation fault in elf2flt, so add an exception for ARM FLAT >>> toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. >>> >>> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> >>> --- >>> I tried to debug the elf2flt segfault but elf2flt isn't exactly the >>> most low-entry-bar source code... >> >> I think we have a regression here, which I would point to the bump of >> binutils from 2.26 to 2.27. Indeed, several packages are now causing >> segfaults in elf2flt on ARM: >> >> Busybox: >> >> http://autobuild.buildroot.net/results/475/4758354f0e2f7f127c1a99ef7846eb62f5ce41b5/build-end.log >> >> pcre: >> >> http://autobuild.buildroot.net/results/68c/68cf951594b0e67b45f8711745c17b93e2fbc03e/build-end.log >> >> and I'm sure the list will grow. So I believe that binutils 2.27 >> produces binaries that are a bit different, and confuse elf2flt. >> >> Looking at https://github.com/uclinux-dev/elf2flt/commits/master, I >> don't see anything that particular stands out. > > It seems this is somehow fixed with binutils 2.28. But I have no > idea in which commit(s). Thanks for the hint! I bisected it to commit 4ba2ef8fbe7. Its parent 024425668d1 fails, but 4ba2ef8fbe7 doesn't. Unfortunately, binutils is such a heap of [fill in something unsavoury] that I have a hard time understanding what that patch could do. I'll see if I can backport it. Regards, Arnout > Should we blacklist binutils 2.27 for ARM > noMMU? > > best regards > Waldemar >
diff --git a/DEVELOPERS b/DEVELOPERS index c89468b075..76da20b2c6 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -104,6 +104,7 @@ N: Arnaud Aujon <arnaud@intelibre.fr> F: package/espeak/ N: Arnout Vandecappelle <arnout@mind.be> +F: package/arp-scan/ F: package/freescale-imx/firmware-imx/ F: package/freescale-imx/imx-lib/ F: package/gstreamer/gst-fsl-plugins/ diff --git a/package/Config.in b/package/Config.in index d6d134d0ca..aa304eb0ff 100644 --- a/package/Config.in +++ b/package/Config.in @@ -1494,6 +1494,7 @@ menu "Networking applications" source "package/aircrack-ng/Config.in" source "package/apache/Config.in" source "package/argus/Config.in" + source "package/arp-scan/Config.in" source "package/arptables/Config.in" source "package/atftp/Config.in" source "package/autossh/Config.in" diff --git a/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch b/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch new file mode 100644 index 0000000000..8eb9d6eff4 --- /dev/null +++ b/package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch @@ -0,0 +1,39 @@ +From f406041b58eadc716d6227408d3af553d566ffeb Mon Sep 17 00:00:00 2001 +From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be> +Date: Tue, 4 Apr 2017 17:31:29 +0200 +Subject: [PATCH] configure: try linking to detect stack-protector support + +Even if gcc accepts the -fstack-protector argument, it is possible that +the libssp support library is missing. Detect this by linking instead +of just compiling. + +Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> +--- + acinclude.m4 | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/acinclude.m4 b/acinclude.m4 +index 3c84118..4725154 100644 +--- a/acinclude.m4 ++++ b/acinclude.m4 +@@ -243,7 +243,7 @@ AC_DEFUN([GCC_STACK_PROTECT_CC],[ + AC_MSG_CHECKING([whether ${CC} accepts -fstack-protector]) + ssp_old_cflags="$CFLAGS" + CFLAGS="$CFLAGS -fstack-protector" +- AC_TRY_COMPILE(,,, ssp_cc=no) ++ AC_TRY_LINK(,,, ssp_cc=no) + echo $ssp_cc + if test "X$ssp_cc" = "Xno"; then + CFLAGS="$ssp_old_cflags" +@@ -259,7 +259,7 @@ AC_DEFUN([GCC_STACK_PROTECT_CXX],[ + AC_MSG_CHECKING([whether ${CXX} accepts -fstack-protector]) + ssp_old_cxxflags="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -fstack-protector" +- AC_TRY_COMPILE(,,, ssp_cxx=no) ++ AC_TRY_LINK(,,, ssp_cxx=no) + echo $ssp_cxx + if test "X$ssp_cxx" = "Xno"; then + CXXFLAGS="$ssp_old_cxxflags" +-- +2.11.0 + diff --git a/package/arp-scan/Config.in b/package/arp-scan/Config.in new file mode 100644 index 0000000000..8fa3235434 --- /dev/null +++ b/package/arp-scan/Config.in @@ -0,0 +1,11 @@ +config BR2_PACKAGE_ARP_SCAN + bool "arp-scan" + depends on !(BR2_arm && BR2_BINFMT_FLAT) # SEGV in elf2flt + select BR2_PACKAGE_LIBPCAP + help + The ARP scanner + + arp-scan is a command-line tool that uses the ARP protocol to + discover and fingerprint IP hosts on the local network. + + http://www.nta-monitor.com/wiki/index.php/Arp-scan_Documentation diff --git a/package/arp-scan/arp-scan.hash b/package/arp-scan/arp-scan.hash new file mode 100644 index 0000000000..4b2ddf1816 --- /dev/null +++ b/package/arp-scan/arp-scan.hash @@ -0,0 +1,2 @@ +# Locally calculated +sha256 ce908ac71c48e85dddf6dd4fe5151d13c7528b1f49717a98b2a2535bd797d892 arp-scan-1.9.tar.gz diff --git a/package/arp-scan/arp-scan.mk b/package/arp-scan/arp-scan.mk new file mode 100644 index 0000000000..fc3740bf57 --- /dev/null +++ b/package/arp-scan/arp-scan.mk @@ -0,0 +1,18 @@ +################################################################################ +# +# arp-scan +# +################################################################################ + +ARP_SCAN_VERSION = 1.9 +ARP_SCAN_SITE = https://github.com/royhills/arp-scan/releases/download/$(ARP_SCAN_VERSION) +ARP_SCAN_LICENSE = GPL-3.0+ +ARP_SCAN_LICENSE_FILES = COPYING +ARP_SCAN_DEPENDENCIES = libpcap + +# 0001-configure-try-linking-to-detect-stack-protector-supp.patch touches acinclude.m4 +ARP_SCAN_AUTORECONF = YES + +ARP_SCAN_CONF_ENV = pgac_cv_snprintf_long_long_int_format='%lld' + +$(eval $(autotools-package))
On the br-arm-cortex-m4-full toolchain, the build fails with a segmentation fault in elf2flt, so add an exception for ARM FLAT toolchains. Other FLAT toolchains (e.g. br-m68k-5208-full) work fine. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> --- I tried to debug the elf2flt segfault but elf2flt isn't exactly the most low-entry-bar source code... v2: ad myself to DEVELOPERS --- DEVELOPERS | 1 + package/Config.in | 1 + ...ry-linking-to-detect-stack-protector-supp.patch | 39 ++++++++++++++++++++++ package/arp-scan/Config.in | 11 ++++++ package/arp-scan/arp-scan.hash | 2 ++ package/arp-scan/arp-scan.mk | 18 ++++++++++ 6 files changed, 72 insertions(+) create mode 100644 package/arp-scan/0001-configure-try-linking-to-detect-stack-protector-supp.patch create mode 100644 package/arp-scan/Config.in create mode 100644 package/arp-scan/arp-scan.hash create mode 100644 package/arp-scan/arp-scan.mk