"segment stack stack" is known only in "-f obj" output - the old dos OMF format for making MZ executables. You didn't see that in a 64-bit section of the Manual (I hope!). We haven't told the OS where the stack is since... well, since dos. The OS tells us, these days. In a 32-bit program, you reserve stack space by subtracting something from esp. I ASSume it's the same for 64-bit - rsp, of course - but 64-bit code is apparently much fussier about alignment. 64-bit questions are "above my pay grade".
I can't imagine why gdb is claiming "no stack". No value at all in rsp?
My preference is, if I don't have anything to compile, I don't use gcc. You might think, if we're using libc, we need the C "startup code" to be linked in. My experience has been that this isn't true. This seems "risky" to me, so I keep trying it. So far, it always works. 32-bit ld has a "glitch" in it - by default it wants to use "/lib/ld-linux.so.1", which doesn't exist on modern systems. We need to specify "-I /lib/ld-linux.so.2", or you get "file not found" when you try to execute the program - very confusing, 'cause my file's right there! An advantage to using gcc is that it knows what to tell ld. No idea what the situation is in 64-bit...
If you want to make 32-bit programs with your 64-bit tools, you'll need to tell them so, or they'll complain. Just "-386" for gcc, I think, and "-melf-i386" for ld - check me on those, I'm not sure...
http://www.x86-64.org/documentation.htmlSupposed to be a 64-bit tutorial here (but the link doesn't work!
http://www.vikaskumar.org/wiki/amd64/amd64/index.htmhttp://milw0rm.org/papers/110You're in "pioneer territory" here, Tenim. Good luck!
Best,
Frank