This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [5.1/breakpoint] shlib patch?


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;
> 
> 
> 
> 



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]