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: Huge slowdown since 6.0


On Fri, Feb 20, 2004 at 01:45:40PM -0500, Andrew Cagney wrote:
> >On Fri, Feb 20, 2004 at 01:07:46PM -0500, Andrew Cagney wrote:
> >
> >>>Even if we start out with on-demand, it should work better.  Given:
> >>>
> >>>	$ gdb foo
> >>>	(gdb) break main
> >>>	(gdb) run
> >>>
> >>>why is GDB loading glibc's symbols?
> >
> >
> >Main might be a function defined in a shared library.  Even if we found
> >a definition in the executable, it might be a PLT loading slot.  KDE
> >on i386 will demonstrate this exact behavior.
> 
> It's been suggested to me that we should create a hacked gdb that 
> records all commands et.al. to a file, and then offers to send them to 
> us.  That way we know what is, rather than what might be.
> 
> If we knew for instance that only 10% of users set breakpoints outside 
> of the main executible, then we'd also know that we were frustrating 90% 
> of users by making them sit around waiting for needless symbol table 
> reads :-(
> 
> On the other hand, if we knew that the first thing people did was:
> 	(gdb) break <tab>
> we'd have an entirely different problem.

My point is that whether or not "break main" shows up as resolving to
the main executable, to get it right in the general case, we also need
shared library symbols.  I discussed this at length in the last thread
about multiple-address breakpoints.  For main in particular maybe it's
a non-issue, but not for any other function.

-- 
Daniel Jacobowitz
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]