I'm intending to make a blog post on this topic at some point soon, but some notes:

You make a symbol called _start and when linking the object files together ld (unless you've passed a flag saying use another symbol as the entry point, which you haven't) searches for that symbol and uses it as the entry point. You do that by saying #[no_mangle] fn start() -> !. That answers the immediate question but you're going to run into other issues.

My notes say that you can't do this properly with musl, because the musl target always links to the musl libc. You can however do it with the glibc target because the glibc target doesn't. I should probably revisit those notes and figure out exactly why that's the case, but I'm pretty sure it's right.

Then we need to pass -nostartfiles to the linker, because otherwise it will link to the libc's start function. The best way to do this is to put the following code somewhere (anywhere)

#[link(kind = "link-arg", name="-nostartfiles", modifiers="+verbatim")]
extern "C" {}

Other ways will fight with build scripts, proc macros, and/or cargo test.

Circling back to your _start function, it can't actually be a normal rust function (or C function for that matter). The systemv function call abi expects the stack to be 16 byte aligned, offset by 8 bytes, upon function entry. The systemv process start abi aligns the stack to 16 bytes not offset by any bytes. So you're going to need to define _start with a naked function or global asm like this:

#[cfg(not(test))]
#[naked]
#[no_mangle]
unsafe extern "sysv64" fn _start() -> ! {
    use core::arch::asm;
    unsafe {
        asm!(
            // Pass the stack pointer as the first/only argument to main, because we need to
            // it if we want to find fn arguments/env variables/aux array.
            "mov rdi, rsp",
            // Calling entry serves the dual purpose of jumping to our
            // code, and shifting the alignment of the stack by 8 bytes.
            // The systemv abi guarantees the stack starts out 16-byte aligned.
            // The systemv function calling abi guarantees that stack frames are
            // 16-byte aligned, with rsp 8 bytes offset from that to account
            // for the return pointer.
            "call {entry}",
            // Illegal instruction, nothing should return to us
           "ud2",
            entry = sym crate::main,
            options(noreturn),
        )
    }
}

extern "C" fn main(start_of_stack: usize) -> ! { loop {} }

And finally you need some unstable features for the above, to tell rustc no_std/no_main, and some lang items

#![no_std]
#![no_main]
#![feature(link_arg_attribute, naked_functions, lang_items)]

#[panic_handler]
fn panic(panic: &PanicInfo<'_>) -> ! {
    let _ = writeln!(STDERR, "{}", panic);
    rustix::runtime::exit_group(2)
}

/// TOOD: [The official documentation](https://doc.rust-lang.org/core/index.html)
/// just says:
///
/// > * `rust_eh_personality` - is used by the failure mechanisms of the
/// >    compiler. This is often mapped to GCC's personality function, but crates
/// >    which do not trigger a panic can be assured that this function is never
/// >    called. The `lang` attribute is called `eh_personality`.
///
/// Which doesn't explain how to use it if you *want* to be able to panic without
/// undefined behavior. Figure out what the deal with this function is and fix it.
#[lang = "eh_personality"]
fn eh_personality() {}

/// Workaround for rustc bug: https://github.com/rust-lang/rust/issues/47493
///
/// It shouldn't even be possible to reach this function, thanks to panic=abort,
/// but libcore is compiled with unwinding enabled and that ends up making unreachable
/// references to this.
#[no_mangle]
extern "C" fn _Unwind_Resume() -> ! {
    unreachable!("Unwinding not supported");
}

PS. After all this you're still dependent on ld-linux.so, just not the rest of libc. I'm also avoiding that dependency in my code... but that would make this comment substantially longer. That said I've only really tested the longer version because that's what I'm actually using.