Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 26 May 2020 23:41:28 +0200 zo...@gentoo.org wrote: > tisdag 26 maj 2020 kl. 19:54:51 CEST skrev Alexis Ballier: > > On Tue, 26 May 2020 10:45:39 -0400 > > > > Mike Gilbert wrote: > > > > Note that having the 'pic' useflag should be considered > > > > something to be fixed: rewrite the asm in a PIC way. But these > > > > days nobody has the will to do it since this is mostly an issue > > > > on x86+pax, both being slowly decreasing. > > > > > > Given that PaX has been stripped out of official Gentoo kernels > > > due to the grsecurity licensing issue, I wonder if there is any > > > other good reason to keep the "pic" USE flag today. Surely this > > > affects a very small population of users. > > > > Yeah that was my thought when I saw pax/grsec beginning to be more > > hostile to open source. That's not my call but the hardened team's, > > however I'm all for removing these workarounds entirely if there's > > no point in having them anymore. > Is not only PaX/Grsec that don't allow textrel. SELinux do it to and > that is manline kernel. k so that means there's no dropping the pic useflag then i guess
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 2020-05-26 at 14:14 -0400, Mike Gilbert wrote: [...] > > > > > Assuming that the pic performance penalty is really only relevant > > on > > legacy arches (like x86), here are a couple of options: > > > > 1. Disable pic on arches where tie performance penalty is small. > > 2. Force pic everywhere, performance be damned. > > Option 1 should say "Disable pic on arches where the performance > penalty is large." Performance penalty is not really a matter of arch. Of course -fPIC from C/C++ code has a small performance impact on x86 (bigger than on amd64), but the gain is worth it. Here it is a matter of hand written assembly that is not relocatable. The performance impact thus depends on the gain of said assembly, which in the case of multimedia apps/libs is huge because that's usually about vectorizing inner loops bodys (somewhere between x4 or x8 speedups is not unusual for the part in question). That's why the policy has always been to have PIC everywhere with exceptions/workarounds tied to the pic useflag, giving users and profiles the choice. Again, the real fix is to rewrite the assembly in a PIC way, or at least have ifdefs to allow it, but that is hard. Packages that have the option to have PIC or slightly faster non-PIC assembly do/should not have a pic useflag and always use the PIC variant.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
tisdag 26 maj 2020 kl. 19:54:51 CEST skrev Alexis Ballier: > On Tue, 26 May 2020 10:45:39 -0400 > > Mike Gilbert wrote: > > > Note that having the 'pic' useflag should be considered something > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > has the will to do it since this is mostly an issue on x86+pax, > > > both being slowly decreasing. > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > the grsecurity licensing issue, I wonder if there is any other good > > reason to keep the "pic" USE flag today. Surely this affects a very > > small population of users. > > Yeah that was my thought when I saw pax/grsec beginning to be more > hostile to open source. That's not my call but the hardened team's, > however I'm all for removing these workarounds entirely if there's no > point in having them anymore. Is not only PaX/Grsec that don't allow textrel. SELinux do it to and that is manline kernel.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 2:13 PM Mike Gilbert wrote: > > On Tue, May 26, 2020 at 2:03 PM Alexis Ballier wrote: > > > > On Tue, 26 May 2020 10:45:39 -0400 > > Mike Gilbert wrote: > > > > Note that having the 'pic' useflag should be considered something > > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > > has the will to do it since this is mostly an issue on x86+pax, > > > > both being slowly decreasing. > > > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > > the grsecurity licensing issue, I wonder if there is any other good > > > reason to keep the "pic" USE flag today. Surely this affects a very > > > small population of users. > > > > > > I couldn't find any recent reference, but PIC shared libs used to be a > > QA policy. There's mainly two reasons to it: First is W^X enforcement; > > non PIC shared libs are refused by the x86_64 linker so a non-issue > > there, on x86 you need pax to emulate it because the mmu doesn't support > > the X part; I don't know about other arches. > > Then there is the small memory waste done because those libs will be > > loaded COW and thus their "code" is not shared anymore between > > processes. And the small startup performance hit to > > perform the relocations. > > > > The latter part affects everyone, and the rule of thumb for having a > > pic useflag (instead of always pic) is that the gain for non-pic asm is > > better than the loss of non-pic shared libs. This is subjective but > > usually a no-brainer for multimedia packages. > > Assuming that the pic performance penalty is really only relevant on > legacy arches (like x86), here are a couple of options: > > 1. Disable pic on arches where tie performance penalty is small. > 2. Force pic everywhere, performance be damned. Option 1 should say "Disable pic on arches where the performance penalty is large."
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 2:03 PM Alexis Ballier wrote: > > On Tue, 26 May 2020 10:45:39 -0400 > Mike Gilbert wrote: > > > Note that having the 'pic' useflag should be considered something > > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > > has the will to do it since this is mostly an issue on x86+pax, > > > both being slowly decreasing. > > > > Given that PaX has been stripped out of official Gentoo kernels due to > > the grsecurity licensing issue, I wonder if there is any other good > > reason to keep the "pic" USE flag today. Surely this affects a very > > small population of users. > > > I couldn't find any recent reference, but PIC shared libs used to be a > QA policy. There's mainly two reasons to it: First is W^X enforcement; > non PIC shared libs are refused by the x86_64 linker so a non-issue > there, on x86 you need pax to emulate it because the mmu doesn't support > the X part; I don't know about other arches. > Then there is the small memory waste done because those libs will be > loaded COW and thus their "code" is not shared anymore between > processes. And the small startup performance hit to > perform the relocations. > > The latter part affects everyone, and the rule of thumb for having a > pic useflag (instead of always pic) is that the gain for non-pic asm is > better than the loss of non-pic shared libs. This is subjective but > usually a no-brainer for multimedia packages. Assuming that the pic performance penalty is really only relevant on legacy arches (like x86), here are a couple of options: 1. Disable pic on arches where tie performance penalty is small. 2. Force pic everywhere, performance be damned.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 26 May 2020 10:45:39 -0400 Mike Gilbert wrote: > > Note that having the 'pic' useflag should be considered something > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > has the will to do it since this is mostly an issue on x86+pax, > > both being slowly decreasing. > > Given that PaX has been stripped out of official Gentoo kernels due to > the grsecurity licensing issue, I wonder if there is any other good > reason to keep the "pic" USE flag today. Surely this affects a very > small population of users. I couldn't find any recent reference, but PIC shared libs used to be a QA policy. There's mainly two reasons to it: First is W^X enforcement; non PIC shared libs are refused by the x86_64 linker so a non-issue there, on x86 you need pax to emulate it because the mmu doesn't support the X part; I don't know about other arches. Then there is the small memory waste done because those libs will be loaded COW and thus their "code" is not shared anymore between processes. And the small startup performance hit to perform the relocations. The latter part affects everyone, and the rule of thumb for having a pic useflag (instead of always pic) is that the gain for non-pic asm is better than the loss of non-pic shared libs. This is subjective but usually a no-brainer for multimedia packages. This is probably something to bring up to QA too.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, 26 May 2020 10:45:39 -0400 Mike Gilbert wrote: > > Note that having the 'pic' useflag should be considered something > > to be fixed: rewrite the asm in a PIC way. But these days nobody > > has the will to do it since this is mostly an issue on x86+pax, > > both being slowly decreasing. > > Given that PaX has been stripped out of official Gentoo kernels due to > the grsecurity licensing issue, I wonder if there is any other good > reason to keep the "pic" USE flag today. Surely this affects a very > small population of users. > Yeah that was my thought when I saw pax/grsec beginning to be more hostile to open source. That's not my call but the hardened team's, however I'm all for removing these workarounds entirely if there's no point in having them anymore.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Tue, May 26, 2020 at 5:30 AM Alexis Ballier wrote: > On Mon, 2020-05-25 at 21:09 -0400, Mike Gilbert wrote: > > If I understand you correctly, we should just drop the USE="pic" > > logic > > from the remaining packages that have it? Or are you trying to say > > something else? > > > Drop USE=asm unless there's a real reason to it: Such a useflag is, > IMHO, at the same level of a useflag on dev-lang/python that would > toggle dict's underlying implementations but not the semantics of the > language. > Have USE=pic for its historical meaning, aka, sacrificing everything to > have PIC shared libs because your system enforces this (pax). Thanks, this last sentence gives me a better understanding of why this "pic" USE flag exists at all. > Note that having the 'pic' useflag should be considered something to be > fixed: rewrite the asm in a PIC way. But these days nobody has the will > to do it since this is mostly an issue on x86+pax, both being slowly > decreasing. Given that PaX has been stripped out of official Gentoo kernels due to the grsecurity licensing issue, I wonder if there is any other good reason to keep the "pic" USE flag today. Surely this affects a very small population of users.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
[...] > > If I understand you correctly, we should just drop the USE="pic" > > logic > > from the remaining packages that have it? Or are you trying to say > > something else? > [...] > Note that having the 'pic' useflag should be considered something to > be > fixed: rewrite the asm in a PIC way. But these days nobody has the > will > to do it since this is mostly an issue on x86+pax, both being slowly > decreasing. As a side note on this: if USE=-pic has no textrel then obviously the useflag should be removed. This can happen over time if we don't pay enough attention.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 21:09 -0400, Mike Gilbert wrote: > On Mon, May 25, 2020 at 7:35 PM Alexis Ballier > wrote: > > On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > > > On Mon, May 25, 2020 at 3:18 PM Michał Górny > > > wrote: > > > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > > > On Mon, 25 May 2020 11:26:26 -0400 > > > > > Mike Gilbert wrote: > > > > > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > > > aball...@gentoo.org> > > > > > > wrote: > > > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > > > Author: Thomas Deutschmann gentoo > > > > > > > > > > > > > > > > org> > > > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > > > > > > > > > > > org> > > > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > > > URL: > > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm > > > > > > > > was > > > > > > > > added, > > > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > > > whether > > > > > > > the toolchain produces PIC or not. Shared libs always > > > > > > > are, > > > > > > > and have > > > > > > > always been, built that way on Gentoo. > > > > > > > In this case, USE=pic means "no matter what it costs, I > > > > > > > do > > > > > > > not want > > > > > > > textrels", for the cases of hand written assembly that > > > > > > > has to > > > > > > > be > > > > > > > rewritten to support PIC. And, still in this case, this > > > > > > > costs > > > > > > > a lot > > > > > > > of performance, so it is enabled by default on hardened > > > > > > > profiles > > > > > > > and not others. > > > > > > > Textrels work fine (on some architectures), they disallow > > > > > > > W^X > > > > > > > and > > > > > > > force each process using the shared lib to make a "copy" > > > > > > > at > > > > > > > runtime > > > > > > > in order to resolve relocations, so are not desirable but > > > > > > > sometimes > > > > > > > the cost outweights the gain. > > > > > > > > > > > > > > Plus, profiles/features/hardened enables pic by default > > > > > > > but > > > > > > > knows > > > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > > > default USE > > > > > > value in the hardened profile should not drive decisions on > > > > > > what we > > > > > > name USE flags. > > > > > > > > > > ... but using a global well documented useflag instead of a > > > > > local > > > > > invention should drive such decisions. > > > > > > > > What 'global well documented useflag'? > > > > > > It's neither global, nor well-documented, but several packages do > > > define it locally. > > > > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba > > > > I guess this hasn't been really discussed back then. > > > > It is also used in a global way in profiles (make.defaults). > > > > > Personally, I think it should be renamed to "asm" or something > > > similar > > > in the majority of cases where it actually disables all use of > > > assembly code. > > > > Thankfully these days there's usually no need to disable asm to > > have > > pic. hardened has no mention of that flag, and I think that e.g. > > for > > openssl they would have noticed long ago. > > And again, 'asm' as a useflag makes no sense: if it works and > > simply > > replaces a C function by a faster one then it shouldn't even be an > > useflag. 'pic' on the other hand conveys the tradeoff idea. > > If I understand you correctly, we should just drop the USE="pic" > logic > from the remaining packages that have it? Or are you trying to say > something else? Drop USE=asm unless there's a real reason to it: Such a useflag is, IMHO, at the same level of a useflag on dev-lang/python that would toggle dict's underlying implementations but not the semantics of the language. Have USE=pic for its historical meaning, aka, sacrificing everything to have PIC shared libs because your system enforces this (pax). Note that having the 'pic' useflag should be considered something to be fixed: rewrite the asm in a PIC way. But these days nobody has the will to do it since this is mostly an issue on x86+pax, both being slowly decreasing.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 7:35 PM Alexis Ballier wrote: > > On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > > On Mon, May 25, 2020 at 3:18 PM Michał Górny > > wrote: > > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > > On Mon, 25 May 2020 11:26:26 -0400 > > > > Mike Gilbert wrote: > > > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > > aball...@gentoo.org> > > > > > wrote: > > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > > Author: Thomas Deutschmann gentoo > > > > > > > org> > > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > > org> > > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > > URL: > > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was > > > > > > > added, > > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > > whether > > > > > > the toolchain produces PIC or not. Shared libs always are, > > > > > > and have > > > > > > always been, built that way on Gentoo. > > > > > > In this case, USE=pic means "no matter what it costs, I do > > > > > > not want > > > > > > textrels", for the cases of hand written assembly that has to > > > > > > be > > > > > > rewritten to support PIC. And, still in this case, this costs > > > > > > a lot > > > > > > of performance, so it is enabled by default on hardened > > > > > > profiles > > > > > > and not others. > > > > > > Textrels work fine (on some architectures), they disallow W^X > > > > > > and > > > > > > force each process using the shared lib to make a "copy" at > > > > > > runtime > > > > > > in order to resolve relocations, so are not desirable but > > > > > > sometimes > > > > > > the cost outweights the gain. > > > > > > > > > > > > Plus, profiles/features/hardened enables pic by default but > > > > > > knows > > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > > default USE > > > > > value in the hardened profile should not drive decisions on > > > > > what we > > > > > name USE flags. > > > > > > > > ... but using a global well documented useflag instead of a local > > > > invention should drive such decisions. > > > > > > What 'global well documented useflag'? > > > > It's neither global, nor well-documented, but several packages do > > define it locally. > > > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 > > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba > > I guess this hasn't been really discussed back then. > > It is also used in a global way in profiles (make.defaults). > > > Personally, I think it should be renamed to "asm" or something > > similar > > in the majority of cases where it actually disables all use of > > assembly code. > > Thankfully these days there's usually no need to disable asm to have > pic. hardened has no mention of that flag, and I think that e.g. for > openssl they would have noticed long ago. > And again, 'asm' as a useflag makes no sense: if it works and simply > replaces a C function by a faster one then it shouldn't even be an > useflag. 'pic' on the other hand conveys the tradeoff idea. If I understand you correctly, we should just drop the USE="pic" logic from the remaining packages that have it? Or are you trying to say something else?
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 17:04 -0400, Mike Gilbert wrote: > On Mon, May 25, 2020 at 3:18 PM Michał Górny > wrote: > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > > On Mon, 25 May 2020 11:26:26 -0400 > > > Mike Gilbert wrote: > > > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier < > > > > aball...@gentoo.org> > > > > wrote: > > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > > "Thomas Deutschmann" wrote: > > > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > > Author: Thomas Deutschmann gentoo > > > > > > org> > > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > > Commit: Thomas Deutschmann gentoo > > > > > > org> > > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > > URL: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was > > > > > > added, > > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > > > You got it wrong here it seems: USE=pic does not control > > > > > whether > > > > > the toolchain produces PIC or not. Shared libs always are, > > > > > and have > > > > > always been, built that way on Gentoo. > > > > > In this case, USE=pic means "no matter what it costs, I do > > > > > not want > > > > > textrels", for the cases of hand written assembly that has to > > > > > be > > > > > rewritten to support PIC. And, still in this case, this costs > > > > > a lot > > > > > of performance, so it is enabled by default on hardened > > > > > profiles > > > > > and not others. > > > > > Textrels work fine (on some architectures), they disallow W^X > > > > > and > > > > > force each process using the shared lib to make a "copy" at > > > > > runtime > > > > > in order to resolve relocations, so are not desirable but > > > > > sometimes > > > > > the cost outweights the gain. > > > > > > > > > > Plus, profiles/features/hardened enables pic by default but > > > > > knows > > > > > nothing about USE=asm so this is a regression for them. > > > > > > > > The USE flag toggles use of assembly, not use of PIC. The > > > > default USE > > > > value in the hardened profile should not drive decisions on > > > > what we > > > > name USE flags. > > > > > > ... but using a global well documented useflag instead of a local > > > invention should drive such decisions. > > > > What 'global well documented useflag'? > > It's neither global, nor well-documented, but several packages do > define it locally. > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=103236c295aa30e5e42cfc8a7429e4eea5f0d680 https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/profiles/use.desc?id=784deb7134b9d430546557a8f8a0877bf35c02ba I guess this hasn't been really discussed back then. It is also used in a global way in profiles (make.defaults). > Personally, I think it should be renamed to "asm" or something > similar > in the majority of cases where it actually disables all use of > assembly code. Thankfully these days there's usually no need to disable asm to have pic. hardened has no mention of that flag, and I think that e.g. for openssl they would have noticed long ago. And again, 'asm' as a useflag makes no sense: if it works and simply replaces a C function by a faster one then it shouldn't even be an useflag. 'pic' on the other hand conveys the tradeoff idea.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 3:18 PM Michał Górny wrote: > > On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > > On Mon, 25 May 2020 11:26:26 -0400 > > Mike Gilbert wrote: > > > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > > > wrote: > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > > "Thomas Deutschmann" wrote: > > > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > > Author: Thomas Deutschmann gentoo org> > > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > > Commit: Thomas Deutschmann gentoo org> > > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > > URL: > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > > > we no longer need a USE flag to control that behavior. > > > > > > > > You got it wrong here it seems: USE=pic does not control whether > > > > the toolchain produces PIC or not. Shared libs always are, and have > > > > always been, built that way on Gentoo. > > > > In this case, USE=pic means "no matter what it costs, I do not want > > > > textrels", for the cases of hand written assembly that has to be > > > > rewritten to support PIC. And, still in this case, this costs a lot > > > > of performance, so it is enabled by default on hardened profiles > > > > and not others. > > > > Textrels work fine (on some architectures), they disallow W^X and > > > > force each process using the shared lib to make a "copy" at runtime > > > > in order to resolve relocations, so are not desirable but sometimes > > > > the cost outweights the gain. > > > > > > > > Plus, profiles/features/hardened enables pic by default but knows > > > > nothing about USE=asm so this is a regression for them. > > > > > > The USE flag toggles use of assembly, not use of PIC. The default USE > > > value in the hardened profile should not drive decisions on what we > > > name USE flags. > > > > ... but using a global well documented useflag instead of a local > > invention should drive such decisions. > > What 'global well documented useflag'? It's neither global, nor well-documented, but several packages do define it locally. profiles % grep ":pic " use.local.desc app-arch/gzip:pic - disable optimized assembly code that is not PIC friendly app-benchmarks/ramspeed:pic - Force shared libraries to be built as PIC (this is slower) dev-libs/gmp:pic - Force static libraries to be built as PIC to avoid TEXTRELs. gnome-base/orbit:pic - Force libname-server-2 to be built as PIC; needed on hardened systems media-libs/x264:pic - disable optimized assembly code that is not PIC friendly media-libs/x265:pic - Disable optimized assembly code that is not PIC friendly media-libs/xvid:pic - disable optimized assembly code that is not PIC friendly media-video/ffmpeg:pic - Force shared libraries to be built as PIC (this is slower) media-video/transcode:pic - disable optimized assembly code that is not PIC friendly www-client/chromium:pic - Disable optimized assembly code that is not PIC friendly I suspect this flag got copy/pasted between various packages related to ffmpeg. That's certainly how chromium ended up with it. Personally, I think it should be renamed to "asm" or something similar in the majority of cases where it actually disables all use of assembly code.
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 2020-05-25 at 19:49 +0200, Alexis Ballier wrote: > On Mon, 25 May 2020 11:26:26 -0400 > Mike Gilbert wrote: > > > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > > wrote: > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > > "Thomas Deutschmann" wrote: > > > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > > Author: Thomas Deutschmann gentoo org> > > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > > Commit: Thomas Deutschmann gentoo org> > > > > CommitDate: Sun May 24 20:23:53 2020 + > > > > URL: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > > > media-libs/x265: drop USE=pic > > > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > > we no longer need a USE flag to control that behavior. > > > > > > You got it wrong here it seems: USE=pic does not control whether > > > the toolchain produces PIC or not. Shared libs always are, and have > > > always been, built that way on Gentoo. > > > In this case, USE=pic means "no matter what it costs, I do not want > > > textrels", for the cases of hand written assembly that has to be > > > rewritten to support PIC. And, still in this case, this costs a lot > > > of performance, so it is enabled by default on hardened profiles > > > and not others. > > > Textrels work fine (on some architectures), they disallow W^X and > > > force each process using the shared lib to make a "copy" at runtime > > > in order to resolve relocations, so are not desirable but sometimes > > > the cost outweights the gain. > > > > > > Plus, profiles/features/hardened enables pic by default but knows > > > nothing about USE=asm so this is a regression for them. > > > > The USE flag toggles use of assembly, not use of PIC. The default USE > > value in the hardened profile should not drive decisions on what we > > name USE flags. > > ... but using a global well documented useflag instead of a local > invention should drive such decisions. What 'global well documented useflag'? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, 25 May 2020 11:26:26 -0400 Mike Gilbert wrote: > On Mon, May 25, 2020 at 9:13 AM Alexis Ballier > wrote: > > > > On Sun, 24 May 2020 20:25:11 + (UTC) > > "Thomas Deutschmann" wrote: > > > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > > Author: Thomas Deutschmann gentoo org> > > > AuthorDate: Sun May 24 19:47:08 2020 + > > > Commit: Thomas Deutschmann gentoo org> > > > CommitDate: Sun May 24 20:23:53 2020 + > > > URL: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > > > media-libs/x265: drop USE=pic > > > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > > we no longer need a USE flag to control that behavior. > > > > > > You got it wrong here it seems: USE=pic does not control whether > > the toolchain produces PIC or not. Shared libs always are, and have > > always been, built that way on Gentoo. > > In this case, USE=pic means "no matter what it costs, I do not want > > textrels", for the cases of hand written assembly that has to be > > rewritten to support PIC. And, still in this case, this costs a lot > > of performance, so it is enabled by default on hardened profiles > > and not others. > > Textrels work fine (on some architectures), they disallow W^X and > > force each process using the shared lib to make a "copy" at runtime > > in order to resolve relocations, so are not desirable but sometimes > > the cost outweights the gain. > > > > Plus, profiles/features/hardened enables pic by default but knows > > nothing about USE=asm so this is a regression for them. > > The USE flag toggles use of assembly, not use of PIC. The default USE > value in the hardened profile should not drive decisions on what we > name USE flags. ... but using a global well documented useflag instead of a local invention should drive such decisions. > > You can add the flag to package.use or package.use.mask in the > hardened profile if necessary. Sure but it was not added there and it's not really relevant here since USE=asm does not make any sense either. (aka: this was better before this series of commits)
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/x265/
On Mon, May 25, 2020 at 9:13 AM Alexis Ballier wrote: > > On Sun, 24 May 2020 20:25:11 + (UTC) > "Thomas Deutschmann" wrote: > > > commit: 6e149596cc76f1bbcee6720828c8c8c92420f2a3 > > Author: Thomas Deutschmann gentoo org> > > AuthorDate: Sun May 24 19:47:08 2020 + > > Commit: Thomas Deutschmann gentoo org> > > CommitDate: Sun May 24 20:23:53 2020 + > > URL: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e149596 > > > > media-libs/x265: drop USE=pic > > > > Gentoo's toolchain uses PIC by default. Since USE=asm was added, > > we no longer need a USE flag to control that behavior. > > > You got it wrong here it seems: USE=pic does not control whether > the toolchain produces PIC or not. Shared libs always are, and have > always been, built that way on Gentoo. > In this case, USE=pic means "no matter what it costs, I do not want > textrels", for the cases of hand written assembly that has to be > rewritten to support PIC. And, still in this case, this costs a lot of > performance, so it is enabled by default on hardened profiles and not > others. > Textrels work fine (on some architectures), they disallow W^X and force > each process using the shared lib to make a "copy" at runtime in order > to resolve relocations, so are not desirable but sometimes the cost > outweights the gain. > > Plus, profiles/features/hardened enables pic by default but knows > nothing about USE=asm so this is a regression for them. The USE flag toggles use of assembly, not use of PIC. The default USE value in the hardened profile should not drive decisions on what we name USE flags. You can add the flag to package.use or package.use.mask in the hardened profile if necessary.
