Re: Breakpoint when entering of functions on i386

Re: Breakpoint when entering of functions on i386

[yichun wang]

Hi,

I'm now working on a script which will print calling graph by stepping
through program with GDB. The script actually works fine in some small
cases, but one big performance bottleneck is that I used "watch $ebp"
to catch the happening of function call, and it will become really
slow when in some cases, local variable/arguments are heavily used. So
my question is:

    Is there any better way in GDB to capture function call event?

Thanks,
-Yichun.

Re: Breakpoint when entering of functions on i386

[Michael Snyder]

On Mon, 2007-11-26 at 15:10 +0800, yichun wang wrote:
> Hi,
> 
> I'm now working on a script which will print calling graph by stepping
> through program with GDB. The script actually works fine in some small
> cases, but one big performance bottleneck is that I used "watch $ebp"
> to catch the happening of function call, and it will become really
> slow when in some cases, local variable/arguments are heavily used. So
> my question is:
> 
>     Is there any better way in GDB to capture function call event?

What about just setting breakpoints on all functions?

That way, if there is a way to define an "interesting subset"
of functions, you can limit your breakpoints to that subset, 
and save a lot of time.

Re: Breakpoint when entering of functions on i386

[yichun wang]

Thanks Michael,  to define an "interesting subset" should improve the
performance , but I need generate call graph for many different
applications, and this script won't have any knowledge of the
application, so this might not work...

Thanks,
-Yichun.

On Nov 27, 2007 2:10 AM, Michael Snyder <msnyder@specifix.com> wrote:
>
> On Mon, 2007-11-26 at 15:10 +0800, yichun wang wrote:
> > Hi,
> >
> > I'm now working on a script which will print calling graph by stepping
> > through program with GDB. The script actually works fine in some small
> > cases, but one big performance bottleneck is that I used "watch $ebp"
> > to catch the happening of function call, and it will become really
> > slow when in some cases, local variable/arguments are heavily used. So
> > my question is:
> >
> >     Is there any better way in GDB to capture function call event?
>
> What about just setting breakpoints on all functions?
>
> That way, if there is a way to define an "interesting subset"
> of functions, you can limit your breakpoints to that subset,
> and save a lot of time.
>
>
>
>

Re: Breakpoint when entering of functions on i386

[Joel Brobecker]

> Thanks Michael,  to define an "interesting subset" should improve the
> performance , but I need generate call graph for many different
> applications, and this script won't have any knowledge of the
> application, so this might not work...

Is there a reason why you have to use GDB instead of a more specialized
tool?

-- 
Joel

Re: Breakpoint when entering of functions on i386

[yichun wang]

GDB is easy to interact and control, for example, one feature of my
script is to start print calling graph after hit some function (just a
breakpoint),  or to print the value of arguments. It can simply give
you many controls of program, for source level to assembly level, with
little programming job.

Other tools could be also possible, for example, a plugin to
valgrind/callgrind will also work, but it may require more knowledge
and programming. Currently I'm using perl+gdb, except performance, the
script works just fine.

-Yichun.

On Nov 27, 2007 3:25 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> > Thanks Michael,  to define an "interesting subset" should improve the
> > performance , but I need generate call graph for many different
> > applications, and this script won't have any knowledge of the
> > application, so this might not work...
>
> Is there a reason why you have to use GDB instead of a more specialized
> tool?
>
> --
> Joel
>

Re: Breakpoint when entering of functions on i386

[Michael Snyder]

On Mon, 2007-11-26 at 23:25 -0800, Joel Brobecker wrote:
> > Thanks Michael,  to define an "interesting subset" should improve the
> > performance , but I need generate call graph for many different
> > applications, and this script won't have any knowledge of the
> > application, so this might not work...
> 
> Is there a reason why you have to use GDB instead of a more specialized
> tool?

GDB is the swiss army knife of software development.
;-)

Re: Breakpoint when entering of functions on i386

[Joel Brobecker]

> GDB is the swiss army knife of software development.
> ;-)

Yeah, but then you have to accept sometimes that it won't be as sharp
as a chef's knife :-).

-- 
Joel

Re: Breakpoint when entering of functions on i386

[Michael Snyder]

On Tue, 2007-11-27 at 13:04 -0800, Joel Brobecker wrote:
> > GDB is the swiss army knife of software development.
> > ;-)
> 
> Yeah, but then you have to accept sometimes that it won't be as sharp
> as a chef's knife :-).

Nor as heavy as a sledge hammer.  But then, it's sharper than
a sledge hammer, and sometimes all you have is a swiss army 
knife.

Re: Breakpoint when entering of functions on i386

[Joel Brobecker]

> > Yeah, but then you have to accept sometimes that it won't be as sharp
> > as a chef's knife :-).
> 
> Nor as heavy as a sledge hammer.  But then, it's sharper than
> a sledge hammer, and sometimes all you have is a swiss army 
> knife.

Right - Just to be clear, I wasn't trying to imply that GDB shouldn't be
used in this case, but making sure that the user was aware of other more
specialized options that may (or not) work better for him.

-- 
Joel