Note that I did specify the x86_64 version of ld-linux because the regular version said it was for 32 bit only. Anyone know what the problem is? This also occurs if I try to use GCC. Running Ubuntu 18.04.

This is my first time using fasm on Linux I've only used it on Windows before.

You can see that it cannot find _start. This example file has been completely untouched, however, I tried adding in a _start, using section instead of segment, and a bunch of other stuff. It just segfaults upon run. I'm very confused.

Ok so that wasn't entirely the issue. It appears as though I've been moving between different types of fasm files. So that example I used builds to ELF just fine, however, this one, fasm spits out an object file instead of an ELF for real:

I think this was the original problem I was having but in trying to troubleshoot it, I switched to that other one which could go directly to ELF. I'm guessing that's because the other style uses a system call instead of libc but I do want to use libc functions so I still need a hand here. Also note that this one is a 32 bit.

fasmnewbie you nailed it. I simply didn't have gcc-multilib installed and installing it with apt install gcc-multilib resolved this issue, along with using the -m32.

Well, I definitely learned a lot during this process, which is cool. Don't think I've ever gotten that close to the linker itself before. Was interesting to see that it looks for _start and it totally makes sense as that's typically the "actual" entrypoint, at least when I was reverse engineering Windows binaries, there was always _start followed by a bunch of boilerplate assembly followed by a jump to "main" where the actual programmer's code began.

"main" is the entry point adhering to the C standard structure. It applies to all platforms that produce C executables. _start is more towards the loader and loading a process on Linux ("ld") into memory. _start marks a jump point in memory where RIP starts fetching the instructions from. It applies to all kind of objects that is to be loaded into memory not necessarily from C, since different languages may have different entry point requirements. But for C executable, it's main() because it may also contain the required command line arguments.

"main" is the entry point adhering to the C standard structure. It applies to all platforms that produce C executables. _start is more towards the loader and loading a process on Linux ("ld") into memory. _start marks a jump point in memory where RIP starts fetching the instructions from. It applies to all kind of objects that is to be loaded into memory not necessarily from C, since different languages may have different entry point requirements. But for C executable, it's main() because it may also contain the required command line arguments.

Ahh interesting. So is _start generally the address which is present in the executable file's format header as the "code entry point?" I suppose I could check with my 010 editor, but figured I'd throw that in here. I'm assuming that _start is the point where the operating system's executable file loader transfer control to the user's program after the header has been parsed and the file mapped into memory.

Ahh interesting. So is _start generally the address which is present in the executable file's format header as the "code entry point?" I suppose I could check with my 010 editor, but figured I'd throw that in here. I'm assuming that _start is the point where the operating system's executable file loader transfer control to the user's program after the header has been parsed and the file mapped into memory.

That's correct.

glibc does some stuff there, and then usually calls __libc_start_main, which ends up calling your main. There's a lot of stuff done before C's main happens.

"main" is the entry point adhering to the C standard structure. It applies to all platforms that produce C executables. _start is more towards the loader and loading a process on Linux ("ld") into memory. _start marks a jump point in memory where RIP starts fetching the instructions from. It applies to all kind of objects that is to be loaded into memory not necessarily from C, since different languages may have different entry point requirements. But for C executable, it's main() because it may also contain the required command line arguments.

Ahh interesting. So is _start generally the address which is present in the executable file's format header as the "code entry point?" I suppose I could check with my 010 editor, but figured I'd throw that in here. I'm assuming that _start is the point where the operating system's executable file loader transfer control to the user's program after the header has been parsed and the file mapped into memory.

Just be careful when interpreting debugging information. Different platforms may give you different preparatory code and different loaders. Windows loaders do not use "ld" when loading C executables. All C toolchain you find on Windows are emulated. IIRC, Win64 uses BaseInitThunk as its main thread loader. Loaders are really not the concern of the CPU since it is part of Operating System kernel core services or to be exact, process scheduling. CPU concerns only what appears on its RIP for fetching the next instructions.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum