The QtCreator debugger is actually pretty decent, and I prefer it to gdb -tui and cgdb. The debugger in the early-access version of CLion looks promising, but it lacks essential features like a disassembly view and a memory view, and sadly they aren't mentioned on the current 1.0 roadmap.
Emacs's gdb-mi mode has the potential to be the best out there. Unfortunately it has some critical weaknesses in its current form. The biggest is that it uses the awful speedbar extension for its watch window. And gdb-mode's local variables window is useless as it won't allow you to inspect any aggregate types like structs and arrays, so you're forced to use the aforementioned awful speedbar-based watch window just to inspect local variables. I'm hoping to fix this or rewrite it entirely when I have time.
I don't think it has a watch window yet, or a disassembly or memory view. It has a cleaner architecture than the original GUD though, which might make it more pleasant to do major development on. It supports more backend debuggers, multiple concurrent sessions and attaching to a debugger session in an existing Comint buffer (presumably that means it supports attaching to existing processes as well; don't know if the original GUD gdb mode does that).
It does have the nifty idea of a minor-mode that is activated in source buffers that makes the buffer read-only and maps debugger commands to single keystrokes, eg. n for next, s for step, etc. ('Insert' toggles it off in case you actually want to do some editing).
The gdb support seems currently a bit basic. For example if you highlight an expression and press 'e' it sends "eval <selection>" to gdb when of course it should be "print". (It sounds like the main dev effort has been on the Ruby debugger so far). I get the feeling it might just need a little TLC to make it great.
For now, I agree the speedbar, and the experience of a watch window in it, is awful. Having seen how powerful gdb's print command is (doing very well with aggregate types, and now with the latest gdb you can switch on some Python-based pretty printing for it as well), as a temporary personal init-file hack I brought the single-key mode to the original GUD making sure to include 'p' to 'print' and capital 'P' to 'print*' the currently highlighted text, or the current word if nothing is highlighted. If the gdb buffer isn't visible, it prints to the minibuffer, else if the gdb buffer is visible, it goes there, and then I can move the cursor around and use seperate Emacs folding commands to collapse and expand the braces. It's still a bit raw but I'm so pleased with it that I already don't miss Visual Studio (the supposed gold standard for user-friendly debugging, yet even in the latest version I find it distressingly weak at inspecting common STL types).
I might try and contribute to Rocky's mode myself when I have the time.
After I wrote my post above, I started work on a GDB mode from scratch. So far, I have the process management and a PEG-based parser (peg.el is great) for MI output working. I'm not sure if you've looked at gdb-mi.el's code, but it was written by a GSoC student and does vile shit like munging MI output with regular expressions so it can be fed to json.el and parsed as valid JSON. In similar lazy fashion, it uses GUD just for process management. I don't feel there's anything worth salvaging or building on in there.
Why kernel tutorials always say they need nasm. Gcc already comes with an assembler so simply use it instead of installing other softwares.
And if you prefer intel syntax simply add ".intel_syntax;"
No, a ret instruction would probably segfault, depending on the content of the stack. To terminate a program you have to use the corresponding system call. On linux :
That (or something like it) is true for the process as a whole, but not necessarily for main. It's usual to call main from a library-provided function, so it returns just like any other function. This removes the need to special-case main in any way, and provides a space for any system-specific startup and shutdown code.
If you've got VS2012, you can see this code in the file at something like "c:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\crt\src\crt0.c" (it should be easy to find for other versions - it's been in pretty much in that place, with that name, probably with those contents, since VC5 I think).
My post was a bit x86/VC++-specific but the principles have been common to all the C environments I've used. I don't think I've ever used one that by default called your startup function directly, bypassing C runtime initialisation. (Though it's very easy to set this up with Visual Studio.)
to3m is correct. On my GNU/Linux machine main() is called from __libc_start_main(). A ret instruction in main() returns to __libc_start_main(), which in turn calls exit().
Yes they are !
Global variables have static storage duration and are therefore default initialized.
Be careful with the word 'static' which does not always correspond to the the keyword static which has several meaning ! When used with a global variable the static keyword has not the same meaning as static storage duration". It only means no external linkage.
Don't bother having a external GUI, just use the built-in Ncruses one.