<feed xmlns="http://www.w3.org/2005/Atom"> <id>/</id><title>Low-Level Club</title><subtitle>A FOSS systems blog that focus on embedded systems, Microarchitecture, hardware/software, Verilog, validations, and more.</subtitle> <updated>2026-06-17T19:14:07+00:00</updated> <author> <name>Daniel</name> <uri>/</uri> </author><link rel="self" type="application/atom+xml" href="/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Daniel </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Decompiler Construction: Chapter 9 - Coverage-Guided Fuzzing for Validation and Symbolic Execution</title><link href="/posts/chapter-9/" rel="alternate" type="text/html" title="Decompiler Construction: Chapter 9 - Coverage-Guided Fuzzing for Validation and Symbolic Execution" /><published>2026-05-27T16:00:00+00:00</published> <updated>2026-06-17T19:13:20+00:00</updated> <id>/posts/chapter-9/</id> <content type="text/html" src="/posts/chapter-9/" /> <author> <name>Daniel</name> </author> <category term="Decompiler Construction" /> <category term="Chapter 9 - Coverage-Guided Fuzzing for Validation and Symbolic Execution" /> <summary>Assume all your passes are wrong and have never been proven. The idea is to find failures before someone else does, pass fail at the smallest scale first, and snowball into catastrophic behaviours. Some of these include: Mis-reconstructed control flow Incorrect SSA transformations Undefined behavior misinterpretation Incorrect type recovery Silent arithmetic mismatches Standard t...</summary> </entry> <entry><title>Decompiler Construction: Chapter 8 - Designing Safe Optimization Passes</title><link href="/posts/chapter-8/" rel="alternate" type="text/html" title="Decompiler Construction: Chapter 8 - Designing Safe Optimization Passes" /><published>2026-05-27T16:00:00+00:00</published> <updated>2026-06-02T01:24:06+00:00</updated> <id>/posts/chapter-8/</id> <content type="text/html" src="/posts/chapter-8/" /> <author> <name>Daniel</name> </author> <category term="Decompiler Construction" /> <category term="Chapter 8 - Designing Safe Optimization Passes" /> <summary>Optimization passes transform IR into a simpler, more canonical form without altering program semantics. The core philosophy of a pass is to reduce code and expressions to their minimal canonical form, applying transformations iteratively until a fixed point is reached (i.e., no further changes occur). Any incorrect or unsafe transformations will corrupt the output. Every pass must be determini...</summary> </entry> <entry><title>Decompiler Construction: Chapter 7 - Reconstructing Control Flow using Graph Theory, SSA, and Types</title><link href="/posts/chapter-7/" rel="alternate" type="text/html" title="Decompiler Construction: Chapter 7 - Reconstructing Control Flow using Graph Theory, SSA, and Types" /><published>2026-05-27T16:00:00+00:00</published> <updated>2026-06-17T19:13:20+00:00</updated> <id>/posts/chapter-7/</id> <content type="text/html" src="/posts/chapter-7/" /> <author> <name>Daniel</name> </author> <category term="Decompiler Construction" /> <category term="Chapter 7 - Reconstructing Control Flow using Graph Theory" /> <category term="SSA" /> <category term="and Types" /> <summary>Now that the IR is ready to go, we can begin transforming it into readable code. Pass Methodology This chapter and the preceding chapters (up to the final one) define transformation passes. Each pass operates on the IR and may modify it. Passes must be applied iteratively until a fixed point is reached i.e., until no pass produces any changes. After any modification, all passes must be r...</summary> </entry> <entry><title>Decompiler Construction: Chapter 6 - IR Semantics Edge Cases, Undefined Behavior, and Special Handling</title><link href="/posts/chapter-6/" rel="alternate" type="text/html" title="Decompiler Construction: Chapter 6 - IR Semantics Edge Cases, Undefined Behavior, and Special Handling" /><published>2026-05-27T16:00:00+00:00</published> <updated>2026-06-17T19:13:20+00:00</updated> <id>/posts/chapter-6/</id> <content type="text/html" src="/posts/chapter-6/" /> <author> <name>Daniel</name> </author> <category term="Decompiler Construction" /> <category term="Chapter 6 - IR Semantics Edge Cases" /> <category term="Undefined Behavior" /> <category term="and Special Handling" /> <summary>Edge-Cases Sometimes your IL will contain abstract functions that do not map 1:1 to the IR. These should be handled by flagging them while remaining as descriptive as possible. The best approach, without bloating IR nodes with extra fields, is to encode the behavior through function arguments. Ask the following questions about each function: Does it modify any registers? If yes, pass...</summary> </entry> <entry><title>Decompiler Construction: Chapter 5 - Lifting IL to IR</title><link href="/posts/chapter-5/" rel="alternate" type="text/html" title="Decompiler Construction: Chapter 5 - Lifting IL to IR" /><published>2026-05-27T16:00:00+00:00</published> <updated>2026-05-27T23:23:55+00:00</updated> <id>/posts/chapter-5/</id> <content type="text/html" src="/posts/chapter-5/" /> <author> <name>Daniel</name> </author> <category term="Decompiler Construction" /> <category term="Chapter 5 - Lifting IL to IR" /> <summary>The purpose of the IL is to simplify lifting from different architectures into the IR. An added benefit is that it enables a multi-architecture decompiler: only one lifting pipeline is needed to support targets such as ARM and x86. Because lifting is the first stage in the IR pipeline, no optimizations should be used at this level. If the IL and IR are designed correctly, the IL should be abl...</summary> </entry> </feed>
