This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Build divdi3 only for architecture that required it
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 19 Apr 2017 18:01:41 -0300
- Subject: Re: [PATCH 1/2] Build divdi3 only for architecture that required it
- Authentication-results: sourceware.org; auth=none
- References: <1489671790-7611-1-git-send-email-adhemerval.zanella@linaro.org> <mvmbmt1uxvl.fsf@hawking.suse.de> <5067790e-50b6-d2c1-4466-26d79fc23166@linaro.org> <af83ffde-83d3-d7d1-d45e-7c379b7e7123@linaro.org> <ca5b3de6-819a-1c9a-a722-a9069bf6c74f@linaro.org> <alpine.DEB.2.20.1704182118100.1253@digraph.polyomino.org.uk>
On 18/04/2017 18:21, Joseph Myers wrote:
> I think these changes caused elf/check-execstack to fail for
> sparcv9-linux-gnu.
>
> https://sourceware.org/ml/libc-testresults/2017-q2/msg00015.html (before
> the change, passes)
>
> https://sourceware.org/ml/libc-testresults/2017-q2/msg00018.html (after
> the change, shows the regression, no other changes in glibc).
>
> /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/elf/ld.so.phdr: *** executable stack signaled
>
I think the problem is with generated sparc toolchain from build-many-glibcs.py
the minimum supported sparc32 version is pre-v9 and it requires a software
implementation of '.udiv'. Since now we are using libgcc.a one instead, it
must have the '.note.GNU-stack' so linker can properly set the stack non
executable.
>From a build using a toolchain from build-many-glibcs.py:
elf/librtld.os.map
[...]
/opt/cross/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/6.2.1/32/libgcc.a(_divsi3.o)
/opt/cross/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/6.2.1/32/libgcc.a(_udivdi3.o) (.udiv)
/opt/cross/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/6.2.1/32/libgcc.a(_clz.o)
/opt/cross/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/6.2.1/32/libgcc.a(_udivdi3.o) (__clz_tab)
[...]
And dumping _udivdi3.o section headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 0002b0 00 AX 0 0 4
[ 2] .data PROGBITS 00000000 0002e4 000000 00 WA 0 0 1
[ 3] .bss NOBITS 00000000 0002e4 000000 00 WA 0 0 1
[ 4] .debug_line PROGBITS 00000000 0002e4 00010d 00 0 0 1
[ 5] .rela.debug_line RELA 00000000 0007c0 00000c 0c I 12 4 4
[ 6] .debug_info PROGBITS 00000000 0003f1 0000ab 00 0 0 1
[ 7] .rela.debug_info RELA 00000000 0007cc 000030 0c I 12 6 4
[ 8] .debug_abbrev PROGBITS 00000000 00049c 000014 00 0 0 1
[ 9] .debug_aranges PROGBITS 00000000 0004b0 000020 00 0 0 8
[10] .rela.debug_arang RELA 00000000 0007fc 000018 0c I 12 9 4
[11] .shstrtab STRTAB 00000000 000814 000070 00 0 0 1
[12] .symtab SYMTAB 00000000 0004d0 000220 10 13 32 4
[13] .strtab STRTAB 00000000 0006f0 0000cf 00 0 0 1
I am not seeing this on a native gcc build which I configured with:
' --with-arch-directory=sparc64 --enable-multiarch --enable-targets=all
--with-cpu-32=ultrasparc --with-long-double-128 --enable-multilib'
Both libgcc's __udivdi3 and __umoddi3 do not pull .udiv since for this libgcc build
both are using hardware instructions:
elf/librtld.os.map
/home/azanella/gcc/install/lib/gcc/sparc64-linux-gnu/6.3.1/32/libgcc.a(_udivdi3.o)
/home/azanella/glibc/glibc-git-build-sparcv9/elf/dl-allobjs.os (__udivdi3)
/home/azanella/gcc/install/lib/gcc/sparc64-linux-gnu/6.3.1/32/libgcc.a(_umoddi3.o)
/home/azanella/glibc/glibc-git-build-sparcv9/elf/dl-allobjs.os (__umoddi3)
Now to actually fix it I can think of two possible solutions:
1. Add divdi3 build on sparc32 as before the patch.
2. Enforce -Wl,-noexecstack on ld.so build.
I would prefer 2. since we already expect loader to have a non-executable stack
and gentoo wiki [1] all current architectures with supported gcc/binutils version
should support the linker option.
[1] https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart