gdb/457: GDB runs slow (internal doco needed) (FAQ)

[Kevin Buettner]

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)?

--- 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

Kevin