{"id":274,"date":"2025-11-26T02:02:33","date_gmt":"2025-11-26T02:02:33","guid":{"rendered":"https:\/\/haco.club\/?p=274"},"modified":"2025-11-26T02:02:33","modified_gmt":"2025-11-26T02:02:33","slug":"why-the-load-of-main-by-_start-uses-got-entry-not-adrpadd-pair","status":"publish","type":"post","link":"https:\/\/haco.club\/?p=274","title":{"rendered":"Why the load of main by _start uses got entry, not adrp+add pair?"},"content":{"rendered":"\n

The _start<\/code> function uses a Global Offset Table (GOT) entry to load the address of main<\/code> primarily because _start<\/code> is defined in a pre-compiled object file (typically Scrt1.o<\/code>) that was built with Position-Independent Code (PIC) enabled.<\/strong><\/p>\n\n\n\n

Here is the detailed explanation of why this happens and why adrp<\/code> + add<\/code> isn’t used by default:<\/p>\n\n\n\n

1. _start<\/code> is Pre-Compiled Generic Code<\/h3>\n\n\n\n

The _start<\/code> function is not compiled at the same time as your application’s main.c<\/code>. It is part of the C Runtime (CRT) startup files (specifically Scrt1.o<\/code> for Position Independent Executables, or PIE).<\/p>\n\n\n\n

    \n
  • Compilation Flags:<\/strong> Scrt1.o<\/code> is compiled by the system maintainers (e.g., glibc developers) using flags like -fPIC<\/code> or -fPIE<\/code>.<\/li>\n\n\n\n
  • Undefined Symbol:<\/strong> When Scrt1.o<\/code> is compiled, it does not know where main<\/code> will be located. main<\/code> is simply an undefined global symbol.<\/li>\n\n\n\n
  • PIC Rules:<\/strong> In -fPIC<\/code> mode, the compiler must assume that any global symbol (like main<\/code>) might be defined in a different shared library or might be preempted<\/strong> (overridden) by another definition at runtime (e.g., via LD_PRELOAD<\/code>). Therefore, it generates code to access the symbol indirectly via the GOT.<\/li>\n<\/ul>\n\n\n\n

    2. The Instruction Sequence<\/h3>\n\n\n\n

    Because of the -fPIC<\/code> compilation, the assembly code in Scrt1.o<\/code> typically looks like this (AArch64):<\/p>\n\n\n\n

    adrp    x0, :got:main       ; Calculate page address of the GOT entry for main\nldr     x0, [x0, :got_lo12:main] ; Load the actual address of main from the GOT<\/code><\/pre>\n\n\n\n
    This sequence asks the dynamic linker to resolve the address of main<\/code>, store it in the GOT, and then loads that address from the GOT.<\/p>\n\n\n\n
    If the compiler had used adrp<\/code> + add<\/code> directly:<\/p>\n\n\n\n
    adrp    x0, main\nadd     x0, x0, :lo12:main<\/code><\/pre>\n\n\n\n
    This would hardcode the relative offset to main<\/code> at link time. While physically possible in a PIE binary (where main<\/code> and _start<\/code> are close), the pre-compiled nature of Scrt1.o<\/code> dictates the instruction pattern before the final link happens.<\/p>\n\n\n\n
    3. Why Doesn’t the Linker “Relax” it?<\/h3>\n\n\n\n
    You are correct that the linker could<\/em> theoretically optimize (relax) this GOT access to a direct adrp<\/code> + add<\/code> since main<\/code> ends up being in the same executable. However, it often doesn’t for a few reasons:<\/p>\n\n\n\n
      \n
    • Symbol Preemption:<\/strong> In ELF, global symbols with “default visibility” (which main<\/code> has) are technically preemptible. Even though main<\/code> is in the executable, the dynamic linking rules usually require the GOT to be present so that the symbol resolution respects the global load order. If the linker relaxed it to adrp<\/code> + add<\/code>, it would bind main<\/code> irrevocably to the internal definition, ignoring any potential external overrides (though overriding main<\/code> is rare and quirky, the linker follows the strict standard).<\/li>\n\n\n\n
    • Relaxation Support:<\/strong> While linker relaxation exists (e.g., changing indirect calls to direct calls), relaxing a load from GOT<\/em> (ldr<\/code>) to an address calculation<\/em> (add<\/code>) is a specific transformation that might not be enabled by default or implemented for this specific case in all linkers (like BFD or LLD) for Scrt1.o<\/code>.<\/li>\n<\/ul>\n\n\n\n
      Summary<\/h3>\n\n\n\n
      The GOT entry exists because _start<\/code> comes from Scrt1.o<\/code><\/strong>, which is a generic, pre-compiled, position-independent object file. It uses the GOT to strictly adhere to ELF symbol resolution rules for global symbols, ensuring the binary works correctly regardless of where main<\/code> is ultimately defined.<\/p>\n\n\n\n
      \n\n\n\n
      Here are the explanations for Symbol Preemption, Global Load Order, and the specific case of overriding main<\/code>.<\/p>\n\n\n\n
      1. Symbol Preemption<\/h3>\n\n\n\n
      Symbol Preemption<\/strong> (or “Interposition”) is a feature of the ELF dynamic linking model that allows a symbol defined in one object file to be “overridden” by a definition in another object file that is loaded earlier.<\/p>\n\n\n\n
        \n
      • How it works:<\/strong> When a piece of code (like a shared library) references a global function (e.g., malloc<\/code>), it doesn’t jump directly to its own internal definition. Instead, it looks up the address in the Global Offset Table (GOT). The dynamic linker fills this table.<\/li>\n\n\n\n
      • The Rule:<\/strong> The dynamic linker looks for the symbol in the Global Load Order<\/strong>. The first<\/strong> definition it finds is the “winner.” All subsequent references to that symbol\u2014even from within the library that provided the “loser” definition\u2014will bind to the “winner.”<\/li>\n<\/ul>\n\n\n\n
        Example:<\/strong>
        If you create a custom library that defines malloc<\/code> and load it before<\/em> the standard C library (libc.so<\/code>), your malloc<\/code> will “preempt” the system malloc<\/code>. Now, when libc.so<\/code> calls malloc<\/code> internally (e.g., inside fopen<\/code>), it will unknowingly call your<\/em> function instead of its own.<\/p>\n\n\n\n
        2. Global Load Order<\/h3>\n\n\n\n
        The Global Load Order<\/strong> is the specific sequence the dynamic linker follows when searching for symbols. For a standard Linux program, the search scope usually looks like this:<\/p>\n\n\n\n
          \n
        1. The Main Executable:<\/strong> The program binary itself is always first.<\/li>\n\n\n\n
        2. LD_PRELOAD<\/code> Libraries:<\/strong> Any libraries specified in the LD_PRELOAD<\/code> environment variable are loaded next.<\/li>\n\n\n\n
        3. Dependencies:<\/strong> Shared libraries linked against the binary (e.g., libc.so<\/code>, libm.so<\/code>) are loaded last, typically in a breadth-first order.<\/li>\n<\/ol>\n\n\n\n
          “First Match Wins”:<\/strong> Because the Main Executable is #1 in this list, any symbol defined in your main program will preempt a symbol of the same name in libc<\/code> or any other library.<\/p>\n\n\n\n
          3. Can you override main<\/code>?<\/h3>\n\n\n\n
          This is where the theory meets a hard wall.<\/p>\n\n\n\n
          Even though _start<\/code> uses a GOT entry to find main<\/code> (which technically allows for dynamic resolution), you typically cannot override main<\/code><\/strong> using standard techniques like LD_PRELOAD<\/code>.<\/p>\n\n\n\n
          Why?<\/strong>
          Referring to the Global Load Order<\/strong> above:<\/p>\n\n\n\n
            \n
          1. The Main Executable<\/strong> is loaded first.<\/li>\n\n\n\n
          2. Your main<\/code> function is inside the Main Executable.<\/li>\n\n\n\n
          3. Therefore, when _start<\/code> asks the dynamic linker for the address of main<\/code>, the linker searches the list. It looks at the Main Executable first, finds main<\/code> immediately, and stops searching.<\/li>\n<\/ol>\n\n\n\n
            It never gets to step 2 (LD_PRELOAD<\/code>), so an external library never gets a chance to provide a substitute main<\/code>.<\/p>\n\n\n\n
            The “Scrt1.o” Dilemma:<\/strong>
            The _start<\/code> function (in Scrt1.o<\/code>) is compiled generically. It doesn’t know<\/em> it will be linked into the main executable; it assumes main<\/code> is just some external symbol that might<\/em> be anywhere. That is why it generates the GOT entry code (adrp<\/code>+ldr<\/code>).
            However, once the final link happens, your main<\/code> is placed in the binary. At runtime, the “First Match Wins” rule ensures that this local main<\/code> is the one that gets used.<\/p>\n\n\n\n
            How people actually “hook” main:<\/strong>
            Since you can’t override main<\/code> directly, tools and libraries that need to run code before main<\/code> usually hook __libc_start_main<\/code><\/strong>.<\/p>\n\n\n\n
              \n
            • _start<\/code> actually calls __libc_start_main<\/code> (which is in libc.so<\/code>), passing the address of main<\/code> as an argument.<\/li>\n\n\n\n
            • Since __libc_start_main<\/code> is in a library (Step 3), you can<\/em> preempt it with LD_PRELOAD<\/code> (Step 2).<\/li>\n\n\n\n
            • Your custom __libc_start_main<\/code> can then run its own logic before finally calling the real main<\/code>.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
              The _start function uses a Global Offset Table (GOT) entry […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[13,30],"class_list":["post-274","post","type-post","status-publish","format-standard","hentry","category-knowledge-base","tag-aarch64","tag-binary"],"_links":{"self":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=274"}],"version-history":[{"count":1,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/274\/revisions"}],"predecessor-version":[{"id":275,"href":"https:\/\/haco.club\/index.php?rest_route=\/wp\/v2\/posts\/274\/revisions\/275"}],"wp:attachment":[{"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/haco.club\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}