[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18961: gud Cannot find bounds of current function, but gdb works
From: |
Eli Zaretskii |
Subject: |
bug#18961: gud Cannot find bounds of current function, but gdb works |
Date: |
Thu, 06 Nov 2014 18:12:43 +0200 |
> Date: Wed, 5 Nov 2014 23:26:56 +0300
> From: Evgeniy Dushistov <dushistov@mail.ru>
>
> I try debug such simple C++ code(
> from here: http://www.boost.org/doc/libs/1_55_0/libs/tokenizer/introduc.htm):
>
> #include<iostream>
> #include<boost/tokenizer.hpp>
> #include<string>
>
> int main(){
> using namespace std;
> using namespace boost;
> string s = "This is, a test";
> tokenizer<> tok(s);
> for(tokenizer<>::iterator beg=tok.begin(); beg!=tok.end();++beg){
> cout << *beg << "\n";
> }
> }
>
> compiled with "g++ -Wall -ggdb test.cpp".
You should use "-ggdb -g3" for better results. (Actually, -ggdb
should be redundant with modern GCC versions. But -g3 is still highly
recommended.)
> using "Next Line" I reach
> for(tokenizer<>::iterator beg=tok.begin(); beg!=tok.end();++beg)
> and the I use "Step Line"
> class iterator_facade in /usr/include/boost/iterator/iterator_facade.hpp,
> after that "Step Line" stop working,
> and gud says "Cannot find bounds of current function",
This message comes from GDB, not from Emacs.
Anyway, I cannot reproduce this problem, stepping by clicking the Step
Line button works for me with that example Boost program.
I used GDB 7.8, so I suggest that you upgrade your GDB and try again.
Debugging of C++ programs gets significant improvements with each GDB
release, so using the latest one (GDB 7.8.1 was released a few days
ago) is recommended.
I also used the latest Boost, but I doubt that this could be the
reason.
> But if I run the same binary in gdb without emacs mediation,
> and use step on the same line, all works fine, I can step until
> the end of program, also simple script like this reach the end of main
> without any problems in plain gdb:
Please note that Emacs generally uses somewhat different commands, not
the ones you'd use from CLI, and also sends a lot of commands to GDB
to receive the state of the debuggee, so comparison with CLI sessions
are not always the way to blame Emacs.