[yocto] [PATCH 1/1] prelink: AARCH64 support added

[Mark Hatle]

I've applied you patch to a new 'cross_prelink_aarch64' branch for testing.

A few notes:

I cleaned up some white space issues.  This might have been a result of the
mailer -- I'm not sure.

I had to change:

R_AARCH64_TLS_DTPMOD64 to R_AARCH64_TLS_DTPMOD
R_AARCH64_TLS_DTPREL64 to R_AARCH64_TLS_DTREL
R_AARCH64_TLS_TPREL64 to R_AARCH64_TLS_TPREL

>From what I can find, the names of these symbols were modified in:

https://sourceware.org/ml/libc-alpha/2014-11/msg00455.html

I found another note that the aarch64 ABI has gone through a few revisions where
the notation has come back -- but glibc has not yet re-introduced it to it's
'elf.h' file.


Now for the testing part.  Running the testsuite (make check), I'm getting a
number of failures.

I'm running the tests on a YP 2.0 based system, with two patches applied to
glibc.  The one that should fix the prelink load address issue, and the other
that should fix the ld.so interface.

The results of the 'make check' are:

============================================================================
Testsuite summary for
============================================================================
# TOTAL: 47
# PASS:  4
# SKIP:  6
# XFAIL: 0
# FAIL:  37
# XPASS: 0
# ERROR: 0

Of the fails, the 'tls*' tests cause kernel back traces on my system.
(Definitely not good.)

'ifunc' tests were skipped as as aarch64 does not have a definition in ifunc.h

The other failures can be classified as:

- unprelink failed (input and output were not identical)
- execution of the prelinked code failed

I'd suggest start working through the issues in the testsuite...

--Mark

On 10/30/15 8:34 AM, Mark Hatle wrote:
> Was the work below based on any existing work (such as arch-arm.c)?  We found a
> bug yesterday in the "arm_prelink_conflict_rela" on ARM, a previous hunk for
> handling ifuncs was missed.
> 
> See:
> http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit/?h=cross_prelink_staging&id=927979bbd115eeb8a75db3231906ef6aca4c4eb6
> 
> Also we really need to add a test case for ifunc processing to the testsuite.
> Look at testsuite/ifunc.h.
> 
> Otherwise, we're likely to experience some breakage in ifunc processing in the
> future.
> 
> Thank you for the contribution.  I'll be looking at it soon and try running it.
> 
> --Mark
>