crt: Need a position-independent CRT for PIE

Review Request #285 — Created Dec. 6, 2016 and submitted

Information
richlowe
illumos-gate
477e605...
Reviewers
general 
- Implement the greatest possible part of the crt1 in C
- Implement SPARC versions of the ASM sections of crt1
- Build crt1 position-independently, minor ASM updates to be position
  independent
- Implement crt1 with the hook expected by modern GCC to support
  profiling, make gcrt1 a symlink for source compatibility (older GCC
  initializes profiling at firsnt use of _mcount if necessary, so
  doesn't need the gcrt)
- Split the CRT out of developer/library/lint into a separate c-runtime package
This is the initial step of a PIE implementation.  I have tested this with the rest of that implementation and (less thoroughly) stand-alone.
  • 0
  • 0
  • 1
  • 0
  • 1
Description From Last Updated
richlowe
marcel
marcel 
  1. Some file moves (like common/sparc/Makefile or usr/src/lib/common/i386/fsr.s) are missing from the webrev.
  2. usr/src/cmd/vi/port/inc.flg (Diff revision 1) 
     
     
     
    Is this empty line needed here?
  3. usr/src/lib/crt/amd64/mach-crt1.s (Diff revision 1) 
     
     
     
    Maybe this 16-byte alignment deserves some comment explaining why it is needed.  Something similar as it is in the i86 code.
    1. As I recall, the ABI mandates it on amd64 (whereas on i386 things are a little less clear-cut).
    2. Yes, this is a requirement of the amd64 psABI. The reason i386 is less clear is that gcc changed from the default SYSV ABI of 4 bytes to 16. So we just helped out by making our parts 16-byte aligned (through the alignments are different).
  4. usr/src/lib/crt/sparc/mach-crt1.s (Diff revision 1) 
     
     
     
    This looks like a small comment alignment issue.
  5. usr/src/lib/crt/sparc/mach-crt1.s (Diff revision 1) 
     
     
     
    What will happen in a case the _start_crt() returns?
    1. Bad things.  But given we call both exit and _exit  That's very very unlikely.  I had asked the SPARC-y illumos folks for an equivalent to hlt, but got no responses.
    2. https://en.wikipedia.org/wiki/HLT_%28x86_instruction%29#Use_in_operating_systems worries me about the hlt usage even on intel (the rong 0 part).

What is used on sparc now?
    3. It drops off the bottom, like I do.
    4. I suggest to add a busy waiting loop there instead.  Even for the intel case.  Something like:
      

      loop:
      
        hlt
      
        jmp loop
    5. The hlt will cause a #gp, if the program hasn't been killed by that, how exactly does spinning in a never-ending loop of #gp's help?
    6. It depends what is worse.  I believe a neverending loop (either with hlt, or without it) is better than "bad things" that could happen if we proceed (but it really depends what exactly is "bad things" :-).
    7. What are the 'bad things' that you're hinting at? Are you trying to refer to the use of hlt outside of ring zero?
    8. No.  I just referred to Rich's answer above.
    9. Falling out of_start would be hard to debug in the case where we didn't  immediately crash. On x86 hlt gets us that. On SPARC you'll need a SPARC hacker, but I'm happy doing what we have done for 30 years or more until then 
      

      (I'm replying from a phone and RB is being crap. If this is unreadable blame it not me)
  6. usr/src/lib/libc/i386/gen/makectxt.c (Diff revision 1) 
     
     
     
    Please remove one "at the".
  7. 
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    8. 




  

 
















 





 

  

   




rm




   

   









  

 



 

  


   

   

    
 
rm


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Thanks for putting this together Rich. Moving a lot of this out of the asm is a big help. I think in general, this looks good. I'm not sure if we may have an ABI problem with Studio or not, but harder to care about that anyways (I don't really know who'd still use Studio as primary).
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 

















  2. 
 
    
  
  
    
  
 
    
  
    
   
    
    
     
      usr/src/lib/crt/Makefile.com
      


       (Diff revision 1)


      
     
    
    
       
   
    
     
    

    
     
    

       
  
    
 
    

   
    
    
    



    
 
    
  
    
   
   
    
    
     
     
     
     
     
    
    Show all issues
   
  
    
 
    

    



    
    Because we're only building an object file, I guess a final $(POST_PROCESS) doesn't make any sense, right?
    
  
    
 
    

 
    
  


    
 
    
 
      

  


    1. 
 
 
      
 
      
  
 
      
 
      
  
      I probably should do it so that mcs -p does the right thing.  Thanks
      
 
      

      2. 


 
    


    

 
    

    3. 




  3. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    4. 




  

 
















 



 

  

   




richlowe




   

   

  

 



 















 





 

  

   




rm




   

   







  

 



 

  


   

   

    
 
rm


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Thanks Rich, this looks good.
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 





 

  

   




kmays




   

   







  

 



 

  


   

   

    
 
kmays


    
   


  

  

  



    




  1. 
 
    
  
    
   
    Ship It!
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    2. 















  2. 
 
    
  
    
   
    
  
    
 
    

 
    
  


    
 
    
 
      

  

 
    


    

 
    

    3. 




  

 
















 



 

  

   




richlowe




   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  






 

  Status:
  

  Closed (submitted)

  
 







 


 










  

 









     

    

   

  

  

   
   Loading...