Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Profile 17.0
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
jagdpanther
Guru
Guru


Joined: 22 Nov 2003
Posts: 362

PostPosted: Sun Dec 03, 2017 8:19 pm    Post subject: Reply with quote

Does it matter if I recompile my kernel using the new gentoo profile 17 (ie. -pie) before or after I reubild my system with ' emerge -e @world' ??
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39297
Location: 56N 3W

PostPosted: Sun Dec 03, 2017 8:25 pm    Post subject: Reply with quote

jagdpanther

No. The kernel rebuild can be any time after the gcc rebuild.
I'm not sure it matters as the kernel build system sets all its own CFLAGS.
Therefore, the kernel may not change.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
jagdpanther
Guru
Guru


Joined: 22 Nov 2003
Posts: 362

PostPosted: Sun Dec 03, 2017 8:40 pm    Post subject: Reply with quote

NeddySeagoon:

> No. The kernel rebuild can be any time after the gcc rebuild.

Thanks.

I ask because I read a comment about an issue with virtuabox-modules after the writer upgraded to gentoo profile 17 but before he re-compiled his kernel. (I use three 'extra' kernel module packages: virtualbox-modules, vmware-modules and nvidia-drivers and am trying to minimize issues with the large 'emerge -e @world')
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 39297
Location: 56N 3W

PostPosted: Sun Dec 03, 2017 8:47 pm    Post subject: Reply with quote

jagdpanther,

That's a different question.
You must update the kernel before you update modules that build against it.

Update kernel
emerge @module-rebuild
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1332
Location: United Kingdom

PostPosted: Sun Dec 03, 2017 10:46 pm    Post subject: Reply with quote

mv wrote:
papandreoos wrote:
is there a flag that will tell portage to exclude all the already-reinstalled packages?

No, but you can try something along the lines of
Code:
emerge -1 $(eix-installed-after -btF /usr/bin/gcc)

I found that the above-mentioned eix-installed-after command did not exclude the already re-installed packages, so I did the following instead, which did exclude the already-installed packages:

Code:
# eix-installed-after -btF /usr/bin/gcc | sort > before-gcc
# eix-installed-after -tF /usr/bin/gcc | sort > after-gcc
# diff -U $(wc -l < before-gcc) before-gcc after-gcc | sed -n 's/^-//p' > diff-list
# tail -n +2 diff-list > merge-list
# emerge -1 --keep-going $(cat merge-list)

_________________
Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.

Fitzcarraldo's blog


Last edited by Fitzcarraldo on Sun Dec 03, 2017 10:50 pm; edited 1 time in total
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 4528

PostPosted: Sun Dec 03, 2017 10:50 pm    Post subject: Reply with quote

Longer answer: the kernel both is and isn't PIE code - it's very position-dependent because CPU interrupt vectors and BIOS interfaces live at fixed positions in low memory. It *also* has to be position-independent because everything newer than a 386 has the concept of plug and play, where devices and their reserved addresses can come and go outside of the kernel's control, and it has to navigate around those. It doesn't use GCC's normal flags for that reason.
_________________
*.ebuild // /etc/service/*
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2395
Location: Canada

PostPosted: Mon Dec 04, 2017 2:16 am    Post subject: Reply with quote

Tony0945 wrote:
The question remains "How slow is compiling with pie?". It seems very slow but I did not have a benchmark to compare to other than the total emerge -e world time. Since the last time I did a world emerge was at least two portage versions and one minor gcc version back, that's not a data point, just a concern.

In another thread I had compared some phoronix benchmarks against this system versus published ryzen 7 results. I could rerun them and see if they had changed.

Another approach is to compare compile times for one or more packages using measured times between this system on profile 17.0 and my profile 13.0 Phenom II system by turning off three cores and limiting the CPU multiplier. That still wouldn't account for the other system having twice the RAM unless I benchmarked builds that don't use swap on either system.

I'll do some research and report my findings in a new thread on Gentoo Chat.


Thanks, would be interesting to see the numbers. I may do a check as well, if I find the time. But, without hard numbers, compilation of gcc itself seemed notably slower.
I have new i7 Skylake laptop with 16 GB RAM and just installed gcc-6.4.0 with 13.0 profile couple of weeks ago, and did notice notable delay. Recompile gcc yesterday with 17.0 profile, and it took lwhat seemed like 45 minutes. Again, I did not time it, but was just coming back again expecting it to finish long time ago, and it did not.
On my old 2007 core 2 duo desktop, it took over 1 hour, and I left before it finished.

Anyway, that needs to be checked, this was just a feel on my side.
Back to top
View user's profile Send private message
BitJam
Advocate
Advocate


Joined: 12 Aug 2003
Posts: 2476
Location: Silver City, NM

PostPosted: Mon Dec 04, 2017 2:25 am    Post subject: Reply with quote

I recently did a system upgrade. Quad core to octa core, 8 Gig to 32 Gig, faster sata. This pretty much canceled out the pie degradation so the compile time for gcc was almost the same.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 2395
Location: Canada

PostPosted: Mon Dec 04, 2017 2:41 am    Post subject: Reply with quote

BitJam wrote:
I recently did a system upgrade. Quad core to octa core, 8 Gig to 32 Gig, faster sata. This pretty much canceled out the pie degradation so the compile time for gcc was almost the same.


Sounds like bad news for people with fixed hardware to support :)
Back to top
View user's profile Send private message
Fitzcarraldo
Veteran
Veteran


Joined: 30 Aug 2008
Posts: 1332
Location: United Kingdom

PostPosted: Mon Dec 04, 2017 3:30 am    Post subject: Reply with quote

On my Clevo W230SS laptop (Intel Core i7-4810MQ CPU @ 2.80GHz and 16GB RAM) the output of the command 'genlop -t gcc' before and after migration from the 13.0 plasma profile to the 17.0 plasma profile doesn't show much difference in merge times.

Code:
# uname -a
Linux clevow230ss 4.12.12-gentoo #2 SMP Sat Dec 2 04:20:45 GMT 2017 x86_64 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz GenuineIntel GNU/Linux
# grep MemTotal /proc/meminfo
MemTotal:       16346168 kB
# eselect profile list | grep plasma | grep -v systemd
  [6]   default/linux/amd64/13.0/desktop/plasma
  [18]  default/linux/amd64/17.0/desktop/plasma *


Code:

    Wed Nov 22 01:36:07 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 4 seconds.   <------ Merge time using gcc-5.4.0-r3 and 13.0 profile

     Fri Dec  1 02:34:10 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 35 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

     Fri Dec  1 17:39:01 2017 >>> sys-devel/gcc-6.4.0
       merge time: 31 minutes and 15 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

     Sat Dec  2 02:54:37 2017 >>> sys-devel/gcc-6.4.0
       merge time: 32 minutes and 22 seconds.  <------ Merge time using gcc-6.4.0 and 17.0 profile

_________________
Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5752

PostPosted: Mon Dec 04, 2017 7:15 am    Post subject: Reply with quote

Fitzcarraldo wrote:
mv wrote:
Code:
emerge -1 $(eix-installed-after -btF /usr/bin/gcc)

I found that the above-mentioned eix-installed-after command did not exclude the already re-installed packages

It excludes everything which was (re)emerged after the timestamp of /usr/bin/gcc.
This timestamp is usually the timestamp when gcc-config was used last time. If you did use this after the installation of gcc, you should probably use another file for reference (or you can omit the -F and specify sys-devel/gcc:7.2.0 (use your slot number) instead, or -l sys-devel/gcc-7.2.0 (use your version number)).
Fitzcarraldo wrote:
Code:
# eix-installed-after -btF /usr/bin/gcc | sort > before-gcc
# eix-installed-after -tF /usr/bin/gcc | sort > after-gcc

It would be serious a bug in the eix-installed-after script (or of the stat utility) if the intersection of these files contains anything (unless something changed the timestamp of /usr/bin/gcc or the /var/db database between the two calls). If you can reproduce this, please report an eix bug.

BTW, to find the intersection of two sorted files you can use
Code:
comm -12 file1 file2
or for unsorted files also
Code:
commlist -2 file1 "" file2
(commlist is in dev-util/mv_perl in the mv overlay).
Back to top
View user's profile Send private message
slackline
Veteran
Veteran


Joined: 01 Apr 2005
Posts: 1390
Location: /uk/sheffield

PostPosted: Mon Dec 04, 2017 4:06 pm    Post subject: Reply with quote

dilfridge wrote:
slackline wrote:
asturm wrote:
No need to if you're already on 7.2.


Thanks for the reply, do you mean I can just select the new profile and then emerge -e @world or do I still need to compile sys-devel/binutils and sys-libs/glibc (already done up to emergeing sys-devel/libtool).

Sorry for the dumb quesiton, just not clear to me what it is I've no need to do.


Sorry, the news item was originally written when gcc-7.2 was still without keywords.

If you're already on 7.2, just replace 6.4.0 with 7.2.0 everywhere in the instructions. You still need to follow the whole procedure though to be 100% sure that everything works.

That said... On a typical system, the fallout from not rebuilding world may be rather small. Many of the developers who tested the 17.0 profiles did no rebuilds at all, and ended up only with a few random build failures at some point later. Then again, the devs recognize the errors that result (I hope), can fix them (I hope) and do not file invalid bugs about it (I hope)... :)


Proceeded with re-emerging world and a couple of packages didn't build, some rebuilt again on trying others didn't those that didn't are detailed in bug reports as follows...

#621848 dev-libs/klibc
#636420 games-puzzle/pingus
#639776 xfce4-extra/xfce4-diskperf-plugin
#638634 sys-apps/raidutils (although as noted this appears to be dead upstream, can't recall ever using it myself so have removed it)

I use the no-multilib profile...

Code:

# eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/13.0
  [2]   default/linux/amd64/13.0/selinux
  [3]   default/linux/amd64/13.0/desktop
  [4]   default/linux/amd64/13.0/desktop/gnome
  [5]   default/linux/amd64/13.0/desktop/gnome/systemd
  [6]   default/linux/amd64/13.0/desktop/plasma
  [7]   default/linux/amd64/13.0/desktop/plasma/systemd
  [8]   default/linux/amd64/13.0/developer
  [9]   default/linux/amd64/13.0/no-multilib
  [10]  default/linux/amd64/13.0/systemd
  [11]  default/linux/amd64/13.0/x32
  [12]  default/linux/amd64/17.0
  [13]  default/linux/amd64/17.0/selinux
  [14]  default/linux/amd64/17.0/hardened
  [15]  default/linux/amd64/17.0/desktop
  [16]  default/linux/amd64/17.0/desktop/gnome
  [17]  default/linux/amd64/17.0/desktop/gnome/systemd
  [18]  default/linux/amd64/17.0/desktop/plasma
  [19]  default/linux/amd64/17.0/desktop/plasma/systemd
  [20]  default/linux/amd64/17.0/developer
  [21]  default/linux/amd64/17.0/no-multilib *
  [22]  default/linux/amd64/17.0/systemd
  [23]  default/linux/amd64/17.0/x32
  [24]  hardened/linux/amd64
  [25]  hardened/linux/amd64/selinux
  [26]  hardened/linux/amd64/no-multilib
  [27]  hardened/linux/amd64/no-multilib/selinux
  [28]  hardened/linux/amd64/x32
  [29]  hardened/linux/musl/amd64
  [30]  hardened/linux/musl/amd64/x32
  [31]  default/linux/uclibc/amd64
  [32]  hardened/linux/uclibc/amd64


...and have rebuilt the kernel, I do use an initramfs which if I've understood correctly uses the minimal libc that dev-libs/klibc provides, and whilst I rebuilt the initramfs as part of rebuilding the kernel I'm holding back on rebooting the system until such time as I've rebuild dev-libs/klibc at which point I'll regenerate the initramfs.

Thanks to all who've worked hard on this, can't be easy making such a large change and I imagine a lot of work and testing has gone on in the background.

slackline
_________________
"Science is what we understand well enough to explain to a computer.  Art is everything else we do." - Donald Knuth
Back to top
View user's profile Send private message
pablo_supertux
Advocate
Advocate


Joined: 25 Jan 2004
Posts: 2701
Location: Somewhere between reality and Middle-Earth and in Freiburg (Germany)

PostPosted: Mon Dec 04, 2017 6:48 pm    Post subject: Reply with quote

mv wrote:
Spargeltarzan wrote:
@klynastor: Do you think you will be even able to measure this performance difference?

On an x86 system, one should be able to measure it. On an amd64 system, it should be rather hard to construct an example where one can measure any difference.



I've finished recompiling all my ~1300 packages, that was a long marathon. You say in amd64 it should be rather hard to construct an example that makes any difference. Perhaps I'm just imaging it, but I do have the feeling, that the system has become a little bit slower than usual. Let's see how it feels after a couple of days.
_________________
A! Elbereth Gilthoniel!
silivren penna míriel
o menel aglar elenath,
Gilthoniel, A! Elbereth!
Back to top
View user's profile Send private message
Wallsandfences
Apprentice
Apprentice


Joined: 29 Mar 2010
Posts: 269

PostPosted: Mon Dec 04, 2017 8:15 pm    Post subject: Reply with quote

for me it's mono that doesn't build...
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 150

PostPosted: Mon Dec 04, 2017 11:36 pm    Post subject: Reply with quote

So profile 17.0 necessitates that I should move to GCC 6 with PIE,
rebuild the whole @world, which will invariably break my system,
and possibly make it slower, just to "improve the overall security finger print" (sic).
Lots of pain for little or no gain.
It seems to me that I need this profile change like I need a hole in my forehead.
Back to top
View user's profile Send private message
Spargeltarzan
Tux's lil' helper
Tux's lil' helper


Joined: 23 Jul 2017
Posts: 130

PostPosted: Tue Dec 05, 2017 12:14 am    Post subject: Reply with quote

@proteusx: For me the "just to improve the overall security fingerprint" is now something what I don't have to care manually about any more. Thank you Gentoo :) As someone wrote already in this thread, within an amd64 system you will most likely notice no difference regarding performance. If you are afraid it will, or you don't want pie generally, force no-pie.

To activate this setting, Gentoo had to think which option most users will probably want - in my point of view this was the right decision.

When you are afraid your world rebuild will break your system, you have now got a nice chance to clean things up - the result of the world emerge will proof you did a good job.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6355
Location: almost Mile High in the USA

PostPosted: Tue Dec 05, 2017 12:39 am    Post subject: Reply with quote

So what's the guidance on x86 systems that need all the performance they can get?

Recently I've found building gcc-6.4 to be miserable, ~6+ hours on an Atom-1.6GHz (x86 only) dual thread. Though this is not related to PIC but all of the slower machines, invariably x86, will hurt even more when they're slower to begin with.

I might have to migrate my 32-bit VM to 64-bit to avoid wasting more CPU cycles than needed :(

BTW I hear a 10-15% hit on x86 but this is hearsay, I did not personally test this.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 150

PostPosted: Tue Dec 05, 2017 1:02 am    Post subject: Reply with quote

Spargeltarzan wrote:
For me the "just to improve the overall security fingerprint" is now something what I don't have to care manually about any more.

You do not have to "care manually" about it any more and as a result some others have to toil manually from now on.

I wonder how many did "Gentoo" ask before deciding that the hardened option is an "option most users will probably want".

I for one care a lot about stability and performance and care little about security.
I regarded shadow as an annoyance and pam as a serious impediment. Nasty software.
Fortunately pam can be crippled easily with pam_permit.so

Anyway I have already taken care of pie along the lines of this post
This is why we love Gentoo. We can easily circumvent creeping developer authoritarianism
and do whatever we like.

EDIT typos.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1222

PostPosted: Tue Dec 05, 2017 1:41 am    Post subject: Reply with quote

eccerr0r wrote:
So what's the guidance on x86 systems that need all the performance they can get?

Ditto...especially given that my MythTV systems (that my family depends) on are all x86, this whole thing (which I just started reading about today) is without question the most terrifying thing I've ever heard in almost 14 years using Gentoo.

I'm seeing somewhat mixed messages as to whether this whole recompile to PIE is in fact really necessary or not(??). If it truly must be one way or the other for everyone due to some technical reasons, then I suppose I can appreciate the decision. If not, this is a seriously horrific mandate to force on everyone, and it doesn't sound like I gain anything I care about from it...and may even take a performance hit. Any clarity on all this would be hugely appreciated. For now I sort of just want to cry.

Tom
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6355
Location: almost Mile High in the USA

PostPosted: Tue Dec 05, 2017 2:23 am    Post subject: Reply with quote

From what I hear, PIE on Linux is only good for security (and libraries that can be used in multiple programs). It does not help speed (and may even hurt speed). It does not help binary sizes.

As mainline Linux requires a MMU, the MMU argument has no teeth. PIE code is great for machines with no MMU.

I do question the need for this if there is a speed hit for security. This is once again something done that sacrifices speed to solve a problem that should have been solved by writing the software correctly (i.e., securely).
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
BitJam
Advocate
Advocate


Joined: 12 Aug 2003
Posts: 2476
Location: Silver City, NM

PostPosted: Tue Dec 05, 2017 2:46 am    Post subject: Reply with quote

I've been compiling for about 24 hours. It is almost done and there are a handful of packages that didn't build. The only one I'm concerned about ATM is nvidia-drivers which failed with:
Code:
error code model kernel does not support PIC mode

Do I need to rebuild the kernel before rebuilding kernel modules? Do I need to use special compiler flags when I rebuild the kernel? My guess is that I should disable pie for the kernel modules but that is only a guess and I'm not sure how to do it.
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2338

PostPosted: Tue Dec 05, 2017 2:49 am    Post subject: Reply with quote

The attacks PIE stops can't all be stopped by codding well. Theft should also be stopped by raising kids right but you still have a lock on your door because it doesn't always work out that way. Many of these attacks are used by purpose written malware as a means of privilege escalation.

The directive to recompile world is because if you don't you are likely to see unusual failures and the devs don't want to be bombarded with invalid bug reports, and with good reason. The failures would not be obviously linked. Kind of like why the GCC upgrade guide says you should emerge -e world when upgrading between major versions.

As for speed hits, that appears to be mostly speculation and conformation bias. If you actually check compile times for individual packages there is not much of a difference. If you could load up you machine with Grsecurity, PaX, and SELinux without taking a noticeable speed hit than just PIE alone isn't going to do anything noteworthy.
_________________
First things first, but not necessarily in that order.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 11431

PostPosted: Tue Dec 05, 2017 3:19 am    Post subject: Reply with quote

For systems running in amd64 mode, there should be no noticeable change in size or speed, since rip-relative addressing is normal in amd64 mode. For systems running in x86 mode, PIC (which is called PIE when used on the main program, and PIC when used on a shared library) consumes an extra register to fake eip-relative addressing since the ISA does not support it naturally. This will cause some code to run slower, since x86 has always been badly register starved. Code with large numbers of in-flight variables (such as many cryptographic digest algorithms) is often forced to spill some variables to the stack. PIC deprives the function of one additional register that non-PIC does not claim, so one more variable will need to be spilled. If the algorithm was right at the limit of what it could hold in registers, this marks the difference between spilling and not spilling. (Even if spilling is required, the stack to which it spills will almost certainly be in the L1 cache, which will mitigate the performance cost.)

Unless you've been going out of your way or using strange programs, your shared libraries are very likely PIC and have been for years. The introduction of PIE means that the main binary will also be position independent, which was historically done on hardened for a small security boost and not done on non-hardened because, for x86, it had a cost.

Whether the switch to eip-relative addressing causes a measurable change in the generated code will depend heavily on how often the code accesses global variables (and to some extent, on whether the compiler is clever about not preparing a PIC register unnecessarily). If it uses globals, then it needs a free register to fake the eip-relative addressing. A spot test here suggests that gcc-7 is clever about not using PIE unnecessarily.
p.c:
int global;

void f()
{
   ++global;
}

int g()
{
   return global;
}

int h()
{
   return 5;
}
gcc-7.1.0 -m32 -std=gnu99 -O2 -o - -S p.c -fno-stack-protector -pie | c++filt:
   .file   "p.c"
   .text
   .p2align 4,,15
   .globl   f
   .type   f, @function
f:
.LFB0:
   .cfi_startproc
   call   __x86.get_pc_thunk.ax
   addl   $_GLOBAL_OFFSET_TABLE_, %eax
   movl   global@GOT(%eax), %eax
   addl   $1, (%eax)
   ret
   .cfi_endproc
.LFE0:
   .size   f, .-f
   .p2align 4,,15
   .globl   g
   .type   g, @function
g:
.LFB1:
   .cfi_startproc
   call   __x86.get_pc_thunk.ax
   addl   $_GLOBAL_OFFSET_TABLE_, %eax
   movl   global@GOT(%eax), %eax
   movl   (%eax), %eax
   ret
   .cfi_endproc
.LFE1:
   .size   g, .-g
   .p2align 4,,15
   .globl   h
   .type   h, @function
h:
.LFB2:
   .cfi_startproc
   movl   $5, %eax
   ret
   .cfi_endproc
.LFE2:
   .size   h, .-h
   .comm   global,4,4
   .section   .text.__x86.get_pc_thunk.ax,"axG",@progbits,__x86.get_pc_thunk.ax,comdat
   .globl   __x86.get_pc_thunk.ax
   .hidden   __x86.get_pc_thunk.ax
   .type   __x86.get_pc_thunk.ax, @function
__x86.get_pc_thunk.ax:
.LFB3:
   .cfi_startproc
   movl   (%esp), %eax
   ret
   .cfi_endproc
.LFE3:
   .ident   "GCC: (Gentoo Hardened 7.1.0-r1 p1.1) 7.1.0"
   .section   .note.GNU-stack,"",@progbits
Note how h() does not prepare a PIC register, since it has no global accesses. Now look at the amd64 version:
gcc-7.1.0 -std=gnu99 -O2 -o - -S p.c -fno-stack-protector -pie | c++filt:
   .file   "p.c"
   .text
   .p2align 4,,15
   .globl   f
   .type   f, @function
f:
.LFB0:
   .cfi_startproc
   addl   $1, global(%rip)
   ret
   .cfi_endproc
.LFE0:
   .size   f, .-f
   .p2align 4,,15
   .globl   g
   .type   g, @function
g:
.LFB1:
   .cfi_startproc
   movl   global(%rip), %eax
   ret
   .cfi_endproc
.LFE1:
   .size   g, .-g
   .p2align 4,,15
   .globl   h
   .type   h, @function
h:
.LFB2:
   .cfi_startproc
   movl   $5, %eax
   ret
   .cfi_endproc
.LFE2:
   .size   h, .-h
   .comm   global,4,4
   .ident   "GCC: (Gentoo Hardened 7.1.0-r1 p1.1) 7.1.0"
   .section   .note.GNU-stack,"",@progbits
Observe how the accesses to the global are done via %rip, so there is no need to prepare a dedicated position independence register.
Back to top
View user's profile Send private message
Tony0945
Advocate
Advocate


Joined: 25 Jul 2006
Posts: 2038
Location: Illinois, USA

PostPosted: Tue Dec 05, 2017 3:22 am    Post subject: Reply with quote

The Doctor wrote:
If you actually check compile times for individual packages there is not much of a difference.

I haven't finished my promised comparison because of some methodological issues. But the preliminary view is that for Athlon II/Phenom II computers there is maybe only a few percent (1-2) loss if any. Losses seem mostly on short compiles and who cares if a compile takes 3 seconds longer? On bigger packages, configuration, and linking, patching, and swapping seem more important than the actual compiling. The world emerge took almost twice as long as usual but I'm not seeing that on individual packages. I'm not sure if that was due to pie or maybe other changes in the profile. I seemed to spend an inordinate amount of time on qt stuff, but wxGTK stuff zips along.

I do agree with those that say we should have had the choice of migrating the profile or not, just on philosophical grounds. Are we going to to check the news some day and find that pulseaudio or systemd are now mandatory because the devs think it's the better choice?
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 6355
Location: almost Mile High in the USA

PostPosted: Tue Dec 05, 2017 4:00 am    Post subject: Reply with quote

The problem is that building everything with -fPIC means that all binaries, even past compilation, will be affected - so this performance hit will extend past build.

I'm worried how much longer Firefox will take to parse a webpage, which will be affected by this change. Perhaps something that uses webkit-gtk won't change much, probably already compiled with PIC.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 4 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum