5 ms·
Thanks for the link to `call_function_by_hand`, that's super helpful! In retrospect, I could have found this file by grepping for 'When the function is done exe
by jvns 9y ago
Thanks for the link to `call_function_by_hand`, that's super helpful! In retrospect, I could have found this file by grepping for 'When the function is done executing, GDB will silently stop' (the very useful "grep for UI text" trick!)
the choice between whether to try to understand something by running or by reading the code is a super interesting one (though if I'm seriously interested in understanding exactly what some software does of course I'll do both!).
I think experimentation/stracing a program to understand it has a lot of advantages:
* It can be helpful to look at the system calls as a way to maybe see the big picture before diving into the code.("ok, it's setting some registers somehow, it's putting in some int3 instructions, then it does PTRACE_CONT, then it undoes all the changes it made").
* it lets me focus on what the program actually does instead of understanding how the code is organized (figuring out how the code in a large project I've never looked at before is organized can be time consuming!)
* It's easy to make incorrect conclusions when reading the source. This happens to me a lot when reading distributed systems code -- often I'll think "ok, if I do X, then Y will happen" but that turns out not to be true in practice. So I think even when you are reading code, doing experimentation as you go is a key part of making sure that your understanding of the code is actually correct.
* I find exploring programs interactively fun!
In this specific example -- I think it's really interesting that gdb modifies the `longjmp` function in libc when running a function. The string `longjmp` doesn't appear anywhere in infcall.c. So even though reading infcall.c seems like a great overview, it just has different information that I get from using strace!
- simias 9y agoI see where you're coming from, in the past I've gdb'd... gdb itself to figure out an obscure bug. It gets a bit confusing at times (better use different prompts at least) but this way you could step through the debugger's code itself instead of deciphering strace's output for instance.
- mmjaa 9y ago>very useful "grep for UI text" trick Just, one thing: for C/C++ code-bases such as gdb, stop using grep for things, people! Use cscope! 'tis a brilliant means of navigating files and scoping out the contents of a project. http://cscope.sourceforge.net http://cscope.sourceforge.net $ cd gdb/src; cscope -R
- dahart 9y agoLooks handy! I think I'll start using it for a few things. But, I probably won't stop using grep, these tools don't really compete.
- mmjaa 9y agoOoh, grep is definitely useful, no question .. but cscope, in the right hands, can be far, far more productive .. try it and see!
- cryptonector 9y agocscope is a sine qua non of C (and even C++ and Java) development. Of course, with OOP languages a dumb lexical indexer is not that useful (this applies to OpenGrok and many others too) -- if you're looking for calls to the getName() method of a particular class (and sub-classes) in a huge codebase then you'll be in for a lot of pain. But for C cscope is absolutely fantastic and much much better than etags/ctags.
- bch 9y agoI use cscope in conjunction w ctags. cscope (which will launch an editor, appropriately ) for a top-level overview/dive, and ctags (from w/i my vi instance, whether vi was launched from cscope or not) when I’m zeroing-in on a problem and can chase down thoughts and maintain my way back out because navigation is pushing/popping on a stack. No need for either/or; use them both.
- mmjaa 9y agoI find that cscope integration in vim supersedes any need for ctags. For why is ctags not just a subset?
- bch 9y agoI'm a BSD nvi user, so no vim for me. I do apparently have access to cscope database from w/i nvi, but my finger muscle memory wrt (ex)ctags support gets me a long way (perhaps I could do better w/ cscope? Something to look into.) I'm not sure how to parse your last question -- rephrase ?
- ratboy666 9y agolongjmp() (and friends) is trapped because it causes a non-local transfer of control. Basically, it can go anywhere. the "p foo()" would then not return to the prompt. What we know is that longjmp() will leave the function (it goes to where the setjmp() was called from). Also, look into libffi for how to call a C function by building a call.