This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoints with shared lib. support.
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: ramana at codito dot com
- Cc: gdb at sources dot redhat dot com, jimb at redhat dot com, ac131313 at redhat dot com,saurabh dot verma at codito dot com, ankit dot thukral at codito dot com,mark dot newman at lmco dot com
- Date: Wed, 1 Oct 2003 10:09:08 -0400
- Subject: Re: Tracepoints with shared lib. support.
- References: <1064924214.3808.157.camel@numenor.codito.co.in> <20030930125017.GA23342@nevyn.them.org> <1065006023.3808.300.camel@numenor.codito.co.in>
On Wed, Oct 01, 2003 at 04:30:23PM +0530, Ramana Radhakrishnan wrote:
> hi all,
>
> Another query i had was regarding tracepoints on shared library
> symbols. That would also have to be handled in a manner similar to the
> way in which the breakpoints for shared libraries have been implemented.
> I wonder if we need internal breakpoints on the shared library event
> handling which would then take care of mapping the addresses to the
> actual addresses because with the current status of tracepoints the
> addresses do not get mapped to the actual addresses. So if we had a
> tracepoint on a function in a shared library would we then not be
> increasing the number of halts in the actual execution of the program.
Well, tracepoints haven't been made to work with shared libraries yet,
that's true. But it should be possible to enable/disable/move them at
the same time as breakpoints. There are always stops when loading a
shared library, and you'll have a whole lot of work cut out for you if
you want to change that. So the tracepoints don't increase the number
of halts.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer