i686 with -fPIE and -fstack-protector-all

i686 with -fPIE and -fstack-protector-all

[Anthony G. Basile]

Hi,

I've hit a bug with 1.0.0 on i686.  When building with 
-fstack-protector-all and -fPIE, I get an undefined reference to 
`__stack_chk_fail_local'.  I do not get this on x86_64:

i686:

i686-musl-vanilla ~ # gcc -fstack-protector-all -fPIE -o test test.c
/tmp/ccmdheAK.o: In function `main':
test.c:(.text+0x28): undefined reference to `__stack_chk_fail_local'
/usr/lib/gcc/i686-gentoo-linux-musl/4.7.3/../../../../i686-gentoo-linux-musl/bin/ld: 
test: hidden symbol `__stack_chk_fail_local' isn't defined
/usr/lib/gcc/i686-gentoo-linux-musl/4.7.3/../../../../i686-gentoo-linux-musl/bin/ld: 
final link failed: Bad value
collect2: error: ld returned 1 exit status

i686-musl-vanilla ~ # gcc -fstack-protector-all -o test test.c

i686-musl-vanilla ~ # gcc -fPIE -o test test.c


By contrast for amd64:

amd64-musl-vanilla ~ # echo "int main() { ; return 0 ; }" > test.c
amd64-musl-vanilla ~ # gcc -fstack-protector-all -fPIE -o test test.c
amd64-musl-vanilla ~ # gcc -fstack-protector-all -o test test.c
amd64-musl-vanilla ~ # gcc -fPIE -o test test.c


Doing a compile without link and checking the symbols confirms the problem:

i686-musl-vanilla ~ # gcc -fstack-protector-all -fPIE  -c test.c
i686-musl-vanilla ~ # readelf -sW test.o | grep stack
9: 00000000     0 NOTYPE  GLOBAL HIDDEN   UND __stack_chk_fail_local

amd64-musl-vanilla ~ # gcc -fstack-protector-all -fPIE  -c test.c
amd64-musl-vanilla ~ # readelf -sW test.o | grep stack
10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND __stack_chk_fail


This is obviously how the compiler spits things out and we have the 
exact same symbols (__stack_chk_fail on amd64 and __stack_chk_fail_local 
on i686) irrespective of the c library.

Where is __stack_chk_fail_local resolved?

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: i686 with -fPIE and -fstack-protector-all

[Szabolcs Nagy]

* Anthony G. Basile <basile@opensource.dyc.edu> [2014-03-22 08:53:07 -0400]:
> I've hit a bug with 1.0.0 on i686.  When building with
> -fstack-protector-all and -fPIE, I get an undefined reference to
> `__stack_chk_fail_local'.  I do not get this on x86_64:
> 

may be this gcc bug should be in the faq

http://gcc.gnu.org/ml/gcc/2012-01/msg00012.html
http://git.alpinelinux.org/cgit/aports/tree/main/musl/__stack_chk_fail_local.c

Re: i686 with -fPIE and -fstack-protector-all

[Anthony G. Basile]

On 03/22/2014 09:06 AM, Szabolcs Nagy wrote:
> * Anthony G. Basile <basile@opensource.dyc.edu> [2014-03-22 08:53:07 -0400]:
>> I've hit a bug with 1.0.0 on i686.  When building with
>> -fstack-protector-all and -fPIE, I get an undefined reference to
>> `__stack_chk_fail_local'.  I do not get this on x86_64:
>>
>
> may be this gcc bug should be in the faq
>
> http://gcc.gnu.org/ml/gcc/2012-01/msg00012.html
> http://git.alpinelinux.org/cgit/aports/tree/main/musl/__stack_chk_fail_local.c
>

Thanks it.  I was going to adopt a patch like alpines but hesitated in 
csae I was missing something.

Aside: it looks like alpine is hitting a lot of the same issues i am 
with gentoo+musl and adopting similar approaches, like getent and ldconfig.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: i686 with -fPIE and -fstack-protector-all

[Rich Felker]

On Sat, Mar 22, 2014 at 09:33:48AM -0400, Anthony G. Basile wrote:
> On 03/22/2014 09:06 AM, Szabolcs Nagy wrote:
> >* Anthony G. Basile <basile@opensource.dyc.edu> [2014-03-22 08:53:07 -0400]:
> >>I've hit a bug with 1.0.0 on i686.  When building with
> >>-fstack-protector-all and -fPIE, I get an undefined reference to
> >>`__stack_chk_fail_local'.  I do not get this on x86_64:
> >>
> >
> >may be this gcc bug should be in the faq
> >
> >http://gcc.gnu.org/ml/gcc/2012-01/msg00012.html
> >http://git.alpinelinux.org/cgit/aports/tree/main/musl/__stack_chk_fail_local.c
> >
> 
> Thanks it.  I was going to adopt a patch like alpines but hesitated
> in csae I was missing something.
> 
> Aside: it looks like alpine is hitting a lot of the same issues i am
> with gentoo+musl and adopting similar approaches, like getent and
> ldconfig.

Can ldconfig just be an empty script? Or does it need to make plain
.so symlinks to all the .so.X.Y.Z files so that ld can find them? I'm
not clear on whether most packages (e.g. libtool based) do the symlink
themselves or expect ldconfig to do so. It doesn't affect runtime
usage but it does affect linking programs against the library.

If we can figure out all this stuff, it would be great if someone
could make a clean git repo of replacements for all of the glibc
binaries that one could use with musl. Do you (or anyone else) have a
list of programs we'd need to make dists happy?

Rich

Re: i686 with -fPIE and -fstack-protector-all

[Anthony G. Basile]

On 03/22/2014 01:42 PM, Rich Felker wrote:
> On Sat, Mar 22, 2014 at 09:33:48AM -0400, Anthony G. Basile wrote:
>> On 03/22/2014 09:06 AM, Szabolcs Nagy wrote:
>>> * Anthony G. Basile <basile@opensource.dyc.edu> [2014-03-22 08:53:07 -0400]:
>>>> I've hit a bug with 1.0.0 on i686.  When building with
>>>> -fstack-protector-all and -fPIE, I get an undefined reference to
>>>> `__stack_chk_fail_local'.  I do not get this on x86_64:
>>>>
>>>
>>> may be this gcc bug should be in the faq
>>>
>>> http://gcc.gnu.org/ml/gcc/2012-01/msg00012.html
>>> http://git.alpinelinux.org/cgit/aports/tree/main/musl/__stack_chk_fail_local.c
>>>
>>
>> Thanks it.  I was going to adopt a patch like alpines but hesitated
>> in csae I was missing something.
>>
>> Aside: it looks like alpine is hitting a lot of the same issues i am
>> with gentoo+musl and adopting similar approaches, like getent and
>> ldconfig.
>
> Can ldconfig just be an empty script? Or does it need to make plain
> .so symlinks to all the .so.X.Y.Z files so that ld can find them? I'm
> not clear on whether most packages (e.g. libtool based) do the symlink
> themselves or expect ldconfig to do so. It doesn't affect runtime
> usage but it does affect linking programs against the library.

There is at least one package, I can't remember which, that does depend 
on ldconfig's output to do the symlinking.  I'm sure others are in the 
same boat.

>
> If we can figure out all this stuff, it would be great if someone
> could make a clean git repo of replacements for all of the glibc
> binaries that one could use with musl. Do you (or anyone else) have a
> list of programs we'd need to make dists happy?
>
> Rich
>

I'm not sure what you mean here, but what I've been doing is building up 
a git repo of ebuilds with patches aginst various packages to make them 
compile against musl, like sabotage or alpine does.


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197