This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [5.1/breakpoint] shlib patch?
- To: gdb-patches at sources dot redhat dot com
- Subject: Re: [5.1/breakpoint] shlib patch?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 31 Oct 2001 17:02:33 -0500
- Cc: Mark Kettenis <kettenis at wins dot uva dot nl>, msnyder at redhat dot com
- References: <3B47384A.3000300@cygnus.com> <3BB2AD4B.1040908@cygnus.com> <200109280939.f8S9dgG00358@delius.kettenis.local>
So ok. Mark K wrote part of:
> 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.
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;
>
>
>
>