Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: ac131313@cygnus.com, msnyder@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [5.1/breakpoint] shlib patch?
Date: Fri, 28 Sep 2001 02:39:00 -0000	[thread overview]
Message-ID: <200109280939.f8S9dgG00358@delius.kettenis.local> (raw)
In-Reply-To: <3BB2AD4B.1040908@cygnus.com>

   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;



  reply	other threads:[~2001-09-28  2:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-07  9:26 Andrew Cagney
     [not found] ` <200107082216.f68MGg824625@delius.kettenis.local>
2001-07-12 12:32   ` Mark Kettenis
2001-09-26 21:38 ` Andrew Cagney
2001-09-28  2:39   ` Mark Kettenis [this message]
2001-10-31 15:03     ` Andrew Cagney
     [not found]       ` <s3ik7xaksip.fsf@soliton.wins.uva.nl>
     [not found]         ` <3BEA11C9.9020702@cygnus.com>
2001-11-01  6:45           ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200109280939.f8S9dgG00358@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=ac131313@cygnus.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox