linuxassemblylinkerandroid-ndk

Android NDK ld.lld: error: duplicate symbol: _start >>> defined at crtbegin.c

I am trying to assemble and run a simple Hello World program on my Android phone. My host laptop is a Ubuntu 22.04 64 bit system. I downloaded the android-ndk-r27c and extracted it to my Android folder where my SDK already resided.

This is my hello64bit.s taken from here and its path is /home/developer/Android/android-ndk-r27c-linux/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin


/* Data segment: define our message string and calculate its length. */
msg:
    .ascii        "Hello, ARM64!\n"
len = . - msg

.text

/* Our application's entry point. */
.globl _start
_start:
    /* syscall write(int fd, const void *buf, size_t count) */
    mov     x0, #1      /* fd := STDOUT_FILENO */
    ldr     x1, =msg    /* buf := msg */
    ldr     x2, =len    /* count := len */
    mov     w8, #64     /* write is syscall #64 */
    svc     #0          /* invoke syscall */

    /* syscall exit(int status) */
    mov     x0, #0      /* status := 0 */
    mov     w8, #93     /* exit is syscall #93 */
    svc     #0          /* invoke syscall */

When I run ./aarch64-linux-android27-clang -o hello64.o hello64bit.s I get the following error:

ld.lld: error: duplicate symbol: _start
>>> defined at crtbegin.c
>>>            /home/developer/Android/android-ndk-r27c-linux/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/./../sysroot/usr/lib/aarch64-linux-android/27/crtbegin_dynamic.o:(_start)
>>> defined at /tmp/hello64bit-fb91b4.o:(.text+0x0)
clang: error: linker command failed with exit code 1 (use -v to see invocation)

When I change the name start to start1 I get an undefined main error:

ld.lld: error: undefined symbol: main
>>> referenced by crtbegin.c
>>>               /home/developer/Android/android-ndk-r27c-linux/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/bin/./../sysroot/usr/lib/aarch64-linux-android/27/crtbegin_dynamic.o:(_start_main)

What am I doing wrong?

Solution

  • Compile and link like this instead:

    $ ./aarch64-linux-android27-clang -o hello64 hello64bit.s -static -nostartfiles -nostdlib

    Explanation

    Why -nostartfiles -nostdlib?

    You hello64bit.s is a tiny standalone program whose entry point (where the OS calls into it) is _start. _start is the default entry point for any program, and its default definition is contained in the object file crtbegin_dynamic.o that you see mentioned in the duplicate symbol error diagnostics.

    That file contains the C runtime startup code that executes the necessary initialisations for running a regular program that depends on the C runtime library. The _start function defined in that file executes that code and thereafter calls main, the mandatory root function of a regular C (or C++) program's application code.

    The file crtbegin_dynamic.o is linked into any dynamically linked program by default, on the assumption that the program is regular program, that defines main, does not define _start, and depends on the C runtime library.

    But your program isn't a regular one. You want to compile and link your own definition of the _start function, and that definition is your whole program, which does not depend on the C runtime library.

    So the linker, by default, links the crtbegin_dynamic.o definition of the _start function in addition to yours, and that is a duplicate symbol or multiple definition error.

    You want to direct the linker not to bother linking the C runtime startup code and the C runtime library. -nostartfiles tells it not to bother linking the startup code and -nostdlib tells it not to bother linking the C runtime library.

    Why -static?.

    Without it, the linkage will still fail like this:

    $ ./aarch64-linux-android27-clang -o hello64 hello64bit.s -nostartfiles -nostdlib
ld.lld: error: relocation R_AARCH64_ABS64 cannot be used against local symbol; recompile with -fPIC
>>> defined in /tmp/hello64bit-699ce4.o
>>> referenced by /tmp/hello64bit-699ce4.o:(.text+0x30)

    That's because your assembly is not position-independent code (PIC), which it must be in a position-independent dynamically linked executable, which is what the linker tries to create by default. You cannot follow the linker's advice - recompile with -fPIC - because that is a compilation option that tells the compiler to generate PIC assembly code, but you are not using the compiler to generate the assembly code. You're supplying it yourself, so it would be up to you to make it PIC.

    Since this program isn't PIC, and I guess you don't care, you can direct the linker not carry out a dynamic linkage, which requires relocations, and just to do a static linkage, which doesn't. -static achieves that.

    Why -o hell64 instead of -o hello64.o?

    hello64.o denotes an object file (*.o), i.e the output of the compiler/assembler, before it is linked into a program. That's what you would get with:

    $ ./aarch64-linux-android27-clang -c -o hello64.o hello64bit.s

    where -c means Just compile/assemble. Don't link. But that's not what you are doing. You are assembling the code and linking it into a executable program. Executables don't have extensions (except on Windows, *.exe).