GDB steping into STL Headers.

GDB steping into STL Headers.

[mweglicki8208]

Hello, 

Is there a way to disable stepping into a STL headers? This is what is
happening: 

std::string test = "New string"; 


And i have a lot of calls from stl headers like: 
(gdb) step
671    
/opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h:
No
        in
/opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h


Is it possible to void it? So for example next will allways step into next
line of code that i wish to debug?
-- 
View this message in context: http://old.nabble.com/GDB-steping-into-STL-Headers.-tp27535106p27535106.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: GDB steping into STL Headers.

[Hui Zhu]

Try next?

On Thu, Feb 11, 2010 at 01:38, mweglicki8208 <mweglicki@gmail.com> wrote:
>
> Hello,
>
> Is there a way to disable stepping into a STL headers? This is what is
> happening:
>
> std::string test = "New string";
>
>
> And i have a lot of calls from stl headers like:
> (gdb) step
> 671
> /opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h:
> No
>        in
> /opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h
>
>
> Is it possible to void it? So for example next will allways step into next
> line of code that i wish to debug?
> --
> View this message in context: http://old.nabble.com/GDB-steping-into-STL-Headers.-tp27535106p27535106.html
> Sent from the Sourceware - gdb list mailing list archive at Nabble.com.
>
>

Re: GDB steping into STL Headers.

[mweglicki8208]

mweglicki8208 wrote:
> So for example next will allways step

Of course I tried next. But in this respect it behaves the same as "step".
Maybe there is something wrong with my gdb configuration....



mweglicki8208 wrote:
> 
> Hello, 
> 
> Is there a way to disable stepping into a STL headers? This is what is
> happening: 
> 
> std::string test = "New string"; 
> 
> 
> And i have a lot of calls from stl headers like: 
> (gdb) step
> 671    
> /opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h:
> No
>         in
> /opt/gcc/linux64/ix86/gcc_3.4.5-2p2/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_list.h
> 
> 
> Is it possible to void it? So for example next will allways step into next
> line of code that i wish to debug?
> 

-- 
View this message in context: http://old.nabble.com/GDB-steping-into-STL-Headers.-tp27535106p27542787.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Obtaining number of children of a dynamic varobj

[Elmenthaler, Jens]

Hi,

Trying to enable the python pretty printers in the Eclipse CDT, a question about the MI API for varobjs arose.

If I read the documentation correctly, I should not call -var-list-children without the range of children, because in general I should assume that the varobj has a huge number of children and fetching them all is potential too expensive.

Quite reasonable sofar. Nevertheless, I have the problem that I have to know the number of children a dynamic varobj has.

The only way I see to obtain the number of children, however, is to call -var-list-children without a range specification. I can omit the values to be transferred. Does that have the same scalability issues, after all it still creates a varobj for each child?

Jens.

Re: Obtaining number of children of a dynamic varobj

[Vladimir Prus]

Elmenthaler, Jens wrote:

> Hi,
> 
> Trying to enable the python pretty printers in the Eclipse CDT, a question about the MI API for
> varobjs arose.
> 
> If I read the documentation correctly, I should not call -var-list-children without the range of
> children, because in general I should assume that the varobj has a huge number of children and
> fetching them all is potential too expensive.
> 
> Quite reasonable sofar. Nevertheless, I have the problem that I have to know the number of
> children a dynamic varobj has.
> 
> The only way I see to obtain the number of children, however, is to call -var-list-children
> without a range specification. I can omit the values to be transferred. Does that have the same
> scalability issues, after all it still creates a varobj for each child?

[Please do not ask new questions by replying to an unrelated email]

Yes, it has the same issues. If you ask GDB about the number of children of a variable, and the
variable is uninitialized, GDB might not ever return. 

- Volodya

Re: GDB steping into STL Headers.

[Tom Tromey]

>>>>> ">" == mweglicki8208  <mweglicki@gmail.com> writes:

[ "next" ]
>> Of course I tried next. But in this respect it behaves the same as "step".
>> Maybe there is something wrong with my gdb configuration....

That is surprising, since "next" should step over calls.

Anyway, no, there is no way in gdb to disable stepping into certain
calls.  This feature is requested fairly frequently, but so far nobody
has worked on implementing it.

This is also http://sourceware.org/bugzilla/show_bug.cgi?id=8287

FWIW I think this would be a good feature to have.

Tom

Re: GDB steping into STL Headers.

[Jim Ingham]

It sounds like the STL code got inlined?  Then next would also step in, since gdb doesn't see inlined functions as new frames.

Jim

On Feb 11, 2010, at 9:56 AM, Tom Tromey wrote:

>>>>>> ">" == mweglicki8208  <mweglicki@gmail.com> writes:
> 
> [ "next" ]
>>> Of course I tried next. But in this respect it behaves the same as "step".
>>> Maybe there is something wrong with my gdb configuration....
> 
> That is surprising, since "next" should step over calls.
> 
> Anyway, no, there is no way in gdb to disable stepping into certain
> calls.  This feature is requested fairly frequently, but so far nobody
> has worked on implementing it.
> 
> This is also http://sourceware.org/bugzilla/show_bug.cgi?id=8287
> 
> FWIW I think this would be a good feature to have.
> 
> Tom

Re: GDB steping into STL Headers.

[Daniel Jacobowitz]

On Thu, Feb 11, 2010 at 11:03:08AM -0800, Jim Ingham wrote:
> It sounds like the STL code got inlined?  Then next would also step
> in, since gdb doesn't see inlined functions as new frames.

Maybe your GDB doesn't :-P  GDB 7.0 does support inlined functions -
if your compiler outputs correct DWARF, at least.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB steping into STL Headers.

[Jim Ingham]

Hey, cool.  Our gdb's been doing that for a couple of years now, glad you caught up :-D

Jim

On Feb 11, 2010, at 11:09 AM, Daniel Jacobowitz wrote:

> On Thu, Feb 11, 2010 at 11:03:08AM -0800, Jim Ingham wrote:
>> It sounds like the STL code got inlined?  Then next would also step
>> in, since gdb doesn't see inlined functions as new frames.
> 
> Maybe your GDB doesn't :-P  GDB 7.0 does support inlined functions -
> if your compiler outputs correct DWARF, at least.
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: GDB steping into STL Headers.

[mweglicki8208]

So could explain how should i give my compiler information not to pass those
inline calls information? Is it possible? 

It's quite confusing, getting through simple line, with so many GDB "calls". 

I'm using older version of gcc actually and i can't change it...( 3.4.5 ). 

I understand that I'm quite new to the subject, and it has to be irritating
to answer same questions all the time...But at least please point me into
right direction. 

Thanks for help. 




Jim Ingham wrote:
> 
> Hey, cool.  Our gdb's been doing that for a couple of years now, glad you
> caught up :-D
> 
> Jim
> 
> On Feb 11, 2010, at 11:09 AM, Daniel Jacobowitz wrote:
> 
>> On Thu, Feb 11, 2010 at 11:03:08AM -0800, Jim Ingham wrote:
>>> It sounds like the STL code got inlined?  Then next would also step
>>> in, since gdb doesn't see inlined functions as new frames.
>> 
>> Maybe your GDB doesn't :-P  GDB 7.0 does support inlined functions -
>> if your compiler outputs correct DWARF, at least.
>> 
>> -- 
>> Daniel Jacobowitz
>> CodeSourcery
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/GDB-steping-into-STL-Headers.-tp27535106p27560876.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: GDB steping into STL Headers.

[Christophe-Marie Duquesne]

On Fri, Feb 12, 2010 at 10:32 AM, mweglicki8208 <mweglicki@gmail.com> wrote:
>
> So could explain how should i give my compiler information not to pass those
> inline calls information? Is it possible?
>
> It's quite confusing, getting through simple line, with so many GDB "calls".
>
> I'm using older version of gcc actually and i can't change it...( 3.4.5 ).
>
> I understand that I'm quite new to the subject, and it has to be irritating
> to answer same questions all the time...But at least please point me into
> right direction.
>
> Thanks for help.
>
>
>
>
> Jim Ingham wrote:
>>
>> Hey, cool.  Our gdb's been doing that for a couple of years now, glad you
>> caught up :-D
>>
>> Jim
>>
>> On Feb 11, 2010, at 11:09 AM, Daniel Jacobowitz wrote:
>>
>>> On Thu, Feb 11, 2010 at 11:03:08AM -0800, Jim Ingham wrote:
>>>> It sounds like the STL code got inlined?  Then next would also step
>>>> in, since gdb doesn't see inlined functions as new frames.
>>>
>>> Maybe your GDB doesn't :-P  GDB 7.0 does support inlined functions -
>>> if your compiler outputs correct DWARF, at least.
>>>
>>> --
>>> Daniel Jacobowitz
>>> CodeSourcery
>>
>>
>>
>
>

Please read the manual:
http://sourceware.org/gdb/current/onlinedocs/gdb/Inline-Functions.html

"For gdb to support inlined functions, the compiler must record
information about inlining in the debug information — gcc using the
dwarf 2 format does this, and several other compilers do also. gdb
only supports inlined functions when using dwarf 2. Versions of gcc
before 4.1 do not emit two required attributes (`DW_AT_call_file' and
`DW_AT_call_line'); gdb does not display inlined function calls with
earlier versions of gcc. It instead displays the arguments and local
variables of inlined functions as local variables in the caller. "

I guess you have two solutions:
1 ) Update your compiler to gcc-4.4.3
2 ) Tell your compiler *not* to inline function, using -fno-inline

-- 
Christophe-Marie Duquesne
06 84 14 26 82 - mobile
04 76 57 48 06 - g-scop
04 97 04 27 33 - amadeus