17 ms·

Learning C with gdb

397 points by happy4crazy 14y ago

iopuy 14y ago
I find the basic c tutorials a nice refresher. Here is one from a few weeks back on memory addresses and pointers in c http://news.ycombinator.com/item?id=4399498 http://news.ycombinator.com/item?id=4399498 .
m_eiman 14y ago
Here's a more full-featured C++ REPL: http://root.cern.ch/drupal/content/what-cling http://root.cern.ch/drupal/content/what-cling
- Create 14y ago
  ...except, that it isn't C++ standard compliant, and you are worse off than when you started out. "full-featured C++" is misleading. http://www.insectnation.org/howto/living-without-root http://www.insectnation.org/howto/living-without-root https://linuxfr.org/nodes/18919/comments/632920 https://linuxfr.org/nodes/18919/comments/632920 http://comments.gmane.org/gmane.comp.lang.c%2B%2B.root/5924 http://comments.gmane.org/gmane.comp.lang.c%2B%2B.root/5924
  - octopus 14y ago
    You are making a confusion here, CINT != CLING.
    - Create 14y ago
      CINT referenced, because CLING hasn't seen deployment and real tests. Maybe in a few years.
sswezey 14y ago
Having programmed a fair amount of C, I regret never learning properly how to use gdb. This article is quite helpful!
- eru 14y ago
  It's never too late to start.
stcredzero 14y ago
There was a debugger posted here to HN awhile back that actually displayed structs and pointers graphically. What was the name of that project, and is it still around? I was trying to find it the other day. I thought that was a dynamite tool for students. With LLVM, we should be able to have a REPL for C. as a pedagogical tool.
- simias 14y ago
  Maybe ddd? https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
- duaneb 14y ago
  Perhaps cling? http://root.cern.ch/drupal/content/cling http://root.cern.ch/drupal/content/cling
- SAHChandler 14y ago
  I believe it was Tenacious-C: http://tenaciousc.com/ http://tenaciousc.com/
  - stcredzero 14y ago
    Yes, that was it! We have a winner! (A wiener?)
    - heretohelp 14y ago
      Sadly, Windows-only.
narrator 14y ago
I just got back into C programming after a long absence. Programming with Eclipse CDT is the way to go, at least for starting out. The debugger is great.
jparishy 14y ago
This is pretty neat, though I found myself doing similar things in small test files when I was first learning C and printing the results. C compile times suck, but with like a 10 line program or so to toy with a language semantic, it was practically instant (in 2007). But then again I had never used a dynamic language like Ruby/Python before then so I didn't know better. More people should be hopping on this bandwagon though because debuggers are awesome. I typically find myself using `po` the most in LLDB (Xcode, iOS development) but it's insanely useful especially when Xcode refuses to show me the values of something I want in the Variables View, ex. NSDictionary keys/values, objects in an NSArray, etc. I'll also use it sometimes to execute simple commands like `[myArrayObject count]` when the Variables View refuses to show me property values. Sometimes Xcode's GUI bits just don't cut it! There's more info on what you can do with LLDB here: http://lldb.llvm.org/tutorial.html http://lldb.llvm.org/tutorial.html And if you've used GDB, this might be of use: http://lldb.llvm.org/lldb-gdb.html http://lldb.llvm.org/lldb-gdb.html
- geoka9 14y ago
  > C compile times suck Can I ask you what you're comparing with? I can compare with C++, Scala and Go. The first two are horrible in that department when compared with C. Go's compiles are blazingly fast.
  - jparishy 14y ago
    I'm not really comparing it to anything, just speaking from experience of having waited many hours waiting for C programs to compile in the past.
    - ghshephard 14y ago
      Isn't the job of your Makefile to require recompilation of only those source files that have changed? I just did a random google of "how long to compile linux kernel" and came across this: https://plus.google.com/u/0/+LinusTorvalds/posts/6BxnSisp8fU https://plus.google.com/u/0/+LinusTorvalds/posts/6BxnSisp8fU One nice excerpt: "Total build time after make clean is about 1min, give or take 10secs. `touch include/linux/version.h` is 6 seconds to rebuild. Just doing a rebuild without touching anything is 2.7secs. For a defconfig, it does build a godawful amount of modules :^) 'allnoconfig; make' is 16 seconds..."
dkhenry 14y ago
GDB skills are one of those super useful abilities that you just can't find in most CS graduates. I often spend a few days with new C developers just teaching them how to use GDB to find problems. They are amazed when they find out you can examine variables and set conditional breakpoints.
- jobu 14y ago
  This is an area where many college professors fall short. In my intro to CS class we learned C, and the professor explicitly told us to debug our code with printf statements. It wasn't until my first job that I even found out about gdb. I can't believe how much time I wasted trying to debug C and C++ code in college with nothing more than printf and cout.
  - dkhenry 14y ago
    What makes it even worse is the lack of a REPL means that between each change you need to recompile. In any large program this is going to take minutes and they add up. A simple GDB invocation is not only a better way of tracking it down, but can potently save hours.
    - vlisivka 14y ago
      When QA will found bug in your program in testing or staging environment, they will send you your logs, which will be empty. They will not allow you to use testing or staging (or production :-) ) for development.
    - tmurray 14y ago
      quick changes that don't require a full recompilation generally mean intermediate files are lying around, which means you only need to recompile changed files and relink. this is usually pretty fast until you start changing headers or something like that. (I'm very used to projects with 30 minute plus full compile times taking less than 10 seconds to recompile and relink single-file changes.) this is not to say that gdb won't save hilarious amounts of time or that you can be a good C coder without understanding a debugger (I don't think you can), just that the huge compile time thing isn't true most of the time.
stonefroot 14y ago
I want to be able to do this with assembly, e.g., see what is in each register as I step through the program.
- digitalinfinity 14y ago
  Doesn't info registers in gdb do this for you?
- duaneb 14y ago
  GDB can step through instruction by instruction, and you can easily examine registers.
  - stonefroot 14y ago
    Can I do this with a hand-written assembly program, i.e. not necessarily one that has been compiled with as and subject to GNU default optimisations or "constraints"?
    - duaneb 14y ago
      It's been many years since i've done hand-written assembly, so I can't say for sure, but it should be able to do instruction stepping on arbitrary programs.
    - tene 14y ago
      Yes.
    - cfallin 14y ago
      The commands you want are "stepi" (single-step one instruction), "disass" (disassemble at the current point in the program), and "info registers" (show you what's in all of the registers). These work equally well for hand-written assembly and for any arbitrary compiled program.
      - stonefroot 14y ago
        cfallin: many, many thanks. I guess should read the gdb manual, and, if it's anything like the as manual (which I've learned is not always the full story), the source too.
16s 14y ago
gdb is very nice. I use it with C++ too. Watch sizeof on char arrays. Why is my string's sizeof always 8? That confuses some when starting out.
- lysol 14y ago
  That's because sizeof is for the size of the variable (a char pointer), not the size of the string up to the null terminator, which is what strlen's for.
Derbasti 14y ago
While graphical debuggers are great overall, there are times when I prefer to get down to the command line and do my debugging there. And quite surprisingly, I don't lose much efficiency there, either. But then, this could be the story of most command line utilities: Seems fiddly at first, but actually it is quite usable and often times more convenient than all those whiz-bang graphical tools.
- dkhenry 14y ago
  The only thing I like about graphical debuggers is the ease of which you can set up multi-window dashboards. I can have my stack windows a few watched variables and the code all on one screen at the same time as I step through the program
joeld42 14y ago
This looks really great, but I'd call it "Learning GDB with C"
jfaucett 14y ago
Does anyone else think debuggers are awesome for learning how programs/languages work? Its pretty much always the first thing I do, even before reading docs, build and debug.
geoka9 14y ago
There's also CINT (a C interpreter), which can be used as a REPL: http://root.cern.ch/drupal/content/cint http://root.cern.ch/drupal/content/cint
djcb 14y ago
for the somewhat-graphically-inclined, gdb mode in emacs has the much under-advertized 'M-x gdb-many-windows' which shows your stack, local variables, breakpoints etc. in separate 'windows'.
X-Istence 14y ago
lldb would be even better for using instead of gdb because lldb actually uses clang's parsing for everything. I was watching an Apple talk on lldb which explained this in more detail, and it shows a lot of promise for a debugger to have a full C compiler inside of it.
doctorwho 14y ago
It's great for instant feedback but IMHO interactive programming makes it easy (or at least easier) to be lazy. If you get used to coding by trial and error you'll never really understand the language or the problem you're trying to solve, you'll just keep trying things until it works. I know that's not how everyone approaches programming but I've seen it far too often to dismiss it
codeinthehole 14y ago
If you enjoyed this, then you'll certainly enjoy the programming chapter of 'Hacking: The Art of Exploitation' by Jon Erickson (http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitation http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitatio...). The first half of the book is a similar exploration of C programming using GDB to explain everything. Recommended.
- happy4crazy 14y ago
  Hacker School agrees--we have two copies in our library :)
agumonkey 14y ago
gdb is like acid, works everywhere : https://stripe.com/blog/exploring-python-using-gdb https://stripe.com/blog/exploring-python-using-gdb
- happy4crazy 14y ago
  That post was one of the things that inspired me to start tinkering with gdb. Very cool stuff.
  - agumonkey 14y ago
    It broke a mental barrier I had gdb begin for `native only` programs.
wildmXranat 14y ago
In addition to the gdb command, what would be a good GUI front-end for it ?
- mtoddh 14y ago
  Emacs actually integrates pretty nicely with gdb. Just split the source file being debugged horizontally and fire up gdb in the other window: Split the windows horizontally: C-x 2 Switch to the other window: C-x o Fire up gdb: M-x gdb You can set breakpoints with C-x <SPC>. Emacs will show an arrow next the source line about to be executed.
  - edge17 14y ago
    yea, agree with this. emacs integration is very nice. as a side note, if you're particularly aggressive with gdb or the project you're working on is very large it helps to increase the buffer size significantly
- miratom 14y ago
  Eclipse
- edge17 14y ago
  i'm sort of in between on this. I really don't like using the graphical debugger in xcode, but it is great when you have to dig around on multiple threads. I used ddd a bit, but always ended up just reverting back to cmdline gdb. typically though, the performance of the graphical debugger is pretty lousy compared to commandline, and (in the case of xcode) it doesn't do everything. Knowing how to navigate yourself on the commandline is very beneficial, especially when you need to [for lack of better words] rip the shit out of something, inject chunks of memory, or forcibly reproduce bugs that don't happen often. That being said, I have heard that visual studio is amazing. For some reason I've never developed on Windows platforms so I've never had the opportunity to use the debugger. I'd be curious to hear other people's opinions/expereinces. I'll freely admit that I use the tools I use because I've grown comfortable with them.
tmurray 14y ago
I'm surprised nobody's linked the gdb reference card. It's fairly old now, but it's still handy if you don't use gdb that often: http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf
- reirob 14y ago
  Many thanks for this link. Exactly what I need at the moment.
breckinloggins 14y ago
Also cool to play around with are the various options that let GCC (and presumably LLVM) show you the various compilation stages of your C code. You can even spit out the C and resulting assembly side-by-side. I haven't had the time to play with this, but Part 4 of the excellent "Unix as IDE" series [1] goes into it and I'm sure there's more around the web. Another really fun way to get into the underlying assembler that the C compiler generates is Vidar Hokstad's "Writing a compiler in Ruby, bottom up" [2]. This series involves writing little C functions, compiling them to the simplest assembly you can get, then writing a ruby compiler (in Ruby!) that emits that assembly. Some people have objections to the approach, but it's really quite nifty. I especially like it because it's really refreshing to see a compiler tutorial that doesn't start with the lexer and parser. [1] http://blog.sanctum.geek.nz/unix-as-ide-compiling/ http://blog.sanctum.geek.nz/unix-as-ide-compiling/ [2] http://www.hokstad.com/compiler http://www.hokstad.com/compiler
winter_blue 14y ago
The visual debugger in both Eclipse CDT and Visual C++ let you do things like create breakpoints, step through your program, monitor variable values, even create conditional breakpoints that are triggered when a particular lineof code is executed n number of times or when some particular expression involving variables in the local context of the breakpoint turn true. My question is, what advantages do you get in using gdb directly through the CLI rather than through an IDE? (like Eclipse/NetBeans which itself uses gdb for C/C++ debugging, but has a nice graphical UI for it.)
- IsTom 14y ago
  I'm not sure if CDT and Visual C++ can't do that, but I don't think so: gdb can attach to already running processes. Saved me once from a bug in ruby runtime.
  - greenyoda 14y ago
    The Visual C++ debugger can attach to a running process. I've used that feature to debug server code.
- kevinnk 14y ago
  GDB itself has a -tui option which gives you a nice "gui" style interface in the command line. As to why you would not use any sort of gui interface, I don't think the command line alone gives you any advantage as far as I know.
- ajross 14y ago
  Flip it around: what advantage does a "nice graphical UI" give you for what is fundamentally a text processing problem. Except for the most basic stuff (starting, stopping, setting a breakpoint at a line, looking at a variable value) everything you want to do in gdb involves something approximating a query language: set a watchpoint on the 32 bit quantity stored at this address; dump memory from this pointer; call this function (e.g. strstr() on a memory region) and tell me the result. Watching your code run and hitting a "next" button repeatedly isn't really a good use of the tool.
shocks 14y ago
You should use debugging not only to learn and fix bugs, but also to check your code actually does what you think it does.
agrona 14y ago
gdb is one of those tools that I regret never learning because I've always had an IDE. I was able to follow the examples here well enough, but the array assignment causes gdb to crash in Cygwin. Does anyone have any suggestions for how to overcome that (short of installing a vm & a real linux)?
phao 14y ago
Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize. Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing. And maybe I am wrong, but even the author got mislead by it. "I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic." That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works". I really liked the idea. I just think it may be misleading if the tool you're using is GDB. It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.
- AYBABTME 14y ago
  That's not undefined, it's simply the bitwise representation of a 32 bits integer.
  - phao 14y ago
    C allows more than 1 representation for integers. I know at least 3 possible ones: two's complement, ones' complement and signed magnitude. The "natural wrap up" is not the same in all of the representations. When the integer is unsigned, C gives you more guarantees, but for signed types, you're out of luck, and get to undefined bahvior land. Check this out: http://web.torek.net/torek/c/numbers.html http://web.torek.net/torek/c/numbers.html And as an after note... The maximum int may be less than 2^31-1. Maybe your C implementation decides that your int type will be a 16bits object with values ranging from -2^15 to 2^15-1. In that case, that integer literal would not be an int, and is likely to be a long, and maybe, in this same implementation, a long is a 61bit object ranging from -2^63 to 2^63-1. In that case, that assertion is just plain false. That's not the system exposed in the article though. But it could happen in some other system. This can be true even on a 32bit system.
izx 14y ago
don't forget about panel mode in gdb! ctrl-x, a to toggle it on/off

397 points by happy4crazy 14y ago

iopuy 14y ago

I find the basic c tutorials a nice refresher. Here is one from a few weeks back on memory addresses and pointers in c http://news.ycombinator.com/item?id=4399498 http://news.ycombinator.com/item?id=4399498 .

m_eiman 14y ago

Here's a more full-featured C++ REPL: http://root.cern.ch/drupal/content/what-cling http://root.cern.ch/drupal/content/what-cling

Create 14y ago
...except, that it isn't C++ standard compliant, and you are worse off than when you started out. "full-featured C++" is misleading. http://www.insectnation.org/howto/living-without-root http://www.insectnation.org/howto/living-without-root https://linuxfr.org/nodes/18919/comments/632920 https://linuxfr.org/nodes/18919/comments/632920 http://comments.gmane.org/gmane.comp.lang.c%2B%2B.root/5924 http://comments.gmane.org/gmane.comp.lang.c%2B%2B.root/5924
- octopus 14y ago
  You are making a confusion here, CINT != CLING.
  - Create 14y ago
    CINT referenced, because CLING hasn't seen deployment and real tests. Maybe in a few years.

sswezey 14y ago

Having programmed a fair amount of C, I regret never learning properly how to use gdb. This article is quite helpful!

eru 14y ago
It's never too late to start.

stcredzero 14y ago

There was a debugger posted here to HN awhile back that actually displayed structs and pointers graphically. What was the name of that project, and is it still around? I was trying to find it the other day. I thought that was a dynamite tool for students. With LLVM, we should be able to have a REPL for C. as a pedagogical tool.

simias 14y ago
Maybe ddd? https://www.gnu.org/software/ddd/ https://www.gnu.org/software/ddd/
duaneb 14y ago
Perhaps cling? http://root.cern.ch/drupal/content/cling http://root.cern.ch/drupal/content/cling
SAHChandler 14y ago
I believe it was Tenacious-C: http://tenaciousc.com/ http://tenaciousc.com/
- stcredzero 14y ago
  Yes, that was it! We have a winner! (A wiener?)
  - heretohelp 14y ago
    Sadly, Windows-only.

narrator 14y ago

I just got back into C programming after a long absence. Programming with Eclipse CDT is the way to go, at least for starting out. The debugger is great.

jparishy 14y ago

This is pretty neat, though I found myself doing similar things in small test files when I was first learning C and printing the results. C compile times suck, but with like a 10 line program or so to toy with a language semantic, it was practically instant (in 2007). But then again I had never used a dynamic language like Ruby/Python before then so I didn't know better. More people should be hopping on this bandwagon though because debuggers are awesome. I typically find myself using `po` the most in LLDB (Xcode, iOS development) but it's insanely useful especially when Xcode refuses to show me the values of something I want in the Variables View, ex. NSDictionary keys/values, objects in an NSArray, etc. I'll also use it sometimes to execute simple commands like `[myArrayObject count]` when the Variables View refuses to show me property values. Sometimes Xcode's GUI bits just don't cut it! There's more info on what you can do with LLDB here: http://lldb.llvm.org/tutorial.html http://lldb.llvm.org/tutorial.html And if you've used GDB, this might be of use: http://lldb.llvm.org/lldb-gdb.html http://lldb.llvm.org/lldb-gdb.html

geoka9 14y ago
> C compile times suck Can I ask you what you're comparing with? I can compare with C++, Scala and Go. The first two are horrible in that department when compared with C. Go's compiles are blazingly fast.
- jparishy 14y ago
  I'm not really comparing it to anything, just speaking from experience of having waited many hours waiting for C programs to compile in the past.
  - ghshephard 14y ago
    Isn't the job of your Makefile to require recompilation of only those source files that have changed? I just did a random google of "how long to compile linux kernel" and came across this: https://plus.google.com/u/0/+LinusTorvalds/posts/6BxnSisp8fU https://plus.google.com/u/0/+LinusTorvalds/posts/6BxnSisp8fU One nice excerpt: "Total build time after make clean is about 1min, give or take 10secs. `touch include/linux/version.h` is 6 seconds to rebuild. Just doing a rebuild without touching anything is 2.7secs. For a defconfig, it does build a godawful amount of modules :^) 'allnoconfig; make' is 16 seconds..."

dkhenry 14y ago

GDB skills are one of those super useful abilities that you just can't find in most CS graduates. I often spend a few days with new C developers just teaching them how to use GDB to find problems. They are amazed when they find out you can examine variables and set conditional breakpoints.

jobu 14y ago
This is an area where many college professors fall short. In my intro to CS class we learned C, and the professor explicitly told us to debug our code with printf statements. It wasn't until my first job that I even found out about gdb. I can't believe how much time I wasted trying to debug C and C++ code in college with nothing more than printf and cout.
- dkhenry 14y ago
  What makes it even worse is the lack of a REPL means that between each change you need to recompile. In any large program this is going to take minutes and they add up. A simple GDB invocation is not only a better way of tracking it down, but can potently save hours.
  - vlisivka 14y ago
    When QA will found bug in your program in testing or staging environment, they will send you your logs, which will be empty. They will not allow you to use testing or staging (or production :-) ) for development.
  - tmurray 14y ago
    quick changes that don't require a full recompilation generally mean intermediate files are lying around, which means you only need to recompile changed files and relink. this is usually pretty fast until you start changing headers or something like that. (I'm very used to projects with 30 minute plus full compile times taking less than 10 seconds to recompile and relink single-file changes.) this is not to say that gdb won't save hilarious amounts of time or that you can be a good C coder without understanding a debugger (I don't think you can), just that the huge compile time thing isn't true most of the time.

stonefroot 14y ago

I want to be able to do this with assembly, e.g., see what is in each register as I step through the program.

digitalinfinity 14y ago
Doesn't info registers in gdb do this for you?
duaneb 14y ago
GDB can step through instruction by instruction, and you can easily examine registers.
- stonefroot 14y ago
  Can I do this with a hand-written assembly program, i.e. not necessarily one that has been compiled with as and subject to GNU default optimisations or "constraints"?
  - duaneb 14y ago
    It's been many years since i've done hand-written assembly, so I can't say for sure, but it should be able to do instruction stepping on arbitrary programs.
  - tene 14y ago
    Yes.
  - cfallin 14y ago
    The commands you want are "stepi" (single-step one instruction), "disass" (disassemble at the current point in the program), and "info registers" (show you what's in all of the registers). These work equally well for hand-written assembly and for any arbitrary compiled program.
    - stonefroot 14y ago
      cfallin: many, many thanks. I guess should read the gdb manual, and, if it's anything like the as manual (which I've learned is not always the full story), the source too.

16s 14y ago

gdb is very nice. I use it with C++ too. Watch sizeof on char arrays. Why is my string's sizeof always 8? That confuses some when starting out.

lysol 14y ago
That's because sizeof is for the size of the variable (a char pointer), not the size of the string up to the null terminator, which is what strlen's for.

Derbasti 14y ago

While graphical debuggers are great overall, there are times when I prefer to get down to the command line and do my debugging there. And quite surprisingly, I don't lose much efficiency there, either. But then, this could be the story of most command line utilities: Seems fiddly at first, but actually it is quite usable and often times more convenient than all those whiz-bang graphical tools.

dkhenry 14y ago
The only thing I like about graphical debuggers is the ease of which you can set up multi-window dashboards. I can have my stack windows a few watched variables and the code all on one screen at the same time as I step through the program

joeld42 14y ago

This looks really great, but I'd call it "Learning GDB with C"

jfaucett 14y ago

Does anyone else think debuggers are awesome for learning how programs/languages work? Its pretty much always the first thing I do, even before reading docs, build and debug.

geoka9 14y ago

There's also CINT (a C interpreter), which can be used as a REPL: http://root.cern.ch/drupal/content/cint http://root.cern.ch/drupal/content/cint

djcb 14y ago

for the somewhat-graphically-inclined, gdb mode in emacs has the much under-advertized 'M-x gdb-many-windows' which shows your stack, local variables, breakpoints etc. in separate 'windows'.

X-Istence 14y ago

lldb would be even better for using instead of gdb because lldb actually uses clang's parsing for everything. I was watching an Apple talk on lldb which explained this in more detail, and it shows a lot of promise for a debugger to have a full C compiler inside of it.

doctorwho 14y ago

It's great for instant feedback but IMHO interactive programming makes it easy (or at least easier) to be lazy. If you get used to coding by trial and error you'll never really understand the language or the problem you're trying to solve, you'll just keep trying things until it works. I know that's not how everyone approaches programming but I've seen it far too often to dismiss it

codeinthehole 14y ago

If you enjoyed this, then you'll certainly enjoy the programming chapter of 'Hacking: The Art of Exploitation' by Jon Erickson (http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitation http://en.wikipedia.org/wiki/Hacking:_The_Art_of_Exploitatio...). The first half of the book is a similar exploration of C programming using GDB to explain everything. Recommended.

happy4crazy 14y ago
Hacker School agrees--we have two copies in our library :)

agumonkey 14y ago

gdb is like acid, works everywhere : https://stripe.com/blog/exploring-python-using-gdb https://stripe.com/blog/exploring-python-using-gdb

happy4crazy 14y ago
That post was one of the things that inspired me to start tinkering with gdb. Very cool stuff.
- agumonkey 14y ago
  It broke a mental barrier I had gdb begin for `native only` programs.

wildmXranat 14y ago

In addition to the gdb command, what would be a good GUI front-end for it ?

mtoddh 14y ago
Emacs actually integrates pretty nicely with gdb. Just split the source file being debugged horizontally and fire up gdb in the other window: Split the windows horizontally: C-x 2 Switch to the other window: C-x o Fire up gdb: M-x gdb You can set breakpoints with C-x <SPC>. Emacs will show an arrow next the source line about to be executed.
- edge17 14y ago
  yea, agree with this. emacs integration is very nice. as a side note, if you're particularly aggressive with gdb or the project you're working on is very large it helps to increase the buffer size significantly
miratom 14y ago
Eclipse
edge17 14y ago
i'm sort of in between on this. I really don't like using the graphical debugger in xcode, but it is great when you have to dig around on multiple threads. I used ddd a bit, but always ended up just reverting back to cmdline gdb. typically though, the performance of the graphical debugger is pretty lousy compared to commandline, and (in the case of xcode) it doesn't do everything. Knowing how to navigate yourself on the commandline is very beneficial, especially when you need to [for lack of better words] rip the shit out of something, inject chunks of memory, or forcibly reproduce bugs that don't happen often. That being said, I have heard that visual studio is amazing. For some reason I've never developed on Windows platforms so I've never had the opportunity to use the debugger. I'd be curious to hear other people's opinions/expereinces. I'll freely admit that I use the tools I use because I've grown comfortable with them.

tmurray 14y ago

I'm surprised nobody's linked the gdb reference card. It's fairly old now, but it's still handy if you don't use gdb that often: http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf http://users.ece.utexas.edu/~adnan/gdb-refcard.pdf

reirob 14y ago
Many thanks for this link. Exactly what I need at the moment.

breckinloggins 14y ago

Also cool to play around with are the various options that let GCC (and presumably LLVM) show you the various compilation stages of your C code. You can even spit out the C and resulting assembly side-by-side. I haven't had the time to play with this, but Part 4 of the excellent "Unix as IDE" series [1] goes into it and I'm sure there's more around the web. Another really fun way to get into the underlying assembler that the C compiler generates is Vidar Hokstad's "Writing a compiler in Ruby, bottom up" [2]. This series involves writing little C functions, compiling them to the simplest assembly you can get, then writing a ruby compiler (in Ruby!) that emits that assembly. Some people have objections to the approach, but it's really quite nifty. I especially like it because it's really refreshing to see a compiler tutorial that doesn't start with the lexer and parser. [1] http://blog.sanctum.geek.nz/unix-as-ide-compiling/ http://blog.sanctum.geek.nz/unix-as-ide-compiling/ [2] http://www.hokstad.com/compiler http://www.hokstad.com/compiler

winter_blue 14y ago

The visual debugger in both Eclipse CDT and Visual C++ let you do things like create breakpoints, step through your program, monitor variable values, even create conditional breakpoints that are triggered when a particular lineof code is executed n number of times or when some particular expression involving variables in the local context of the breakpoint turn true. My question is, what advantages do you get in using gdb directly through the CLI rather than through an IDE? (like Eclipse/NetBeans which itself uses gdb for C/C++ debugging, but has a nice graphical UI for it.)

IsTom 14y ago
I'm not sure if CDT and Visual C++ can't do that, but I don't think so: gdb can attach to already running processes. Saved me once from a bug in ruby runtime.
- greenyoda 14y ago
  The Visual C++ debugger can attach to a running process. I've used that feature to debug server code.
kevinnk 14y ago
GDB itself has a -tui option which gives you a nice "gui" style interface in the command line. As to why you would not use any sort of gui interface, I don't think the command line alone gives you any advantage as far as I know.
ajross 14y ago
Flip it around: what advantage does a "nice graphical UI" give you for what is fundamentally a text processing problem. Except for the most basic stuff (starting, stopping, setting a breakpoint at a line, looking at a variable value) everything you want to do in gdb involves something approximating a query language: set a watchpoint on the 32 bit quantity stored at this address; dump memory from this pointer; call this function (e.g. strstr() on a memory region) and tell me the result. Watching your code run and hitting a "next" button repeatedly isn't really a good use of the tool.

shocks 14y ago

You should use debugging not only to learn and fix bugs, but also to check your code actually does what you think it does.

agrona 14y ago

gdb is one of those tools that I regret never learning because I've always had an IDE. I was able to follow the examples here well enough, but the array assignment causes gdb to crash in Cygwin. Does anyone have any suggestions for how to overcome that (short of installing a vm & a real linux)?

phao 14y ago

Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize. Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing. And maybe I am wrong, but even the author got mislead by it. "I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic." That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works". I really liked the idea. I just think it may be misleading if the tool you're using is GDB. It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.

AYBABTME 14y ago
That's not undefined, it's simply the bitwise representation of a 32 bits integer.
- phao 14y ago
  C allows more than 1 representation for integers. I know at least 3 possible ones: two's complement, ones' complement and signed magnitude. The "natural wrap up" is not the same in all of the representations. When the integer is unsigned, C gives you more guarantees, but for signed types, you're out of luck, and get to undefined bahvior land. Check this out: http://web.torek.net/torek/c/numbers.html http://web.torek.net/torek/c/numbers.html And as an after note... The maximum int may be less than 2^31-1. Maybe your C implementation decides that your int type will be a 16bits object with values ranging from -2^15 to 2^15-1. In that case, that integer literal would not be an int, and is likely to be a long, and maybe, in this same implementation, a long is a 61bit object ranging from -2^63 to 2^63-1. In that case, that assertion is just plain false. That's not the system exposed in the article though. But it could happen in some other system. This can be true even on a 32bit system.

izx 14y ago

don't forget about panel mode in gdb! ctrl-x, a to toggle it on/off