This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/457: GDB runs slow (internal doco needed) (FAQ)
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: Andrew Cagney <ac131313 at cygnus dot com>, gdb at sources dot redhat dot com
- Date: Thu, 4 Apr 2002 13:49:49 -0500
- Subject: Re: gdb/457: GDB runs slow (internal doco needed) (FAQ)
- References: <20020404165802.6629.qmail@sources.redhat.com> <3CAC91A0.3000702@cygnus.com> <1020404184426.ZM28992@localhost.localdomain>
On Thu, Apr 04, 2002 at 11:44:27AM -0700, Kevin Buettner wrote:
> On Apr 4, 12:47pm, Andrew Cagney wrote:
>
> > >> Related to the above. Being able to identify just the information that changed so that GUI refresh operations are limited to areas that need an update. See varobj.[ch].
> > > > > If profiling GDB to improve performance it is important to look
> > > > beyond the raw numbers (some one line pid/tid functions come up as
> > > > ``hot spots'') and more at the overall picture (the thread_info
> > > > object should be used). Replacing apparently hot functions with
> > > > macros isn't an option.
> > >
> > > If the thread_info object is used, we're still going to have all the
> > > little accessor functions. Why the categorical objection to macros?
> > > Especially in places that they would especially benefit compiler
> > > performance, like one-line accessor macros? And even more so since GDB
> > > will soon support better macro debugging...
> >
> > I'll be ok with macro's when you can step into them, print their local
> > (macro) variables, ensure (using compiler warnings) that the user can't
> > grub a round directly in the object the macro is wrapping, not have any
> > side effects, not have pass by name problems, ....
> > Even static functions in headers are less evil than macros.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Hmm...
>
> Jim Blandy recently added an autoconf test for ``inline'', right? I'm
> wondering if it'd be possible to define functions like ptid_get_pid()
> as being inline (in a header file like defs.h)?
I was just thinking the same thing :)
> --- time passes ---
>
> I've done a bit more checking. It appears that autoconf defines ``inline''
> as follows when it's not supported by the compiler:
>
> #define inline
>
> I think it might work if it were defined like this instead:
>
> #define inline static
No, it's simpler than that. You define the functions in headers as
'static inline'. I think that works quite far back along the train of
C history.
Now, I could easily check what difference it made if the profile
patches had ever made it into GDB...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer