# binutils

Published articles for binutils.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Call relocation types

DevFeed: [Call relocation types](<https://devfeed.tech/articles/call-relocation-types-31126.md>)

Original publisher: [Read original article](<https://maskray.me/blog/call-relocation-types>)

Published: 2026-02-16T08:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [x86](<https://devfeed.tech/topics/x86.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [binutils](<https://devfeed.tech/tags/binutils.md>), [function](<https://devfeed.tech/tags/function.md>), [linker](<https://devfeed.tech/tags/linker.md>), [static-linking](<https://devfeed.tech/tags/static-linking.md>), [symbols](<https://devfeed.tech/tags/symbols.md>), [x86](<https://devfeed.tech/tags/x86.md>), [x86-64](<https://devfeed.tech/tags/x86-64.md>)

### 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

## Long branches in compilers, assemblers, and linkers

DevFeed: [Long branches in compilers, assemblers, and linkers](<https://devfeed.tech/articles/long-branches-in-compilers-assemblers-and-linkers-31133.md>)

Original publisher: [Read original article](<https://maskray.me/blog/long-branches-in-compilers-assemblers-and-linkers>)

Published: 2026-01-25T08:00:00Z

Content type: article

Language: en

Sources: [MaskRay](<https://devfeed.tech/sources/maskray.md>)

Topics: [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Assembly](<https://devfeed.tech/topics/assembly.md>)

Tags: [architectures](<https://devfeed.tech/tags/architectures.md>), [article](<https://devfeed.tech/tags/article.md>), [assembler](<https://devfeed.tech/tags/assembler.md>), [binutils](<https://devfeed.tech/tags/binutils.md>), [compilers](<https://devfeed.tech/tags/compilers.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [linker](<https://devfeed.tech/tags/linker.md>), [llvm](<https://devfeed.tech/tags/llvm.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>)

### 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

## ReactOS Build Environment 2.2 released

DevFeed: [ReactOS Build Environment 2.2 released](<https://devfeed.tech/articles/reactos-build-environment-2-2-released-33233.md>)

Original publisher: [Read original article](<https://reactos.org/project-news/rosbe-22-released/>)

Published: 2020-05-01T00:00:00Z

Content type: release

Language: en

Sources: [Front Page on ReactOS Website](<https://devfeed.tech/sources/front-page-on-reactos-website.md>)

Topics: [ReactOS](<https://devfeed.tech/topics/reactos.md>), [build tools](<https://devfeed.tech/topics/build-tools.md>), [gcc](<https://devfeed.tech/topics/gcc.md>), [toolchain](<https://devfeed.tech/topics/toolchain.md>), [Parser](<https://devfeed.tech/topics/parser.md>), [C](<https://devfeed.tech/topics/c.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [CMake](<https://devfeed.tech/topics/cmake.md>), [Visual Studio](<https://devfeed.tech/topics/visual-studio.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [macOS](<https://devfeed.tech/topics/macos.md>), [Windows](<https://devfeed.tech/topics/windows.md>)

Tags: [binutils](<https://devfeed.tech/tags/binutils.md>), [build](<https://devfeed.tech/tags/build.md>), [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [cmake](<https://devfeed.tech/tags/cmake.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [free](<https://devfeed.tech/tags/free.md>), [gcc](<https://devfeed.tech/tags/gcc.md>), [linux](<https://devfeed.tech/tags/linux.md>), [macos](<https://devfeed.tech/tags/macos.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [os](<https://devfeed.tech/tags/os.md>), [react](<https://devfeed.tech/tags/react.md>), [reactos](<https://devfeed.tech/tags/reactos.md>), [toolchain](<https://devfeed.tech/tags/toolchain.md>), [visual-studio](<https://devfeed.tech/tags/visual-studio.md>), [win32](<https://devfeed.tech/tags/win32.md>), [winapi](<https://devfeed.tech/tags/winapi.md>)

### AI overview

ReactOS Build Environment 2.2 upgrades the project's compiler and build tools, replacing GCC 4.7.2 with GCC 8.4.0. The release improves diagnostics, adds support for newer C and C++ standards, includes Bison and Flex, and updates the remaining toolchain.

### Source excerpt

The ReactOS Build Environment (RosBE), our curated set of compilers and build tools, has just received a major upgrade. After more than 7 years of using the same and now ancient GCC 4.7.2, ReactOS is finally going to be built with the help of a modern compiler (GCC 8.4.0). Among other things, the new version better detects programming mistakes like improperly sized buffers, and comes with improved error messages to pinpoint such mistakes to the corresponding position in code.