Bug 1306382 - epel7 sipp-3.4.1 FTBFS on aarch64
epel7 sipp-3.4.1 FTBFS on aarch64
Status: CLOSED ERRATA
Product: Fedora EPEL
Classification: Fedora
Component: sipp (Show other bugs)
epel7
aarch64 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
:
Depends On: 1300543
Blocks: 1277314 epel7aarch64
  Show dependency treegraph
 
Reported: 2016-02-10 12:01 EST by D. Marlin
Modified: 2016-03-12 14:59 EST (History)
7 users (show)

See Also:
Fixed In Version: sipp-3.5.0-3.fc23 sipp-3.5.0-3.fc22 sipp-3.5.0-3.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1300543
Environment:
Last Closed: 2016-03-03 15:25:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description D. Marlin 2016-02-10 12:01:34 EST
+++ This bug was initially created as a clone of Bug #1300543 +++

Attempting to build sipp-3.4.1-1 from epel7 on RHELSA failed:

g++   -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches    -Wl,-z,relro  -o sipp src/sipp-actions.o src/sipp-auth.o src/sipp-comp.o src/sipp-call.o src/sipp-deadcall.o src/sipp-infile.o src/sipp-listener.o src/sipp-logger.o src/sipp-md5.o src/sipp-message.o src/sipp-milenage.o src/sipp-call_generation_task.o src/sipp-reporttask.o src/sipp-rijndael.o src/sipp-scenario.o src/sipp-sip_parser.o src/sipp-screen.o src/sipp-socket.o src/sipp-socketowner.o src/sipp-stat.o src/sipp-strings.o src/sipp-task.o src/sipp-time.o src/sipp-variables.o src/sipp-watchdog.o src/sipp-xp_parser.o src/sipp-sslinit.o src/sipp-sslthreadsafe.o  src/sipp-prepare_pcap.o src/sipp-send_packets.o src/sipp-rtpstream.o src/sipp-sipp.o  -lpcap -lsctp -lcrypto -lssl -lm -lpthread -ldl -lcurses
src/sipp-send_packets.o: In function `send_packets':
/builddir/build/BUILD/sipp-3.4.1/src/send_packets.c:147:(.text+0x370): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against symbol `media_ip_is_ipv6' defined in .bss section in src/sipp-sipp.o
/builddir/build/BUILD/sipp-3.4.1/src/send_packets.c:182:(.text+0x3f0): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against symbol `media_ip_is_ipv6' defined in .bss section in src/sipp-sipp.o
/builddir/build/BUILD/sipp-3.4.1/src/send_packets.c:224:(.text+0x4d8): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against symbol `media_ip_is_ipv6' defined in .bss section in src/sipp-sipp.o
/builddir/build/BUILD/sipp-3.4.1/src/send_packets.c:198:(.text+0x53c): relocation truncated to fit: R_AARCH64_LDST32_ABS_LO12_NC against symbol `media_ip_is_ipv6' defined in .bss section in src/sipp-sipp.o
collect2: error: ld returned 1 exit status
make: *** [sipp] Error 1 

Google seems to imply that this comes from a mismatch of types, which there indeed is:

include/sipp.hpp:extern bool               media_ip_is_ipv6;
src/send_packets.c:extern int media_ip_is_ipv6;

Nonetheless, the same version successfully built on Fedora and EPEL x86_64 as well as Fedora aarch64:

http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=8720

Therefore this would appear to be an issue with binutils.

--- Additional comment from Nick Clifton on 2016-01-29 06:32:37 EST ---

The new 7.3 binutils is based upon the F23 binutils, so changing this BZ to MODIFIED so that QE can test/verify.

--- Additional comment from D. Marlin on 2016-02-04 21:06:29 EST ---

I tried building sipp using binutils-2.25.1-1.el7, but I get the same errors as before.  Do I need to try a different (or later) version?

--- Additional comment from Nick Clifton on 2016-02-08 08:14:40 EST ---

Hi Guys,

  I am reverting this BZ to assigned, since upgrading the binutils sources does not fix the problem.

  I have started an email thread about the problem on the binutils mailing list:

https://www.sourceware.org/ml/binutils/2016-02/msg00119.html

  Essentially it boils down to a test case like this:

file1.c:  extern int foo; int a (void) { return foo; }
file2.c:  char bar, foo, baz;

  When the function a() in file1,c tries to access the variable foo, it uses a 32-bit wide, 32-bit aligned access.  This fails because foo is actually 8-bits wide and 8-bit aligned, and, as it happens, not placed on a 32-bit aligned boundary.

  So the linker is correct in refusing the link the program, but it certainly could produce a more helpful error message.  I have created a patch to do this, which can be found in the email thread above.  If it proves to be acceptable I will backport it to the RHEL sources.

  The reason that this problem arises on the AArch64 architecture and not on other architectures is that the AArch64 has stricter alignment requirements on its load and store instructions.  In particular a 32-bit access will not encode the bottom two bits of the address to be accessed, so the address *must* be on a 32-bit boundary.  Other architectures may end up with slower accesses, or a run-time failure, but not a link time failure.

--- Additional comment from D. Marlin on 2016-02-08 18:10:48 EST ---

Since the same version of sipp builds for F23, 

  http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=327954

I tried another build in RHELSA using the F23 version of binutils (binaries straight from koji, without rebuilding it for RHELSA):

  http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=318616

but I still get the same error as before, so I'm trying to determine why it successfully builds for AArch64 on F23, and fails on RHELSA-7.2.

I can reproduce this on a local build system; succeeds in F23 mock chroot, fails in RHELSA-7.2 mock chroot, even if using the F23 binutils.

Could the issue be that some of the options used (flags for the compiler or linker) differ between F23 and RHELSA, or possibly a difference in the code the compiler generates for the linker?

--- Additional comment from Nick Clifton on 2016-02-09 05:06:07 EST ---

> Could the issue be that some of the options used (flags for the compiler or
> linker) differ between F23 and RHELSA, or possibly a difference in the code
> the compiler generates for the linker?

Yes.  Also another possibility is that the *placement* of the variables into the .data or .bss sections differs between the two installations.  This matters because the linker will only detect a problem if the code tries to make an unaligned access to the variable.  In the code example in comment #3, if you remove the declaration of the bar and baz variables the code will compile and link without any problems, because foo, even though it only needs byte alignment, will just happen to be placed onto a word aligned boundary.  (The compiled code will still be incorrect however.  Function a will still be loading foo as if it were a 32-bit quantity and not an 8-bit quantity).

--- Additional comment from Nick Clifton on 2016-02-09 06:16 EST ---

This is the patch that I plan to check in to the RHEL 7.3 binutils, once they are open for new fixes.

-----------------------

Since the actual issue appears to be in the sipp sources (variable type mismatch), and not binutils (correctly refusing to link on AArch64), I am cloning this bug for sipp.

Please correct the variable type mismatch:

  include/sipp.hpp:extern bool               media_ip_is_ipv6;

  src/send_packets.c:extern int media_ip_is_ipv6;


to resolve this issue.
Comment 1 D. Marlin 2016-02-10 17:17:07 EST
This appears to have been fixed on the master branch of sipp:

commit 9f15c949a925c58852593b7e928558a80924f92c
Author: Simon Gomizelj <sgomizelj@sangoma.com>
Date:   Mon Jul 13 14:55:14 2015 -0400

    Make the media_ip_is_ipv6 types match
    
    Fixes #162. Ultimately I guess this was an aliasing issue.


Please backport this commit.
Comment 2 Fedora Update System 2016-02-13 15:26:25 EST
sipp-3.5.0-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1a52165240
Comment 3 Fedora Update System 2016-02-13 15:26:25 EST
sipp-3.5.0-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2040001ad6
Comment 4 Fedora Update System 2016-02-13 15:26:32 EST
sipp-3.5.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bcd44235b5
Comment 5 Fedora Update System 2016-02-14 22:53:02 EST
sipp-3.5.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bcd44235b5
Comment 6 Fedora Update System 2016-02-14 23:52:32 EST
sipp-3.5.0-1.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2040001ad6
Comment 7 Fedora Update System 2016-02-15 00:24:07 EST
sipp-3.5.0-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1a52165240
Comment 8 Fedora Update System 2016-02-23 07:37:39 EST
sipp-3.5.0-3.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-41ef16e778
Comment 9 Fedora Update System 2016-02-23 07:37:39 EST
sipp-3.5.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ac41e446b4
Comment 10 Fedora Update System 2016-02-23 07:37:42 EST
sipp-3.5.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ac41e446b4
Comment 11 Fedora Update System 2016-02-23 07:37:47 EST
sipp-3.5.0-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-868982b551
Comment 12 Fedora Update System 2016-02-23 16:25:33 EST
sipp-3.5.0-3.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-868982b551
Comment 13 Fedora Update System 2016-02-24 13:23:16 EST
sipp-3.5.0-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-41ef16e778
Comment 14 Fedora Update System 2016-02-24 16:51:17 EST
sipp-3.5.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ac41e446b4
Comment 15 Fedora Update System 2016-03-03 15:25:17 EST
sipp-3.5.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2016-03-03 21:18:57 EST
sipp-3.5.0-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Comment 17 Fedora Update System 2016-03-12 14:59:07 EST
sipp-3.5.0-3.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.