Announcement

Collapse
No announcement yet.

Linux 4.6 Will Try To Make It Easier To Find Assembly Code Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 4.6 Will Try To Make It Easier To Find Assembly Code Bugs

    Phoronix: Linux 4.6 Will Try To Make It Easier To Find Assembly Code Bugs

    Linus Torvalds has honored the request to land the "objtool" stack frame validation support for the Linux 4.6 kernel...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Throw out as much old architecture-specific Assembly code and port it to architecture-independent, portable C code instead.

    Comment


    • #3
      Originally posted by uid313 View Post
      Throw out as much old architecture-specific Assembly code and port it to architecture-independent, portable C code instead.
      I honestly don't even know what all that ASM does. I mean, the only things that come to mind for me are boot sequence, interrupt preamble/register saving, and page table remapping/TLB invalidation, all of which are architecture-dependent.

      Comment


      • #4
        Originally posted by CrystalGamma View Post

        I honestly don't even know what all that ASM does. I mean, the only things that come to mind for me are boot sequence, interrupt preamble/register saving, and page table remapping/TLB invalidation, all of which are architecture-dependent.

        Lock implementations would also come to mind.

        And technically speaking quite a bit of this could be hidden in commonly used preprocessor macros, so it might be more common than one would assume.

        Anyway, first step to port the kernel to a JVM [as code verification of that ilk is typical for Java]

        Comment


        • #5
          Originally posted by yacc143 View Post


          Lock implementations would also come to mind.
          But locks probably only need atomics, which are standardised in C11.

          Comment


          • #6
            But locks probably only need atomics, which are standardised in C11.
            That's cute and all, but the kernel supports gcc 3.2 minimum, released in 2003. That's not going to have C11 support, and even if they wanted to limit compilers to recent gcc/llvm only, would they trust the code it generates vs hand-tuned and perfected over-the-years results?

            Comment


            • #7
              Originally posted by yacc143 View Post
              Anyway, first step to port the kernel to a JVM [as code verification of that ilk is typical for Java]
              Please do not say that ever again

              Just jocking, but I cannot think of something worse than a kernel writtern in Java

              Comment


              • #8
                Originally posted by devtry View Post

                Please do not say that ever again

                Just jocking, but I cannot think of something worse than a kernel writtern in Java
                I'm sure this wouldn't work with the kernel, but people have tried compiling C to java byte code. Certainly would be an interesting project to try at least. For example: https://github.com/davidar/lljvm

                Comment


                • #9
                  Originally posted by devtry View Post

                  Please do not say that ever again

                  Just jocking, but I cannot think of something worse than a kernel writtern in Java
                  A kernel written in perl.

                  Comment


                  • #10
                    Originally posted by smitty3268 View Post

                    A kernel written in perl.
                    To be fair, that's not what perl is intended for. It saved me from having to interpret regular expressions.

                    Comment

                    Working...
                    X