Re: [5.1/breakpoint] shlib patch?

Mark Kettenis
2001-09-28T02:39:00Z

Date: Thu, 27 Sep 2001 00:38:35 -0400
From: Andrew Cagney <ac131313@cygnus.com>

Just FYI,

This is probably the 5.1 release hack candidate (in branch, not in
trunk). Every release has one ... Unless someone comes up with
something that is.

And a hack it is, although Apple's Darwin version of GDB contains an
almost identical hack to implement a "future break" command. It seems
to work in many real world cases, but it is easy to come up with a
test case where the patch doesn't help at all.

It seems that the way GDB implements breakpoints-in-shared-libraries
was designed for a.out shared library systems (SunOS 4) where shared
libraries were loaded at a fixed address in memory. Since ELF shared
libraries can (and will) be loaded at any address in memory, things
break. Fixing this is not trivial. Therefore, I'm not sure whether
we should add this hack to the branch only. I cannot guarantee that
things will be fixed on the trunk in the near future.

Anyway, for reference I attached the hack.

Mark

Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.53
diff -u -p -r1.53 breakpoint.c
--- breakpoint.c 2001/09/18 05:00:48 1.53
+++ breakpoint.c 2001/09/28 09:27:52
@@ -7009,10 +7009,14 @@ breakpoint_re_set_one (PTR bint)
delete_breakpoint (b);
return 0;
}
- /* In case we have a problem, disable this breakpoint. We'll restore
- its status if we succeed. */
+ /* In case we have a problem, disable this breakpoint. We'll
+ restore its status if we succeed. Don't disable a
+ shlib_disabled breakpoint though. There's a fair chance we
+ can't re-set it if the shared library it's in hasn't been
+ loaded yet. */
save_enable = b->enable_state;
- b->enable_state = bp_disabled;
+ if (b->enable_state != bp_shlib_disabled)
+ b->enable_state = bp_disabled;

set_language (b->language);
input_radix = b->input_radix;