[BZ,#21779] Resolve non-relocatable branch in MicroBlaze pt-vfork.S

The relative branch directly to __libc_vfork results in an relocation
that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
type relocations symbols are not resolved. Additionally due to the
branch being located in the .text section the instruction cannot be
rewritten as the section is not writable, and causes a segfault at
runtime when loading libpthread.

To resolve this issue, ensure the branch is done using PLT. This removes
the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
for a more common R_MICROBLAZE_JUMP via the PLT.

2017-07-17  Nathan Rossi  <nathan@nathanrossi.com>

        [BZ #21779]
        * sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT
---
 sysdeps/unix/sysv/linux/microblaze/pt-vfork.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 17/07/2017 09:58, Nathan Rossi wrote:
> The relative branch directly to __libc_vfork results in an relocation
> that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
> is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
> type relocations symbols are not resolved. Additionally due to the
> branch being located in the .text section the instruction cannot be
> rewritten as the section is not writable, and causes a segfault at
> runtime when loading libpthread.
> 
> To resolve this issue, ensure the branch is done using PLT. This removes
> the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
> for a more common R_MICROBLAZE_JUMP via the PLT.
> 
> 2017-07-17  Nathan Rossi  <nathan@nathanrossi.com>
> 
>         [BZ #21779]
>         * sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT

LGTM, cross make clean shows no regression.  Since you seem to have access
to a microblaze ystem, it would be useful if you have time to run the
complete make check so we can update the 2.26 release wike [1].

[1] https://sourceware.org/glibc/wiki/Release/2.26

> ---
>  sysdeps/unix/sysv/linux/microblaze/pt-vfork.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> index f201f0429f..d8339f21f7 100644
> --- a/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> +++ b/sysdeps/unix/sysv/linux/microblaze/pt-vfork.S
> @@ -34,7 +34,7 @@
>         || SHLIB_COMPAT (libpthread, GLIBC_2_1_2, GLIBC_2_20))
>  
>  ENTRY (vfork_compat)
> -	bri	__libc_vfork
> +	bri	__libc_vfork@PLT
>  END (vfork_compat)
>  
>  #endif
>

On 18 July 2017 at 04:42, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
> On 17/07/2017 09:58, Nathan Rossi wrote:
>> The relative branch directly to __libc_vfork results in an relocation
>> that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
>> is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
>> type relocations symbols are not resolved. Additionally due to the
>> branch being located in the .text section the instruction cannot be
>> rewritten as the section is not writable, and causes a segfault at
>> runtime when loading libpthread.
>>
>> To resolve this issue, ensure the branch is done using PLT. This removes
>> the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
>> for a more common R_MICROBLAZE_JUMP via the PLT.
>>
>> 2017-07-17  Nathan Rossi  <nathan@nathanrossi.com>
>>
>>         [BZ #21779]
>>         * sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT
>
> LGTM, cross make clean shows no regression.  Since you seem to have access
> to a microblaze ystem, it would be useful if you have time to run the
> complete make check so we can update the 2.26 release wike [1].
>
> [1] https://sourceware.org/glibc/wiki/Release/2.26

Sorry for taking to so long to reply, took me a little while to setup
and get the testsuite running.

The following results are run against glibc 1740441b49, but also
include this patch and a patch to update the libm-test-ulps (otherwise
all the math/ tests fail with precision mismatch).

Just a note, 40 of the tests are failing due to time out. I am in the
process of running with a longer time out factor.

Regards,
Nathan

Build system: GCC 7.1.0, binutils 2.28-20170627, Linux 4.12 (LE soft-float)

FAIL: crypt/sha256c-test
FAIL: crypt/sha512c-test
FAIL: debug/tst-backtrace2
FAIL: debug/tst-backtrace3
FAIL: debug/tst-backtrace4
FAIL: debug/tst-backtrace5
FAIL: debug/tst-backtrace6
FAIL: debug/tst-chk2
FAIL: debug/tst-chk3
UNSUPPORTED: debug/tst-chk4
UNSUPPORTED: debug/tst-chk5
UNSUPPORTED: debug/tst-chk6
FAIL: debug/tst-lfschk2
FAIL: debug/tst-lfschk3
UNSUPPORTED: debug/tst-lfschk4
UNSUPPORTED: debug/tst-lfschk5
UNSUPPORTED: debug/tst-lfschk6
FAIL: debug/tst-longjmp_chk
UNSUPPORTED: dlfcn/bug-atexit3
FAIL: dlfcn/tststatic
FAIL: dlfcn/tststatic2
FAIL: dlfcn/tststatic3
FAIL: dlfcn/tststatic4
FAIL: dlfcn/tststatic5
FAIL: elf/check-execstack
FAIL: elf/circleload1
FAIL: elf/constload1
FAIL: elf/dblload
FAIL: elf/dblunload
FAIL: elf/lateglobal
FAIL: elf/nodelete2
FAIL: elf/order-cmp
FAIL: elf/order2-cmp
FAIL: elf/reldep6
FAIL: elf/resolvfail
FAIL: elf/tst-addr1
FAIL: elf/tst-align2
FAIL: elf/tst-array1-cmp
FAIL: elf/tst-array1-static
FAIL: elf/tst-array1-static-cmp
FAIL: elf/tst-array2-cmp
FAIL: elf/tst-array3-cmp
FAIL: elf/tst-array4-cmp
FAIL: elf/tst-array5-static
FAIL: elf/tst-array5-static-cmp
FAIL: elf/tst-audit1
FAIL: elf/tst-audit11
FAIL: elf/tst-audit12
FAIL: elf/tst-audit2
FAIL: elf/tst-audit8
FAIL: elf/tst-audit9
FAIL: elf/tst-dl-iter-static
FAIL: elf/tst-env-setuid
FAIL: elf/tst-env-setuid-tunables
FAIL: elf/tst-global1
FAIL: elf/tst-initorder-cmp
FAIL: elf/tst-initorder2-cmp
FAIL: elf/tst-latepthread
FAIL: elf/tst-ldconfig-X
FAIL: elf/tst-leaks1-mem
FAIL: elf/tst-leaks1-static
FAIL: elf/tst-leaks1-static-mem
FAIL: elf/tst-linkall-static
FAIL: elf/tst-ptrguard1-static
FAIL: elf/tst-stackguard1-static
FAIL: elf/tst-tls1
FAIL: elf/tst-tls1-static
FAIL: elf/tst-tls10
FAIL: elf/tst-tls13
FAIL: elf/tst-tls14
FAIL: elf/tst-tls2
FAIL: elf/tst-tls2-static
FAIL: elf/tst-tls3
FAIL: elf/tst-tls9-static
FAIL: elf/tst-tlsalign
FAIL: elf/tst-tlsalign-extern-static
FAIL: elf/tst-tlsalign-static
FAIL: iconvdata/iconv-test
FAIL: iconvdata/mtrace-tst-loading
FAIL: iconvdata/tst-loading
FAIL: iconvdata/tst-tables
FAIL: libio/tst-fopenloc
FAIL: libio/tst-fopenloc-cmp
FAIL: libio/tst-fopenloc-mem
FAIL: libio/tst-widetext
FAIL: localedata/bug-setlocale1-static
FAIL: localedata/mtrace-tst-leaks
FAIL: localedata/tst-fmon
FAIL: localedata/tst-langinfo-static
FAIL: localedata/tst-leaks
FAIL: malloc/tst-dynarray
FAIL: malloc/tst-dynarray-fail
FAIL: malloc/tst-dynarray-fail-mem
FAIL: malloc/tst-dynarray-mem
FAIL: malloc/tst-malloc-thread-fail
FAIL: malloc/tst-malloc-usable-static
FAIL: malloc/tst-malloc-usable-static-tunables
FAIL: malloc/tst-mallocfork2
FAIL: math/test-fpucw-ieee-static
FAIL: math/test-fpucw-static
FAIL: math/test-signgam-uchar-init-static
FAIL: math/test-signgam-uchar-static
FAIL: math/test-signgam-uint-init-static
FAIL: math/test-signgam-uint-static
FAIL: math/test-signgam-ullong-init-static
FAIL: math/test-signgam-ullong-static
FAIL: misc/test-errno-linux
FAIL: misc/tst-atomic
FAIL: misc/tst-atomic-long
FAIL: misc/tst-empty
FAIL: misc/tst-error1
FAIL: misc/tst-tsearch
FAIL: nptl/test-cond-printers
FAIL: nptl/test-condattr-printers
FAIL: nptl/test-mutex-printers
FAIL: nptl/test-mutexattr-printers
FAIL: nptl/test-rwlock-printers
FAIL: nptl/test-rwlockattr-printers
FAIL: nptl/tst-cancel17
FAIL: nptl/tst-cancel20
FAIL: nptl/tst-cancel21
FAIL: nptl/tst-cancel21-static
UNSUPPORTED: nptl/tst-cancel24
UNSUPPORTED: nptl/tst-cancel24-static
FAIL: nptl/tst-cancel7
FAIL: nptl/tst-cancelx16
FAIL: nptl/tst-cancelx17
FAIL: nptl/tst-cancelx18
FAIL: nptl/tst-cancelx20
FAIL: nptl/tst-cancelx21
FAIL: nptl/tst-cancelx4
FAIL: nptl/tst-cancelx5
FAIL: nptl/tst-cancelx7
FAIL: nptl/tst-cleanup0-cmp
FAIL: nptl/tst-cond24
FAIL: nptl/tst-cond25
FAIL: nptl/tst-cond8-static
FAIL: nptl/tst-create-detached
FAIL: nptl/tst-execstack
FAIL: nptl/tst-fini1
FAIL: nptl/tst-locale1
FAIL: nptl/tst-locale2
FAIL: nptl/tst-mutex8-static
FAIL: nptl/tst-mutexpi8-static
UNSUPPORTED: nptl/tst-once5
FAIL: nptl/tst-oncex4
FAIL: nptl/tst-pthread-getattr
FAIL: nptl/tst-robust-fork
FAIL: nptl/tst-sem11-static
FAIL: nptl/tst-sem12-static
FAIL: nptl/tst-signal6
FAIL: nptl/tst-stack4
FAIL: nptl/tst-stackguard1
FAIL: nptl/tst-stackguard1-static
UNSUPPORTED: nptl/tst-thread_local1
FAIL: nptl/tst-tls2
FAIL: nptl/tst-vfork1
FAIL: nptl/tst-vfork2
FAIL: nss/bug17079
FAIL: nss/tst-field
FAIL: posix/bug-regex24
FAIL: posix/globtest
FAIL: posix/tst-exec-static
FAIL: posix/tst-fnmatch
FAIL: posix/tst-fnmatch-mem
FAIL: posix/tst-regex
FAIL: posix/tst-regex2
FAIL: posix/tst-spawn-static
UNSUPPORTED: posix/tst-sysconf-empty-chroot
FAIL: posix/wordexp-tst
FAIL: resolv/mtrace-tst-resolv-res_ninit
FAIL: resolv/tst-bug18665
FAIL: resolv/tst-resolv-basic
FAIL: resolv/tst-resolv-edns
FAIL: resolv/tst-resolv-res_init
FAIL: resolv/tst-resolv-res_init-thread
FAIL: resolv/tst-resolv-res_ninit
FAIL: resolv/tst-resolv-search
FAIL: resolv/tst-resolv-threads
FAIL: rt/tst-mqueue8x
FAIL: setjmp/tst-setjmp-static
FAIL: stdio-common/bug22
FAIL: stdio-common/test-vfprintf
FAIL: stdio-common/tst-setvbuf1-cmp
FAIL: stdio-common/tst-sprintf
FAIL: stdio-common/tst-unbputc
FAIL: stdlib/test-canon
FAIL: stdlib/tst-fmtmsg
UNSUPPORTED: stdlib/tst-quick_exit
FAIL: stdlib/tst-secure-getenv
FAIL: stdlib/tst-setcontext2
UNSUPPORTED: stdlib/tst-setcontext3
UNSUPPORTED: stdlib/tst-thread-quick_exit
FAIL: string/test-strcasecmp
FAIL: string/test-strncasecmp
FAIL: string/tst-cmp
FAIL: string/tst-xbzero-opt
FAIL: sunrpc/bug20790
FAIL: timezone/tst-tzset
Summary of test results:
    184 FAIL
   3098 PASS
     15 UNSUPPORTED
     30 XFAIL

On Mon, 17 Jul 2017, Adhemerval Zanella wrote:

> On 17/07/2017 09:58, Nathan Rossi wrote:
> > The relative branch directly to __libc_vfork results in an relocation
> > that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
> > is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
> > type relocations symbols are not resolved. Additionally due to the
> > branch being located in the .text section the instruction cannot be
> > rewritten as the section is not writable, and causes a segfault at
> > runtime when loading libpthread.
> > 
> > To resolve this issue, ensure the branch is done using PLT. This removes
> > the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
> > for a more common R_MICROBLAZE_JUMP via the PLT.
> > 
> > 2017-07-17  Nathan Rossi  <nathan@nathanrossi.com>
> > 
> >         [BZ #21779]
> >         * sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT
> 
> LGTM, cross make clean shows no regression.  Since you seem to have access
> to a microblaze ystem, it would be useful if you have time to run the
> complete make check so we can update the 2.26 release wike [1].

It looks like neither this nor the ulps update has been committed?

On 28/07/2017 09:02, Joseph Myers wrote:
> On Mon, 17 Jul 2017, Adhemerval Zanella wrote:
> 
>> On 17/07/2017 09:58, Nathan Rossi wrote:
>>> The relative branch directly to __libc_vfork results in an relocation
>>> that cannot be resolved. Specifically a R_MICROBLAZE_64_PCREL relocation
>>> is created for this branch, however for MicroBlaze R_MICROBLAZE_64_PCREL
>>> type relocations symbols are not resolved. Additionally due to the
>>> branch being located in the .text section the instruction cannot be
>>> rewritten as the section is not writable, and causes a segfault at
>>> runtime when loading libpthread.
>>>
>>> To resolve this issue, ensure the branch is done using PLT. This removes
>>> the need to modify the instruction and trades the R_MICROBLAZE_64_PCREL
>>> for a more common R_MICROBLAZE_JUMP via the PLT.
>>>
>>> 2017-07-17  Nathan Rossi  <nathan@nathanrossi.com>
>>>
>>>         [BZ #21779]
>>>         * sysdeps/unix/sysv/linux/microblaze/pt-vfork.S: Branch using PLT
>>
>> LGTM, cross make clean shows no regression.  Since you seem to have access
>> to a microblaze ystem, it would be useful if you have time to run the
>> complete make check so we can update the 2.26 release wike [1].
> 
> It looks like neither this nor the ulps update has been committed?
> 

I will take care of these.