This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Why running the next command will jump back to the previous line position
- From: asmwarrior <asmwarrior at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 29 Oct 2011 22:19:47 +0800
- Subject: Re: Why running the next command will jump back to the previous line position
- References: <4EABA71D.600@gmail.com> <4EABB25B.40208@gmail.com>
On 2011-10-29 15:59, asmwarrior wrote:
> Hi, I have just a question post on GDB maillist, and some gdb guys thought it was related to GCC.
> see: http://sourceware.org/ml/gdb/2011-10/msg00210.html
> so I forward my question to this maillist.
>
> ------------------------------------------------------------------------------
>
> Hi, I'm using MinGW 4.6.2 and GDB cvs head under Windows XP.
>
> When debugging a sample program: (I build it with -g, and no optimization option is used)
>
> #include<string>
> #include<map>
>
> int main()
> {
> std::map<int, std::string> m;
> m[0] = "000";
> m[1] = "111";
> for( int i = 0; i< 3; i++)
> {
> m[i] = "ssss";
> }
> return 0;
> }
>
>
> If I continuously run the command "next" under gdb, I found that when I hit the statement "return 0", if I run "next" again, It will take me backward to the line "std::map<int, std::string> m;". If I run the "next" again, the instruction will go forward the closing bracket of the main function body.
>
> This was quite strange, it looks like the instruction will return to some previous position. (I guess that the destructor of the "std::map" was called.
>
> My question is: This behavior is quite anti-friendly, because if I'm debugging a large function, I always get the instruction line back to where some local variable (automatic variable) was defined.
>
> Is it possible to solve it. I don't want the instruction line go backward when I leave some scope.
>
> Thanks.
>
> asmwarrior
> ollydbg from codeblocks' forum
>
>
>
Hi, all. It looks like some one has report a similar bug on:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
and it has caused by the revision:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149722
Any GCC developer can have look at it?
Thanks.
asmwarrior
ollydbg from codeblocks' forum