Re: Flurry of GMP check failures

There are a few cycles lost for each call to PIC code and a few cycles lost for each read/write of a PIC variable. Currently, we pay these costs also for calls/variables *within* GMP. The symbol hiding stuff will help, but only for calls, while variable access still needs extra code (although not

Re: Flurry of GMP check failures

t...@gmplib.org (Torbjörn Granlund) writes: > But this is odd: At least Debian (didn't have a chance to check Gentoo > yet) does not ban R_X86_64_64 which we use frequently from GMP's > assembly for references to tables of constants. It bans R_X86_64_32S > which we use for tables of function

Re: Flurry of GMP check failures

I have not read carefully follow-ups on this yet, but here are some observations. Gentoo "hardened" behaves similarly wrt my sym.c/m.c example. Note that gcc's defaults for compiling and linking do not affect things much here, except that PIC code adds overhead. I am not suggesting that we

Re: Flurry of GMP check failures

On Sat, 5 Nov 2016, Niels Möller wrote: Marc Glisse writes: Uh? I have 2 very natural use cases for libgmp.a: 1) to build a static (or at least with few dependencies) executable that I am going to send to someone else [...] 2) I am rebuilding GMP on my specific

Re: Flurry of GMP check failures

Marc Glisse writes: > Uh? I have 2 very natural use cases for libgmp.a: > > 1) to build a static (or at least with few dependencies) executable > that I am going to send to someone else [...] > 2) I am rebuilding GMP on my specific platform in order to get the > best

Re: Flurry of GMP check failures

On Sat, 5 Nov 2016, Niels Möller wrote: At this point in time, I think use-cases involving static libgmp.a (or libnettle.a) are somewhat obscure. Uh? I have 2 very natural use cases for libgmp.a: 1) to build a static (or at least with few dependencies) executable that I am going to send to

Re: Flurry of GMP check failures

t...@gmplib.org (Torbjörn Granlund) writes: > This fails: > $ gcc sym.c -c -fno-pic && gcc sym.o m.c I guess we never need to pass -fno-pic to gcc, we should either pass -fpic, when building shared library, or no pic-reaetd flags at all, when building static libraries and executables. Right?

Re: Flurry of GMP check failures

ni...@lysator.liu.se (Niels Möller) writes: t...@gmplib.org (Torbjörn Granlund) writes: > 2. Something is broken wrt Debian sid from the past few weeks. >It seems they want static lib code to be PIC. Or rather, PIC code for all executables, to enable randomization of the

Re: Flurry of GMP check failures

t...@gmplib.org (Torbjörn Granlund) writes: > 2. Something is broken wrt Debian sid from the past few weeks. >It seems they want static lib code to be PIC. Or rather, PIC code for all executables, to enable randomization of the mapping of the text segment into the process address space. I

Flurry of GMP check failures

There are two reasons for the current build/check failure situation (see https://gmplib.org/devel/tm/gmp/date.html). 1. We added testing of mini-gmp. 2. Something is broken wrt Debian sid from the past few weeks. It seems they want static lib code to be PIC. -- Torbjörn Please encrypt, key