View previous topic :: View next topic |
Author |
Message |
Hu Administrator
Joined: 06 Mar 2007 Posts: 21793
|
Posted: Thu May 18, 2017 2:00 am Post subject: |
|
|
Traditionally, non-PIE x86 embeds the address of the global as a literal in the instruction. That is fine if the shared object loads at the expected address. If it does not, then all the global references (and frequently this would be hundreds or thousands of sites) need to be fixed by the loader. PIE x86 uses ebx as the PIE offset register and expresses the address of the global as a function of that register, where that register is loaded with a value derived from the shared object's address, thus making it position independent, so there are no sites to fix. So yes, using PIE on x86 costs an otherwise-general-purpose register that, if it were not used for PIE, could be used for arithmetic or pointer operations related to program logic.
On amd64, globals are typically indexed directly off rip, which is already "busy" as the program counter register, so it is effectively zero cost, because the program could not repurpose rip even if it were not being used for globals. For the other architectures, the question is not specifically about 32-bit vs 64-bit, but about how they address global variables. It's probably fair to assume that most 64-bit systems will use some variant of the amd64 design, where globals are accessed as a 32-bit offset off a register instead of using a 64-bit literal address. Other 32-bit systems might follow the amd64 design due to decisions by their respective designers, in which case they too would have zero-register-cost PIE. From a quick read about ARM, it looks like they use register-relative addressing on 32-bit. This makes sense, since they prefer to have fixed width instructions, and the instruction is not wide enough to encode both a command code and a full 32-bit address.
This also means that ct85711 is correct about people using x86 Linux on a 64-bit CPU. The issue is not what the CPU can do, but about the instructions used. Any x86 PIE Linux has the PIE limitations, whether run on an old i686, a modern x86_64 in IA32 emulation mode, or a virtual machine (possibly with an exotic host architecture) emulating x86.
ct85711: you can use a hardened profile without a hardened kernel (though you get less than full protection that way). If you want to use PIE, I think using a hardened profile would be the easiest way to enable it. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Thu May 18, 2017 7:34 am Post subject: |
|
|
ct85711,
Nothing broke here going from -pie to pie on amd64 /no-multilib/ nor or arm64 but I did do a full emerge -e world.
With an amd64 multilib system, it was more problematic.
I had to add -fPIC to CFLAGS to get almost anything to build.
Its not quite that clear cut, since I moved to gcc-7.1 at the same time.
I should have migrated that multilib system to no-multilib, since in the 6 years its been running, its never run any 32 bit code. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
ct85711 Veteran
Joined: 27 Sep 2005 Posts: 1791
|
Posted: Thu May 18, 2017 2:54 pm Post subject: |
|
|
Hu wrote: | ct85711: you can use a hardened profile without a hardened kernel (though you get less than full protection that way). If you want to use PIE, I think using a hardened profile would be the easiest way to enable it. |
Thanks Hu, this lets me know that an PIE profile for non-hardened systems isn't available yet. Frankly, I am not worried much about the protection, as my threat profile isn't concerned about the host, but more of remote threats. So for me, hardened profile and hardened kernel adds little benefit. Most of the desire of using PIE is to test it out on my machine, and help test for potential breakage if the devs transition the profiles to start using PIE.
NeddySeagoon wrote: | Nothing broke here going from -pie to pie on amd64 /no-multilib/ nor or arm64 but I did do a full emerge -e world.
With an amd64 multilib system, it was more problematic.
I had to add -fPIC to CFLAGS to get almost anything to build.
Its not quite that clear cut, since I moved to gcc-7.1 at the same time.
I should have migrated that multilib system to no-multilib, since in the 6 years its been running, its never run any 32 bit code. |
Thank you for testing and letting me know, as this indicates that this will explode right away in my face, as I am using multilib system. Right now, I am still on gcc-6, and I need to see if switching to a non-multilib system for me is feasible or not. A lot of it is that I need to go through and see what all 32bit code I am still using and what can go away. I already moved away the main ones that would have restricted me, so this may be something that I can go ahead and migrate over. I know I was already intending to do a full emerge -e world, when I do such a big change to the overall system. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Fri May 19, 2017 5:31 am Post subject: |
|
|
NeddySeagoon wrote: | I had to add -fPIC to CFLAGS to get almost anything to build. |
This is strange. I am running amd64 multilib and did never needed -fPIC for any package. The only package which required -no-pie is clisp which apparently internally does a lot of ugly things.
Perhaps you did not start with a recompilation of glibc which is the main provider of static libs unless you use a lot of USE=static-libs. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Fri May 19, 2017 9:31 am Post subject: |
|
|
mv,
I went straight for which just worked on no-multilib. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Fri May 19, 2017 12:07 pm Post subject: |
|
|
NeddySeagoon wrote: | I went straight for which just worked on no-multilib. |
The problem with -e @world is that glibc is never listed as an explicit dependency (because it belongs to @system), and that the order of the packages in @system is not well-defined (perhaps even the dependencies of some packages from @system might be emerged before system in some cases) |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6052 Location: Removed by Neddy
|
Posted: Sun May 21, 2017 5:49 pm Post subject: |
|
|
gold linker is causing some issues as well by the way _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Sun May 21, 2017 5:53 pm Post subject: |
|
|
Naib,
That's separate to gcc though. Its its own can of worms.
It has got better with newer binutils.
My arm64 rebuild has been running 7 days 24/7 and its still not done.
During the day, my amd64 has been helping out. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6052 Location: Removed by Neddy
|
Posted: Sun May 21, 2017 5:56 pm Post subject: |
|
|
oh I know, just wanted to report it here just incase other are finding issues with GCC-7.1 while the issue could be elsewhere. I am not sure why samba compiled fine when I 1st did and emerge -e world, but this 2nd pass is causing some interesting failures. just reverted to old linker and samba compiles fine, going to emerge -e world to catch the others _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Sun May 21, 2017 6:48 pm Post subject: |
|
|
Naib wrote: | why samba compiled fine when I 1st did and emerge -e world |
Perhaps your emerge -e @world did not --exclude binutils? When binutils are emerged, your gold linker is set back to bfd until you manually set the gold linker again… |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Sun May 21, 2017 7:03 pm Post subject: |
|
|
mv,
Or you set the gold linker to be the default in /etc/portage/env/ _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Sun May 21, 2017 7:08 pm Post subject: |
|
|
NeddySeagoon wrote: | Or you set the gold linker to be the default in /etc/portage/env/ |
Do you mean like this, or do you know a better way?
Edit: The above link has become invalid, because a better method discussed below is used.
Last edited by mv on Sun Jun 04, 2017 4:37 am; edited 1 time in total |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6052 Location: Removed by Neddy
|
Posted: Sun May 21, 2017 7:47 pm Post subject: |
|
|
what I had was via this. https://wiki.gentoo.org/wiki/Gold
A few ebuilds force BFD
Quote: | Messages generated by process 16188 on 2017-04-27 00:11:39 BST for package media-libs/libmypaint-1.3.0:
WARN: configure
Forcing usage of the BFD linker instead of GOLD
|
Quote: |
Messages generated by process 11137 on 2017-04-29 17:08:44 BST for package sys-boot/grub-2.02:
WARN: configure
Forcing usage of the BFD linker instead of GOLD
|
Quote: |
Messages generated by process 6187 on 2017-05-01 09:35:49 BST for package sys-libs/glibc-2.24-r1:
WARN: configure
Forcing usage of the BFD linker instead of GOLD
Forcing usage of the BFD linker instead of GOLD |
I think I might emerge -e @world again for a final pass, without gold _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Sun May 21, 2017 8:38 pm Post subject: |
|
|
mv,
As explained at the bottom of the Gold Linker wiki page.
There is also -fuse-ld=gold which I think goes in CFLAGS.
I've not tried it. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6749
|
Posted: Mon May 22, 2017 3:23 am Post subject: |
|
|
NeddySeagoon wrote: | As explained at the bottom of the Gold Linker wiki page. |
Thanks. This is much better than the mentioned hack.
The oppsite (-fuse-ld=bfd) is useful in the few cases where gold breaks. In fact, it is even used in some ebuilds. However, I would not rely on the opposite, since there may be some packages which do not honour CFLAGS throughout. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6052 Location: Removed by Neddy
|
Posted: Sat Jun 03, 2017 10:02 pm Post subject: |
|
|
dev-qt/qtwebengine-5.x won't build with gcc-7.1 either:
Code: | /var/tmp/portage/dev-qt/qtwebengine-5.7.1-r1/work/qtwebengine-opensource-src-5.7.1/src/3rdparty/chromium/mojo/public/cpp/bindings/interface_ptr_info.h:37:31: error: ‘mojo::ScopedMessagePipeHandle {aka class mojo::ScopedHandleBase<mojo::MessagePipeHandle>}’ has no member named ‘Pass’
handle_ = other.handle_.Pass();
^~~~
|
upstream bugreport exists to change Pass() _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
CaptainBlood Advocate
Joined: 24 Jan 2010 Posts: 3657
|
Posted: Sun Jun 04, 2017 4:03 pm Post subject: |
|
|
NeddySeagoon wrote: | mv,
As explained at the bottom of the Gold Linker wiki page.
There is also -fuse-ld=gold which I think goes in CFLAGS.
I've not tried it. |
I'm doin it only @LDFLAGS.
I maybe wrong.
Thks 4 ur attention. |
|
Back to top |
|
|
wrc1944 Advocate
Joined: 15 Aug 2002 Posts: 3436 Location: Gainesville, Florida
|
Posted: Sat Jun 10, 2017 10:00 pm Post subject: |
|
|
Naib- the "dev-qt/qtwebengine-5.x won't build with gcc-7.1" problem was solved for me by the 2 patches Mark Wright posted at:
https://bugs.gentoo.org/show_bug.cgi?id=617896
However, two days ago qtwebengine again failed on a rebuild which came with the plasma update, and when I removed the 2 patches, I could then rebuild qtwebengine.
I'm no expert, but I think it was because after I used the two patches I then later updated to binutils-2.28-r1 right before the full plasma-meta update. Apparently, the patches were then no longer needed or conflicted for building qtwebengine with gcc-7 and binutils-2.28-r1.
Would that be correct? _________________ Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.9.1 USE=experimental python3_11 |
|
Back to top |
|
|
saboya Guru
Joined: 28 Nov 2006 Posts: 552 Location: Brazil
|
Posted: Sun Jun 11, 2017 3:44 am Post subject: |
|
|
wrc1944 wrote: | Naib- the "dev-qt/qtwebengine-5.x won't build with gcc-7.1" problem was solved for me by the 2 patches Mark Wright posted at:
https://bugs.gentoo.org/show_bug.cgi?id=617896
However, two days ago qtwebengine again failed on a rebuild which came with the plasma update, and when I removed the 2 patches, I could then rebuild qtwebengine.
I'm no expert, but I think it was because after I used the two patches I then later updated to binutils-2.28-r1 right before the full plasma-meta update. Apparently, the patches were then no longer needed or conflicted for building qtwebengine with gcc-7 and binutils-2.28-r1.
Would that be correct? |
Actually it's because the Gentoo devs pushed the patches to the portage tree:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90f45d0172ad22d6b8a6e77025499156b704dcc9 |
|
Back to top |
|
|
asturm Developer
Joined: 05 Apr 2007 Posts: 8942
|
Posted: Sun Jun 11, 2017 6:32 am Post subject: |
|
|
wrc1944 wrote: | ...and when I removed the 2 patches, I could then rebuild qtwebengine. |
You don't have to be an expert to pay attention to error messages - they would have told you that your patches did not apply anymore. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6052 Location: Removed by Neddy
|
Posted: Sun Jun 11, 2017 8:47 am Post subject: |
|
|
Yup, I emerged both last night without any error _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8710 Location: ~Brussels - Belgique
|
Posted: Mon Jun 19, 2017 8:28 am Post subject: |
|
|
Hi!,
I switched to ld.gold and I try to find how to tell the kernel make to use ld.bfd. I tried to enabe CFLAGS, LDFLAGS, LD, environment variables, but it does'nt work (VDSO fails to build). Any idea? _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Mon Jun 19, 2017 10:18 am Post subject: |
|
|
xaviermiller,
Code: | CFLAGS -fuse-ld=gold | tells the system to use the gold linker.
I know it works the other way too as some build system force it.
You can set CFLAGS on a per packages basis. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
xaviermiller Bodhisattva
Joined: 23 Jul 2004 Posts: 8710 Location: ~Brussels - Belgique
|
Posted: Mon Jun 19, 2017 10:24 am Post subject: |
|
|
what I do is Code: | CFLAGS="-fuse-ld=bfd" LD="ld.bfd" make | but the environment variables are not well taken into account _________________ Kind regards,
Xavier Miller |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54407 Location: 56N 3W
|
Posted: Mon Jun 19, 2017 10:32 am Post subject: |
|
|
xaviermiller,
CFLAGS="${CFLAGS} -fuse-ld=bfd" USE="..." emerge ...
Will append -fuse-ld=bfd to the CFLAGS from make.conf. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|