# linker Published articles for linker. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## lld 23 ELF changes DevFeed: [lld 23 ELF changes]() Original publisher: [Read original article]() Published: 2026-09-12T07:00:00Z Content type: release Language: en Sources: [MaskRay]() Topics: [LLVM](), [Git](), [Claude Code]() Tags: [2026](), [compression](), [linker](), [llvm](), [performance](), [release]() ### AI overview This release article summarizes changes in lld/ELF for LLVM 23.1. It reports 141 commits during the development cycle, with substantial performance work including parallelized input-file loading and mark processing, along with linker behavior and compatibility updates. ### Source excerpt LLVM 23.1 has been released. As usual, I maintain lld/ELF and as volunteer work have added some notes to https://github.com/llvm/llvm-project/blob/release/23.x/lld/docs/ReleaseNotes.rst. Like last time, I used Claude Code to summarize git log llvmorg-23-init..origin/release/23.x -- lld/ELF, excluding changes cherry-picked into 22.x (git rev-list llvmorg-23-init..llvmorg-22.1.8 -- lld), and then edited the draft. This was a busy cycle: 141 commits landed in lld/ELF between the branch point (2026-01-13) and 23.1.0-rc1 (2026-07-16), compared with 72 in the 22 cycle. Much of the increase is performance work, which I described in Recent lld/ELF performance improvements. lld 23 is the first release that ships all of it. ## Recent lld/ELF performance improvements DevFeed: [Recent lld/ELF performance improvements]() Original publisher: [Read original article]() Published: 2026-04-12T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Benchmark](), [benchmarking](), [clang](), [Chromium]() Tags: [2026](), [benchmark](), [chromium](), [clang](), [gc](), [gdb](), [improvements](), [linker](), [lld](), [llvm](), [macos](), [overhead](), [patches](), [performance]() ### AI overview This article reports LLVM lld/ELF linker performance improvements from parallelizing link phases and reducing task-runtime overhead. Benchmarks show a 1.34x speedup over lld 22.1 for a Release+Asserts clang link and a 1.09x speedup for a Chromium debug link, while mold and wild remain faster in the comparisons described. ### Source excerpt Updated in 2026-05. Since the LLVM 22 branch was cut, I've landed patches that parallelize more link phases and cut task-runtime overhead. This post compares current main against lld 22.1, mold, and wild. Headline: a Release+Asserts clang --gc-sections link is 1.34x as fast as lld 22.1; Chromium debug with --gdb-index is 1.09x as fast. mold and wild are still ahead -- the last section explains why. ## Call relocation types DevFeed: [Call relocation types]() Original publisher: [Read original article]() Published: 2026-02-16T08:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [x86](), [Assembly](), [Code]() Tags: [architectures](), [binutils](), [function](), [linker](), [static-linking](), [symbols](), [x86](), [x86-64]() ### AI overview This technical post explains why some architectures use separate ELF relocation types for direct function calls and tail calls. It contrasts static linking, where a PC-relative relocation can often be reused, with dynamic linking, where calls may use PLT indirection and therefore require relocation types that encode call semantics. ### Source excerpt Most architectures encode direct branch/call instructions with a PC-relative displacement. This post discusses a specific category of branch relocations: those used for direct function calls and tail calls. Some architectures use two ELF relocation types for a call instruction: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # i386, x86-64 call foo # R_386_PC32, R_X86_64_PC32 call foo@plt # R_386_PLT32, R_X86_64_PLT32 # m68k bsr.l foo # R_68K_PC32 bsr.l foo@plt # R_68K_PLT32 # s390/s390x brasl %r14, foo # R_390_PC32DBL brasl %r14, foo@plt # R_390_PLT32DBL # sparc call foo, 0 # not PIC: R_SPARC_WDISP30 call foo, 0 # gas -KPIC: R_SPARC_WPLT30 ## lld 22 ELF changes DevFeed: [lld 22 ELF changes]() Original publisher: [Read original article]() Published: 2026-02-01T08:00:00Z Content type: release Language: en Sources: [MaskRay]() Topics: [LLVM](), [releases](), [Release notes](), [Claude Code](), [Large Language Model]() Tags: [claude-code](), [compiler](), [git](), [linker](), [lld](), [llm](), [llvm](), [release](), [release-notes](), [releases]() ### AI overview An LLVM lld/ELF maintainer summarizes changes planned for LLVM 22.1, including linker behavior updates, parsing improvements, relocation support, partitioning changes, and architecture-specific fixes. The author also describes using Claude Code to review commits and draft release notes. ### Source excerpt For those unfamiliar, lld is the LLVM linker, supporting PE/COFF, ELF, Mach-O, and WebAssembly ports. These object file formats differ significantly, and each port must follow the conventions of the platform's system linker. As a result, the ports share limited code (diagnostics, memory allocation, etc) and have largely separate reviewer groups. With LLVM 22.1 releasing soon, I've added some notes to the https://github.com/llvm/llvm-project/blob/release/22.x/lld/docs/ReleaseNotes.rst as an lld/ELF maintainer. As usual, I've reviewed almost all the patches not authored by me. For the first time, I used an LLM agent (Claude Code) to help look through commits (git log release/21.x..release/22.x -- lld/ELF) and draft the release notes. Despite my request to only read lld/ELF changes, Claude Code also crafted notes for other ports, which I retained since their release notes had been quite sparse for several releases. Changes back ported to the 21.x release are removed (git log --oneline llvmorg-22-init..llvmorg-21.1.8 -- lld). I'll delve into some of the key changes. ## Long branches in compilers, assemblers, and linkers DevFeed: [Long branches in compilers, assemblers, and linkers]() Original publisher: [Read original article]() Published: 2026-01-25T08:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [toolchain](), [Compiler](), [Assembly]() Tags: [architectures](), [article](), [assembler](), [binutils](), [compilers](), [implementation](), [linker](), [llvm](), [toolchain]() ### AI overview This article explains how compilers, assemblers, and linkers handle branch instructions whose PC-relative targets exceed the supported range. It describes the division of responsibility across toolchain stages and compares branch-range limitations across architectures, including AArch32, AArch64, and LoongArch. ### Source excerpt Branch instructions on most architectures use PC-relative addressing with a limited range. When the target is too far away, the branch becomes "out of range" and requires special handling. Consider a large binary where main() at address 0x10000 calls foo() at address 0x8010000-over 128MiB away. On AArch64, the bl instruction can only reach ±128MiB, so this call cannot be encoded directly. Without proper handling, the linker would fail with an error like "relocation out of range." The toolchain must handle this transparently to produce correct executables. This article explores how compilers, assemblers, and linkers work together to solve the long branch problem. Compiler (IR to assembly): Handles branches within a function that exceed the range of conditional branch instructions Assembler (assembly to relocatable file): Handles branches within a section where the distance is known at assembly time Linker: Handles cross-section and cross-object branches discovered during final layout ## Remarks on SFrame DevFeed: [Remarks on SFrame]() Original publisher: [Read original article]() Published: 2025-09-28T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [Linux](), [Compiler](), [Optimization](), [x86]() Tags: [compiler](), [linker](), [linux](), [llvm](), [optimization](), [profiling](), [sframe](), [x86-64]() ### AI overview An analysis of SFrame, a stack-walking format for userspace profiling inspired by Linux's ORC unwind format. It examines SFrame's trade-offs against .eh_frame and Windows ARM64 unwind codes, its section layout, versioning, and opportunities to reduce data-structure overhead. ### Source excerpt SFrame is a new stack walking format for userspace profiling, inspired by Linux's in-kernel ORC unwind format. While SFrame eliminates some .eh_frame CIE/FDE overhead, it sacrifices functionality (e.g., personality, LSDA, callee-saved registers) and flexibility, and its stack offsets are less compact than .eh_frame's bytecode-style CFI instructions. In llvm-project executables I've tested on x86-64, .sframe section is 20% larger than .eh_frame. It also remains significantly larger than highly compact schemes like Windows ARM64 unwind codes. SFrame describes three elements for each function: Canonical Frame Address (CFA): The base address for stack frame calculations Return address Frame pointer An .sframe section follows a straightforward layout: Header: Contains metadata and offset information Auxiliary header (optional): Reserved for future extensions Function Descriptor Entries (FDEs): Array describing each function Frame Row Entries (FREs): Arrays of unwinding information per function ## lld 21 ELF changes DevFeed: [lld 21 ELF changes]() Original publisher: [Read original article]() Published: 2025-09-07T07:00:00Z Content type: release Language: en Sources: [MaskRay]() Topics: [LLVM](), [patches](), [toolchain](), [Arm](), [RISC-V](), [TLS (Transport Layer Security)]() Tags: [architecture](), [arm](), [linker](), [llvm](), [optimization](), [patches](), [release](), [riscv](), [tls]() ### AI overview An overview of selected changes in the ELF linker lld included with LLVM 21.1, covering symbol handling, garbage-collection diagnostics, ThinLTO, linker scripts, architecture-specific features, branch relaxation, TLS optimizations, and bug fixes. ### Source excerpt LLVM 21.1 have been released. As usual, I maintain lld/ELF and have added some notes to https://github.com/llvm/llvm-project/blob/release/21.x/lld/docs/ReleaseNotes.rst. I've meticulously reviewed nearly all the patches that are not authored by me. I'll delve into some of the key changes. ## The Underrust: Rust's assembly output DevFeed: [The Underrust: Rust's assembly output]() Original publisher: [Read original article]() Author: Graham King Published: 2022-08-31T07:00:00Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Rust](), [Assembly](), [Compiler](), [LLVM](), [cpu](), [Linux](), [linker]() Tags: [assembly](), [compiler](), [cpu](), [linker](), [linux](), [llvm](), [optimize](), [performance](), [rust](), [software](), [underrust]() ### AI overview This article introduces the Underrust series, which examines Rust programs through their generated assembly. It explains a repeatable setup using Rust on Linux with an Intel processor, a stripped-down program, LLVM optimizations, a custom entry point, and release builds to make assembly easier to inspect. ### Source excerpt Assembly: In all the world of the programmer, there is no more important output. ## 10 LDFLAGS I Love DevFeed: [10 LDFLAGS I Love]() Original publisher: [Read original article]() Published: 2016-07-18T20:00:14Z Content type: article Language: en Sources: [Jessie Frazelle]() Topics: [linker](), [Programming]() Tags: [binaries](), [debug](), [linker](), [map](), [symbols]() ### AI overview A sarcastic programming article presents ten favorite LDFLAGS and briefly explains their linker behavior, including static linking, symbol export, archive inclusion, link-map generation, symbol stripping, tracing, library search restrictions, and unresolved symbols. ### Source excerpt Hello and welcome to what will become the most sarcastic post on my blog. This is going to be a series of "buzzfeed" style programming articles and after this post I very happily pass the baton to Filippo Valsorda to continue. And I urge you to write your own as well. @jessfraz "We asked Jess for her top 10 ldflags; you won't believe what happened next" -- adg (@enneff) July 17, 2016 So here they are: -static I would be an embarassment to myself if I didn't start with the flag that tells the linker to not link against shared libraries. This is the best flag. STATIC BINARIES FTW. --export-dynamic This flag tells the linker to add all the symbols to the dynamic symbol table. This is especially important if you want to do "The Macgyver of Dlopening" and dlopen yourself. --whole-archive This is another flag that comes in handy when you want to dlopen yourself. See most linkers will only take into account the things it knows it needs. But with this flag, you tell it "YOLO, I want it all" so that later you can dlopen yourself with that symbol that was never actually used until runtime. FUN! --no-whole-archive This flag un-sets the --whole-archive flag which is nice for when you only want the whole archive of one library but not all the others you are linking to. --print-map This flag is just dope. It prints a link map to stdout. This gives you information about object files, common symbols, and the values assigned to symbols. --strip-all This flag strips all the symbol information from the artifact produced. If say you are a few KB/MB off from your binary fitting on a floppy disk, this flag is your friend. --strip-debug This flag is very similar to --strip-all except it only strips the debug symbol information. This all really depends on how much you need to shave off to fit that binary on a floppy disk. --trace This flag is great for debugging. It prints the names of the input files as ld processes them. -nostdlib This flag forces the linker to only search the libraries y ## Learning assembler on Linux DevFeed: [Learning assembler on Linux]() Original publisher: [Read original article]() Author: Graham King Published: 2014-08-23T03:49:14Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [Assembly](), [Linux](), [Programming](), [x86](), [Code]() Tags: [assembler](), [assembly](), [linker](), [linux](), [linux-kernel](), [programming](), [software](), [x86](), [x86-64]() ### AI overview A programmer documents learning assembly on Linux, comparing AT&T and Intel syntax, assemblers, and 32-bit versus 64-bit targets. The article also explains entry points, linker behavior, system calls, and explicit program termination. ### Source excerpt "Diving into the nitty-gritty of assembly: A programmer's adventure!" ## Unity - Failing Store Submission or WACK with Windows 8 Games DevFeed: [Unity - Failing Store Submission or WACK with Windows 8 Games]() Original publisher: [Read original article]() Author: Adam Tuliper (noreply@blogger.com) Published: 2013-10-27T08:01:00Z Content type: tutorial Language: en Sources: [Adam Tuliper]() Topics: [Unity](), [Windows](), [Development](), [Visual Studio](), [test](), [debug](), [vulnerability](), [linker]() Tags: [debug](), [developer](), [games](), [linker](), [release](), [unity](), [visual-studio](), [vulnerability](), [windows]() ### AI overview A developer describes resolving a rejected Windows 8 Store submission for a Unity game. The Windows Application Certification Kit reported binary protection and debug-configuration failures; selecting a Release build in Visual Studio and recompiling addressed the debug-build issue, while the report also identified required linker options. ### Source excerpt I was helping a developer in porting their game to work on Windows 8. They had done the export in Unity (Build Settings - Windows Store Apps, as shown below) and uploaded the package to the Windows Store. So far, pretty easy and straightforward process. The store review process rejected the application. I asked the to run WACK locally (Windows Application Certification Kit) that is on any system that is doing Windows 8 development. To run it, simply hit the windows key on your keyboard and type cert, it should be in the results. It's also available at http://msdn.microsoft.com/en-us/windows/apps/bg127575.aspx WACK failed and gave the following issues in the report. I'm including everything for those that find this via a search engine trying to solve their own issues. However the fix was quite simple. In Visual Studio ensure you are doing a RELEASE build. The problem here is when a Debug build is selected in Visual Studio, the debug version of the Unity libraries are referenced instead of the Release version. Debug libraries have optimizations removed and a bunch of diagnostic information included in them (for ex information to link in PDB files for debug information). Simply select "Release" in Visual Studio for build settings, recompile via the build menu or control-shift-b, which is also the same hotkey for build in Unity and voila! Failing application details: Binary analyzer Error Found: The binary analyzer test detected the following errors: File \AppX\BridgeInterface.dll has failed the WXCheck check. File \AppX\BridgeInterface.dll has failed the SafeSEHCheck check. File \AppX\Catch Falling Stuff.exe has failed the WXCheck check. File \AppX\Catch Falling Stuff.exe has failed the SafeSEHCheck check. File \AppX\UnityEngineDelegates.dll has failed the WXCheck check. File \AppX\UnityEngineDelegates.dll has failed the SafeSEHCheck check. Impact if not fixed: If the app doesn't use the available Windows protections, it can increase the vulnerability of customer's com ## Exploring RarVM Bytecode and Runtime Filters for Improving Compression DevFeed: [Exploring RarVM Bytecode and Runtime Filters for Improving Compression]() Original publisher: [Read original article]() Author: taviso (noreply@blogger.com) Published: 2012-09-28T22:40:00Z Content type: article Language: en Sources: [Tavis Ormandy]() Topics: [Programming](), [Code](), [Compression](), [Assembly](), [x86](), [toolchain](), [linker](), [GitHub]() Tags: [assembly](), [code](), [compression](), [documentation](), [github](), [linker](), [programming](), [toolchain](), [x86]() ### AI overview An exploration of RAR's x86-like RarVM, whose reversible runtime filters increase redundancy in input data to improve compression. The author describes a toolchain and example programs for writing RarVM filters. ### Source excerpt Believe it or not, RAR files can contain bytecode for a simple x86-like virtual machine called the RarVM. This is designed to provide filters (preprocessors) to perform some reversible transformation on input data to increase redundancy, and thus improve compression. For example, one filter (likely inspired by LZX, an earlier scheme with a similar feature) is called "Intel E8 preprocessing", which is designed to increase redundancy in x86 code. If you imagine a program like this: mov foo, bar cmp bar, baz push foo call write push bar call write The two calls are relative to the branch location, so there will be two different encodings of the same instruction. At compress time, we can translate them to absolute addresses. This way, the same instruction appears twice, and can therefore be compressed much more efficiently. When the archive is decompressed, this transformation can be reversed to restore the original. WinRAR includes around a dozen standard filters that improve compression of several common inputs, but surprisingly also allows new filters to be defined at runtime by archives! As far as I'm aware, no tool exists to explore this functionality. This is just too tempting to play with, so I've written some. So far, I have a RAR toolchain working, as well as some documentation on how to write programs. You can checkout the code and some example programs on github, https://github.com/taviso/rarvmtools. $ cat helloworld.rs #include #include ; vim: syntax=fasm ; Test RAR assembly file. _start: ; Install our message in the output buffer mov r3, #0x1000 ; Output buffer. mov [r3+#0], #0x6c6c6548 ; 'lleH' mov [r3+#4], #0x57202c6f ; 'W ,o' mov [r3+#8], #0x646c726f ; 'dlro' mov [r3+#12], #0x00000a21 ; '!\n' mov [VMADDR_NEWBLOCKPOS], r3 ; Pointer mov [VMADDR_NEWBLOCKSIZE], #14 ; Size call $_success $ make helloworld.rar cpp -I../stdlib < helloworld.rs > helloworld.ri ../raras -o helloworld.ro helloworld.ri ../rarld helloworld.ro > helloworld.ra ## ReactOS Newsletter 71: USB stack development and build tool fixes DevFeed: [ReactOS Newsletter 71: USB stack development and build tool fixes]() Original publisher: [Read original article]() Published: 2010-04-23T00:00:00Z Content type: news Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [USB](), [gcc](), [linker](), [Windows](), [Xen]() Tags: [build-tools](), [c-plus-plus](), [compiler](), [free](), [gcc](), [linker](), [open-source](), [os](), [react](), [reactos](), [usb](), [win32](), [winapi]() ### AI overview This ReactOS newsletter reports work on lower-level USB stack components, including a basic usbehci driver tested in Windows XP, and describes GCC, linker, library, and binutils fixes needed for interoperability with Microsoft's C/C++ compiler. ### Source excerpt NT USB Stack Pre-Vista, the USB architecture started with a very low level usbport driver. This driver was the one that created device objects for each USB controller and received I/O Request Packets (IRP). Depending on which USB standard the controllers were for, usbport would call into one of three helper drivers, usbehci, usbohci, and usbuhci. The one actually sending those IRPs was usbhub, and these components constitute the lower levels of the USB stack.