bug#18961: gud Cannot find bounds of current function, but gdb works

[Eli Zaretskii <eliz@gnu.org>]

> 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.