This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]