This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Breakpoints in dynamically loaded objects
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: Breakpoints in dynamically loaded objects
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 08 May 2000 09:49:15 -0500
- Cc: gdb at sourceware dot cygnus dot com
- References: <200005081343.e48DhHu06845@delius.kettenis.local>
> Right now GDB doesn't gracefully handle breakpoints in dynamically
> loaded objects.
I'm shocked!
I tend to agree that breakpoint_re_set_one shouldn't delete a
shlib_disabled breakpoint just because it can't find the symbol; it
should leave it shlib_disabled.
However, that would mean that, if you're doing shared library work and
you really do rename a function that had a breakpoint set on it, that
old breakpoint will just sit around forever. I'm not sure what to do
with that.
re_enable_breakpoints_in_shlibs looks wrong to me, too. Shlibs can be
loaded at a different address every time, so b->address may not be
valid. Of course, the shlibs that are were specified at link time
will most likely appear at the same address each time, but libraries
loaded by hand may not.
Ideally, re_enable_breakpoints_in_shlibs should do something like what
breakpoint_re_set_one does. But I wouldn't be surprised if simply
calling breakpoint_re_set_one didn't do the job.