You’re not seeing a pristine stack, which you could perhaps use to deduce how the stack is initialised, because the C library does a number of things before calling main, and they touch the stack.

With the GNU C library, on x86-64, execution starts at the _start entry point, which calls __libc_start_main to set things up, and the latter ends up calling main. But before calling main, it calls a number of other functions, which causes various pieces of data to be written to the stack. The stack’s contents aren’t cleared in between function calls, so when you get into main, your stack contains leftovers from the previous function calls.

This only explains the results you get from the stack, see the other answers regarding your general approach and assumptions.

Regardless of how the stack is initialised, you’re not seeing a pristine stack, because the C library does a number of things before calling main, and they touch the stack.

With the GNU C library, on x86-64, execution starts at the _start entry point, which calls __libc_start_main to set things up, and the latter ends up calling main. But before calling main, it calls a number of other functions, which causes various pieces of data to be written to the stack. The stack’s contents aren’t cleared in between function calls, so when you get into main, your stack contains leftovers from the previous function calls.

This only explains the results you get from the stack, see the other answers regarding your general approach and assumptions.

You’re not seeing a pristine stack, which you could use to deduce how the stack is initialised, because the C library does a number of things before calling main, and they touch the stack.

With the GNU C library, on x86-64, execution starts at the _start entry point, which calls __libc_start_main to set things up, and the latter ends up calling main. But before calling main, it calls a number of other functions, which causes various pieces of data to be written to the stack. The stack’s contents aren’t cleared in between function calls, so when you get into main, your stack contains leftovers from the previous function calls.

You’re not seeing a pristine stack, which you could perhaps use to deduce how the stack is initialised, because the C library does a number of things before calling main, and they touch the stack.

With the GNU C library, on x86-64, execution starts at the _start entry point, which calls __libc_start_main to set things up, and the latter ends up calling main. But before calling main, it calls a number of other functions, which causes various pieces of data to be written to the stack. The stack’s contents aren’t cleared in between function calls, so when you get into main, your stack contains leftovers from the previous function calls.

This only explains the results you get from the stack, see the other answers regarding your general approach and assumptions.