From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb-patches@sources.redhat.com Cc: Mark Kettenis , msnyder@redhat.com Subject: Re: [5.1/breakpoint] shlib patch? Date: Wed, 31 Oct 2001 15:03:00 -0000 Message-id: <3BE074F9.7040902@cygnus.com> References: <3B47384A.3000300@cygnus.com> <3BB2AD4B.1040908@cygnus.com> <200109280939.f8S9dgG00358@delius.kettenis.local> X-SW-Source: 2001-10/msg00413.html So ok. Mark K wrote part of: > Date: Thu, 27 Sep 2001 00:38:35 -0400 > From: Andrew Cagney > > 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. Can someone give me a good reason to not commit this. Trunk and branch ....! While still broken, is it worse than before? Andrew > 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; > > > >