--- title: Seriously, what is the large code-model even for? description: An investigation into a fundamental limitation of the x86-64 large code model (`-mcmodel=large`): while it successfully handles binaries with >2GiB of ordinary... canonical: https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Seriously, what is the large code-model even for? | daily.dev og:description: An investigation into a fundamental limitation of the x86-64 large code model (`-mcmodel=large`): while it successfully handles binaries with >2GiB of ordinary... og:url: https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8 og:image: https://api.daily.dev/og/posts/gbaaDlWy8.png og:image:alt: Seriously, what is the large code-model even for? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Seriously, what is the large code-model even for? **[Farid Zakaria’s Blog](https://daily.dev/sources/fzakaria)** · 10 min read · 1 upvotes · 0 comments ## Summary An investigation into a fundamental limitation of the x86-64 large code model (`-mcmodel=large`): while it successfully handles binaries with >2GiB of ordinary data (`.bss`), it completely fails for thread-local storage (`.tbss`). The root cause is that every TLS access model (local-exec, initial-exec, general-dynamic) uses 32-bit relocation fields by construction — the x86-64 psABI never defined a large-model TLS code sequence using 64-bit immediates. This is not a GCC or LLVM bug; it's a gap in the ABI specification itself. The author demonstrates the failure with reproducible test cases, explains why `TPOFF64` exists but can't be used in code sequences, and points to an ongoing RFC in the x86-64-abi group and an LLVM Massive Binaries working group aimed at fixing this. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does gcc's -mcmodel=large fail with a relocation truncated error for thread-local storage variables? Every thread-local storage access model (local-exec, initial-exec, general-dynamic, local-dynamic) emits a 32-bit relocation such as R_X86_64_TPOFF32 or R_X86_64_GOTTPOFF, regardless of the code model in use. This happens because the instruction fields these relocations patch, like an add $imm32 immediate, are only 32 bits wide in the x86-64 instruction encoding, so accesses to thread-locals beyond a 2 to 4GiB offset overflow even under -mcmodel=large. _daily.dev surfaces deep toolchain internals like this for engineers debugging linker relocation failures in massive binaries._ ### Is the TLS relocation overflow with -mcmodel=large a bug in gcc or clang? No, it is a gap in the x86-64 psABI specification itself, not a compiler bug. The ABI never defined a large-model TLS access sequence that uses a 64-bit immediate like movabs $x@tpoff, so no toolchain can emit code the specification doesn't describe; TPOFF64 and DTPOFF64 only ever appear patching GOT slot data, never as instruction immediates in generated code. _engineers hitting the same wall in massive-binary work can follow ABI-level fixes like this via daily.dev._ ### How can I construct a test binary larger than 2GiB to reproduce relocation overflow errors? Generate uninitialized global arrays in C, since they land in .bss, a NOBITS section that occupies virtual address space but zero bytes on disk, letting a few thousand 1MiB arrays produce gigabytes of address space almost for free. A Python script can emit thousands of 1MiB char arrays plus a function touching each one to force one relocation per array, producing a small object file that still represents gigabytes of address space. _developers reproducing linker edge cases at scale can track practical techniques like this through daily.dev._ ## Similar posts on daily.dev - [Does anyone actually use the large code-model?](https://daily.dev/posts/does-anyone-actually-use-the-large-code-model--kakobvx3p) · Farid Zakaria’s Blog · 0 upvotes · 0 comments - [Huge binaries](https://daily.dev/posts/huge-binaries-wnxpejcac) · Farid Zakaria’s Blog · 0 upvotes · 0 comments - [Huge binaries: papercuts and limits](https://daily.dev/posts/huge-binaries-papercuts-and-limits-zza8ns6n8) · Farid Zakaria’s Blog · 0 upvotes · 0 comments - [The scourge of x86 emulation](https://daily.dev/posts/the-scourge-of-x86-emulation-dcwg2dhgw) · Lobsters · 0 upvotes · 0 comments --- Tags: [#compiler](https://daily.dev/tags/compiler) [View this post on daily.dev](https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Seriously, what is the large code-model even for?","url":"https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8"},"datePublished":"2026-07-27T04:22:35.156Z","dateModified":"2026-09-13T20:31:22.216Z","description":"An investigation into a fundamental limitation of the x86-64 large code model (`-mcmodel=large`): while it successfully handles binaries with >2GiB of ordinary...","image":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","thumbnailUrl":"https://media.daily.dev/image/upload/s--58gMhC4P--/f_auto/v1722860399/public/Placeholder%2012","isAccessibleForFree":true,"articleSection":"Farid Zakaria’s Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Farid Zakaria’s Blog","logo":"https://media.daily.dev/image/upload/s--YqqvRt90--/f_auto/v1723789280/logos/fzakaria","url":"https://daily.dev/sources/fzakaria"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"compiler","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Farid Zakaria’s Blog","item":"https://daily.dev/sources/fzakaria"},{"@type":"ListItem","position":3,"name":"Seriously, what is the large code-model even for?"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/seriously-what-is-the-large-code-model-even-for--gbaadlwy8#faq","mainEntity":[{"@type":"Question","name":"Why does gcc's -mcmodel=large fail with a relocation truncated error for thread-local storage variables?","acceptedAnswer":{"@type":"Answer","text":"Every thread-local storage access model (local-exec, initial-exec, general-dynamic, local-dynamic) emits a 32-bit relocation such as R_X86_64_TPOFF32 or R_X86_64_GOTTPOFF, regardless of the code model in use. This happens because the instruction fields these relocations patch, like an add $imm32 immediate, are only 32 bits wide in the x86-64 instruction encoding, so accesses to thread-locals beyond a 2 to 4GiB offset overflow even under -mcmodel=large. daily.dev surfaces deep toolchain internals like this for engineers debugging linker relocation failures in massive binaries."}},{"@type":"Question","name":"Is the TLS relocation overflow with -mcmodel=large a bug in gcc or clang?","acceptedAnswer":{"@type":"Answer","text":"No, it is a gap in the x86-64 psABI specification itself, not a compiler bug. The ABI never defined a large-model TLS access sequence that uses a 64-bit immediate like movabs $x@tpoff, so no toolchain can emit code the specification doesn't describe; TPOFF64 and DTPOFF64 only ever appear patching GOT slot data, never as instruction immediates in generated code. engineers hitting the same wall in massive-binary work can follow ABI-level fixes like this via daily.dev."}},{"@type":"Question","name":"How can I construct a test binary larger than 2GiB to reproduce relocation overflow errors?","acceptedAnswer":{"@type":"Answer","text":"Generate uninitialized global arrays in C, since they land in .bss, a NOBITS section that occupies virtual address space but zero bytes on disk, letting a few thousand 1MiB arrays produce gigabytes of address space almost for free. A Python script can emit thousands of 1MiB char arrays plus a function touching each one to force one relocation per array, producing a small object file that still represents gigabytes of address space. developers reproducing linker edge cases at scale can track practical techniques like this through daily.dev."}}]} ```