From: "H . J . Lu" <hjl@lucon.org>
To: Michael Veksler <veksler@il.ibm.com>
Cc: gdb@sources.redhat.com, Andrew Cagney <ac131313@cygnus.com>
Subject: Re: gdb 5.2 removes the conditional breakpoints
Date: Wed, 17 Apr 2002 16:57:00 -0000 [thread overview]
Message-ID: <20020417165756.A6417@lucon.org> (raw)
In-Reply-To: <3CB3EF53.80608@il.ibm.com>; from veksler@il.ibm.com on Wed, Apr 10, 2002 at 10:52:51AM +0300
On Wed, Apr 10, 2002 at 10:52:51AM +0300, Michael Veksler wrote:
> /References/: <20020322095020.A12445@lucon.org
> <http://sources.redhat.com/ml/gdb/2002-03/msg00196.html> >
> <3C9B76F5.6050809@cygnus.com
> <http://sources.redhat.com/ml/gdb/2002-03/msg00198.html> >
>
>
> On Fri, Mar 22, 2002 at 01:24:53PM -0500, Andrew Cagney wrote:
> > > When I do
> > >
> > > (gdb) b 100
> > > (gdb) cond 1 i == 3
> > > (gdb) r
> > > (gdb) r
> > >
> > > gdb 5.2 will remove the conditional breakpoints on Linux/x86 after I
> > > restart the debug session. Am I the only one who sees it?
> >
> > It would be very helpful if you could illustrate this problem by
> > submitting a real testcase. That way people can run it and check
> > before/after effects on various platforms and GDB releases.
> >
>
> Here are the instructions for reproducing this annoying problem:
>
> // Debugged source:
> typedef int operation(int val);
>
> int f(operation * op, int value)
> {
> return op(value);
> }
>
> int nop(int val)
> {
> return val;
> }
>
> int main()
> {
> return f(nop, 5);
> }
> // End source
>
> Compile it on Linux using gcc 3.0.4 or redhat's 2.96 (did not test it
> on other versions).
> (gdb) b main
> (gdb) r
> Breakpoint 1, main () at t.c:15
> 15 return f(nop, 5);
> (gdb) s
> f (op=0x8048448 <nop>, value=5) at t.c:5
> 5 return op(value);
> (gdb) b
> Breakpoint 2 at 0x8048432: file t.c, line 5.
Thanks for the testcase. Basically, we deleted all break points set
with "break" when we restart. It is a very bad regression from gdb
4.17. Here is a patch. May I check it into gdb 5.2?
Thanks.
H.J.
----
2002-04-17 H.J. Lu (hjl@gnu.org)
* breakpoint.c (create_thread_event_breakpoint): Use xasprintf.
(create_breakpoints): Make sure the addr_string field is not
NULL.
--- gdb/breakpoint.c.break Wed Mar 6 22:30:42 2002
+++ gdb/breakpoint.c Wed Apr 17 16:50:18 2002
@@ -3859,14 +3859,12 @@ struct breakpoint *
create_thread_event_breakpoint (CORE_ADDR address)
{
struct breakpoint *b;
- char addr_string[80]; /* Surely an addr can't be longer than that. */
b = create_internal_breakpoint (address, bp_thread_event);
b->enable_state = bp_enabled;
/* addr_string has to be used or breakpoint_re_set will delete me. */
- sprintf (addr_string, "*0x%s", paddr (b->address));
- b->addr_string = xstrdup (addr_string);
+ xasprintf (&b->addr_string, "*0x%s", paddr (b->address));
return b;
}
@@ -4422,7 +4420,10 @@ create_breakpoints (struct symtabs_and_l
b->number = breakpoint_count;
b->cond = cond[i];
b->thread = thread;
- b->addr_string = addr_string[i];
+ if (addr_string[i])
+ b->addr_string = addr_string[i];
+ else
+ xasprintf (&b->addr_string, "%s:%d", b->source_file, b->line_number);
b->cond_string = cond_string[i];
b->ignore_count = ignore_count;
b->enable_state = bp_enabled;
next prev parent reply other threads:[~2002-04-17 23:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-10 0:52 Michael Veksler
2002-04-17 16:57 ` H . J . Lu [this message]
2002-04-17 17:33 ` PATCH: Fix restarting breakpoint (Re: gdb 5.2 removes the conditional breakpoints) H . J . Lu
2002-04-17 17:34 ` gdb 5.2 removes the conditional breakpoints Andrew Cagney
2002-04-17 17:48 ` H . J . Lu
2002-04-17 20:20 ` Andrew Cagney
-- strict thread matches above, loose matches on Subject: below --
2002-04-17 23:40 Michael Veksler
2002-04-18 3:11 ` Eli Zaretskii
2002-04-18 9:31 ` H . J . Lu
2002-04-18 10:22 ` Daniel Jacobowitz
2002-04-18 10:34 ` H . J . Lu
2002-04-18 10:41 ` Daniel Jacobowitz
2002-04-18 9:42 ` H . J . Lu
2002-03-22 9:50 H . J . Lu
2002-03-22 10:24 ` Andrew Cagney
2002-03-22 10:45 ` H . J . Lu
2002-03-22 10:27 ` Daniel Jacobowitz
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=20020417165756.A6417@lucon.org \
--to=hjl@lucon.org \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=veksler@il.ibm.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