FS#46019 - [pacman] -fstack-check fails some 32 bit asm compiles
            Attached to Project:
            Arch Linux
            
Opened by Johannes Dewender (JonnyJD) - Wednesday, 19 August 2015, 10:45 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 02 October 2015, 11:48 GMT
          Opened by Johannes Dewender (JonnyJD) - Wednesday, 19 August 2015, 10:45 GMT
Last edited by Evangelos Foutras (foutrelis) - Friday, 02 October 2015, 11:48 GMT
| 
 | Details
                    pacman 4.1.2-3 includes -fstack-check in the default
                    makepkg.conf CFLAGS. (currently in [testing]) This does break some 32 bit compilation including asm code since it "effectively" costs 1 register (see gcc bug below). I only tested compiling 32 bit packages on a 64 bit system. This effect is probably the same on actual i686, I guess. The package lib32-libx264 disables PIC as a workaround for this issue: https://aur.archlinux.org/packages/lib32-libx264 I reported the problem to gcc as this is possibly something that shouldn't happen or be done differently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265 I also reported the same bug to hardening-wrapper, since that package was the first to include -fstack-check in (non-testing) Arch Linux: https://github.com/thestinger/hardening-wrapper/issues/6 And because the problem affects x264 I also reported it there: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67265 I am not to judge who needs to do what and what needs to happen and when, but I wanted to inform that this flag is not without problems currently. | 
              This task depends upon
              
              
            
            
          
            Closed by  Evangelos Foutras (foutrelis)
Friday, 02 October 2015, 11:48 GMT
Reason for closing: Fixed
Additional comments about closing: pacman 4.2.1-4
          
        Friday, 02 October 2015, 11:48 GMT
Reason for closing: Fixed
Additional comments about closing: pacman 4.2.1-4
 Comment by Allan McRae (Allan) -
            Wednesday, 19 August 2015, 11:03 GMT
            
            Comment by Allan McRae (Allan) -
            Wednesday, 19 August 2015, 11:03 GMT
          
           
          
              So gcc is reserving a register for this? That will be a missive
              performance issue on i686...
            
           Comment by
            Daniel Micay (thestinger) -
            Wednesday, 19 August 2015, 17:38 GMT
            
            Comment by
            Daniel Micay (thestinger) -
            Wednesday, 19 August 2015, 17:38 GMT
          
           
          
              I don't think that's why it's breaking. It makes a register
              unavailable for use by inline assembly in the functions where it
              needs to insert a write, but that doesn't mean it's reserved from
              C code.
            
          