DROB (Dynamic Rewriter and Optimizer of Binary code)
> This library implements application-guided rewriting of binary functions at runtime. Binary functions can be optimized and specialized based on runtime information. In contrast to transparent binary optimization, only selected binary functions are rewritten. No metadata (e.g. debug information) is required.
Yaegi is Another Elegant Go Interpreter
> Despite being static and strongly typed, Go feels like a dynamic language. The standard library even provides the Go parser used by the compiler and the reflection system to interact dynamically with the runtime. So why not just take the last logical step and finally build a complete Go interpreter?
> Programming languages for high level scripting and for low level implementation are usually different. This time, with Go, we have an opportunity to unify both. Imagine all the C/C++/Java fast libraries for Python being written in Python instead. That’s what Yaegi is for Go (or, the reverse). No burden due to syntax switch, no need to rewrite or modify slow code to make it fast, and full access to goroutines, channels, type safety, etc. at script level.
Models of Generics and Metaprogramming: Go, Rust, Swift, D and More
> In some domains of programming it’s common to want to write a data structure or algorithm that can work with elements of many different types, such as a generic list or a sorting algorithm that only needs a comparison function. Different programming languages have come up with all sorts of solutions to this problem: From just pointing people to existing general features that can be useful for the purpose (e.g C, Go) to generics systems so powerful they become Turing-complete (e.g. Rust, C++). In this post I’m going to take you on a tour of the generics systems in many different languages and how they are implemented. I’ll start from how languages without a special generics system like C solve the problem and then I’ll show how gradually adding extensions in different directions leads to the systems found in other languages.
Design and Evolution of C-Reduce
> Since 2008, my colleagues and I have developed and maintained C-Reduce, a tool for programmatically reducing the size of C and C++ files that trigger compiler bugs. C-Reduce also usually does a credible job reducing test cases in languages other than C and C++; we’ll return to that later.
Part 2: https://blog.regehr.org/archives/1679
Announcing code annotations for SourceHut
> A lot of design thought went into this feature, but I knew one thing from the outset: I wanted to make a generic system that users could use to annotate their source code in any manner they chose. My friend Andrew Kelley (of Zig fame) once expressed to me his frustration with GitHub’s refusal to implement syntax highlighting for “small” languages, citing a shortage of manpower. It’s for this reason that it’s important to me that SourceHut’s open-source platform allows users large and small to volunteer to build the perfect integration for their needs - I don’t scale alone.
Go compiler internals: adding a new statement to Go
> This is the first post in a two-part series that takes a tutorial-based approach to exploring the Go compiler. The compiler is large and would require a small book to describe properly, so the idea of these posts is to provide a quick depth-first dive instead. I plan to write more descriptive posts on specific areas of the compiler in the future.
Open Dylan 2019.1 Released
> Dylan is a multi-paradigm functional and object-oriented programming language. It is dynamic while providing a programming model designed to support efficient machine code generation, including fine-grained control over dynamic and static behaviors.
> Although there are many changes in this release, the main highlight is that the LLVM back-end, which uses LLVM 7.x or later for code generation, is now full-featured and mature on i386 and x86_64 Linux, FreeBSD, and macOS platforms.
Defeating Racket’s separate compilation guarantee
> Being a self-described programming-language programming language is an ambitious goal. To preserve predictability while permitting linguistic extension, Racket comes equipped with a module system carefully designed to accommodate composable and compilable macros. One of the module system’s foundational properties is its separate compilation guarantee, which imposes strong, unbreakable limits on the extent of compile-time side-effects. It is essential for preserving static guarantees in a world where compiling a module can execute arbitrary code, and despite numerous unsafe trapdoors that have crept into Racket since its birth as PLT Scheme, none have ever given the programmer the ability to cheat it.
> Yet today, in this blog post, we’re going to do exactly that.
Fast compilers for fast programs
> When you have a small team that write tests and a compiler that is on the boundary of interactive speed, compiler speed dominates performance.
The Go low-level calling convention on x86-64
> This article analyzes how the Go compiler generates code for function calls, argument passing and exception handling on x86-64 targets.
Tons of information. Very thorough.
Why are my Go executable files so large?
> I built some tooling to extract details about the contents of a Go executable file, and a small D3 application to visualize this information interactively as zoomable tree maps.
I Built a Lisp Compiler
> Malcc is an incremental and ahead-of-time lisp compiler written in C.
> This is the story of my progress over the years and what I learned in the process. An alternate title for this post is: “How to Write a Compiler in Ten Years or Less”
Implementing a static stack usage analysis tool
> Stack usage analysis consists of three steps: first, computing the stack usage of every function (subroutine) in the program, then computing the full call graph of the program and finally using these two pieces of information to compute the worst-case stack usage.
Usability improvements in GCC 9
> I work at Red Hat on GCC, the GNU Compiler Collection, and I spent most of the past year making GCC easier to use. Let’s look at C and C++ improvements that will be in the next major release of GCC, GCC 9.
C++ error messages that are slowly approaching useful...
Oneliner-izer: An Exercise in Constrained Coding
> We’ll describe the ideas and implementation behind Oneliner-izer, a “”compiler“” which can convert most Python 2 programs into one line of code. As we discuss how to construct each language feature within this unorthodox constraint, we’ll explore the boundaries of what Python permits and encounter some gems of functional programming – lambda calculus, continuations, and the Y combinator.
WebAssembly Is Not a Stack Machine
> This poses a problem for optimisation.
Vulnerability in compiler leads to perfect stealth backdoor in software
> Formally speaking, the bug in the compiler does not take into account the
“!” (not) operator in context of equal checks.
> In the bogus environment of ml compiler, truth equation of “!” is changed.
> From the same line of code, we have a different logic result.
> Trusting the source code is now an error. The real logic is masked by the bug.
Some of the slides seem a little wonky with overwritten text, but mostly comprehensible.
Cross DSO CFI - LLVM and Android
> Control Flow Integrity is an exploit mitigation that helps raise the cost of writing reliable exploits for memory safety vulnerabilities. There are various CFI schemes available today, and most are quite well documented and understood. One of the important areas where CFI can be improved is protecting indirect calls across DSO (Dynamic Shared Object) boundaries. This is a difficult problem to solve as only the library itself can validate call targets and consumers of the library may be compiled and linked against the library long after it was built. This requires a low level ABI compatability between the caller and the callee. The LLVM project has documented their design for this here. The remainder of this post looks at that design, it’s drawbacks, and then briefly explores how the Android PIE Bionic linker implements it.
Automating data-only attacks through Block Oriented Programming (BOP)
> With the rise of strong control-flow defenses such as Control-Flow Integrity (CFI), attackers will increasingly resort to data-only attacks that can be equally powerful. Earlier research demonstrated that data-only attacks can be as devastating as control-flow hijacking attacks. So far, constructing data-only attacks was cumbersome and required deep manual analysis. We introduce the idea of Block-Oriented Programming (BOP) where, based on a C-like programming language and the help of constraint solving, we automatically synthesize data-only exploits that run arbitrary payloads on host programs.