From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Cc: Mark Kettenis <kettenis@wins.uva.nl>, msnyder@redhat.com
Subject: Re: [5.1/breakpoint] shlib patch?
Date: Wed, 31 Oct 2001 15:03:00 -0000 [thread overview]
Message-ID: <3BE074F9.7040902@cygnus.com> (raw)
In-Reply-To: <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;
>
>
>
>
next prev parent reply other threads:[~2001-10-31 15:03 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
2001-10-31 15:03 ` Andrew Cagney [this message]
[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=3BE074F9.7040902@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kettenis@wins.uva.nl \
--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