crt: Need a position-independent CRT for PIE

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

- 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
- 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
  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. 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:

      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".

  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. usr/src/lib/crt/ (Diff revision 1)
    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

  1. Thanks Rich, this looks good.

  1. Ship It!
Review request changed

Status: Closed (submitted)