Why running the next command will jump back to the previous line position

Why running the next command will jump back to the previous line position

[asmwarrior]

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

Re: Why running the next command will jump back to the previous line position

[Jan Kratochvil]

On Sat, 29 Oct 2011 09:11:25 +0200, asmwarrior wrote:
[...]
> 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.

yes, objdump -dSC shows there:

    std::map<int, std::string> m;
  400bab:       48 8d 45 b0             lea    -0x50(%rbp),%rax
  400baf:       48 89 c7                mov    %rax,%rdi
  400bb2:       e8 43 00 00 00          callq  400bfa <std::map<int, std::string, std::less<int>, std::allocator<std::pair<int const, std::string> > >::~map()>
  400bb7:       89 d8                   mov    %ebx,%eax


> My question is: This behavior is quite anti-friendly,

Maybe GCC could produce there DW_LNS_negate_stmt so that the variable
declaration line is still shown in backtraces (if the destructor crashes) but
it is skipped over during stepping/nexting; but GDB currently would not show
such line in backtraces, GCC currently does not produce DW_LNS_negate_stmt
anyway.



Regards,
Jan

Re: Why running the next command will jump back to the previous line position

[asmwarrior]

On 2011-10-29 15:22, Jan Kratochvil wrote:
> On Sat, 29 Oct 2011 09:11:25 +0200, asmwarrior wrote:
> [...]
>> 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.
> 
> yes, objdump -dSC shows there:
> 
>      std::map<int, std::string>  m;
>    400bab:       48 8d 45 b0             lea    -0x50(%rbp),%rax
>    400baf:       48 89 c7                mov    %rax,%rdi
>    400bb2:       e8 43 00 00 00          callq  400bfa<std::map<int, std::string, std::less<int>, std::allocator<std::pair<int const, std::string>  >  >::~map()>
>    400bb7:       89 d8                   mov    %ebx,%eax
> 

Hi, thanks for the reply, I just run the objdump -dSC a.exe under Windows, and I found the similar content. 


So, it looks like the line "std::map<int, std::string>  m;" associates many instruction pieces. Those pieces include the calling of the std::map's destructor.

When leaving the main function body, the instruction piece of the destructor will reached, and gdb just refer to the declaration line. So that gdb put the current source line back to "std::map<int, std::string>  m;" again.

My explanation is right?

> 
>> My question is: This behavior is quite anti-friendly,
> 
> Maybe GCC could produce there DW_LNS_negate_stmt so that the variable
> declaration line is still shown in backtraces (if the destructor crashes) but
> it is skipped over during stepping/nexting; but GDB currently would not show
> such line in backtraces, GCC currently does not produce DW_LNS_negate_stmt
> anyway.
> 

I'm not quite sure what DW_LNS_negate_stmt means, any way, I will forward my question to GCC maillist.

Thanks.

asmwarrior
ollydbg from codeblocks' forum 

Re: Why running the next command will jump back to the previous line position

[Jan Kratochvil]

On Sat, 29 Oct 2011 09:45:41 +0200, asmwarrior wrote:
> When leaving the main function body, the instruction piece of the destructor
> will reached, and gdb just refer to the declaration line. So that gdb put
> the current source line back to "std::map<int, std::string>  m;" again.
> 
> My explanation is right?

yes.


> I'm not quite sure what DW_LNS_negate_stmt means, any way, I will forward my
> question to GCC maillist.

DWARF:
is_stmt
A boolean indicating that the current instruction is a recommended breakpoint
location.  A recommended breakpoint location is intended to “represent” a line,
a statement and/or a semantically distinct subpart of a statement.

I am not convinced myself it is right to hide destructor calls; but I am not
C++ developer.


Regards,
Jan

Re: Why running the next command will jump back to the previous line position

[陳韋任]

> > Maybe GCC could produce there DW_LNS_negate_stmt so that the variable
> > declaration line is still shown in backtraces (if the destructor crashes) but
> > it is skipped over during stepping/nexting; but GDB currently would not show
> > such line in backtraces, GCC currently does not produce DW_LNS_negate_stmt
> > anyway.
> > 
> 
> I'm not quite sure what DW_LNS_negate_stmt means, any way, I will forward my question to GCC maillist.

  GCC should emit debug information so that GDB can work correctly.
You can checkout http://dwarfstd.org/doc/Dwarf3.pdf .

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Re: Why running the next command will jump back to the previous line position

[asmwarrior]

On 2011-10-29 18:39, 陳韋任 wrote:
>>> Maybe GCC could produce there DW_LNS_negate_stmt so that the variable
>>> declaration line is still shown in backtraces (if the destructor crashes) but
>>> it is skipped over during stepping/nexting; but GDB currently would not show
>>> such line in backtraces, GCC currently does not produce DW_LNS_negate_stmt
>>> anyway.
>>>
>>
>> I'm not quite sure what DW_LNS_negate_stmt means, any way, I will forward my question to GCC maillist.
> 
>    GCC should emit debug information so that GDB can work correctly.
> You can checkout http://dwarfstd.org/doc/Dwarf3.pdf .
> 
> Regards,
> chenwj
> 

Well, thanks. It looks like there is a similar gcc bug report.
see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
It looks like at this revision:
http://gcc.gnu.org/viewcvs?view=revision&revision=149722

I have no experience to dig into gcc source.... Hope the GCC guys can help.

asmwarrior
ollydbg from codeblocks' forum