Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Don't reset watchpoint block on solib load.
Date: Wed, 28 Nov 2007 22:37:00 -0000	[thread overview]
Message-ID: <m3r6iauhe4.fsf@codesourcery.com> (raw)
In-Reply-To: <200711282304.16403.vladimir@codesourcery.com> (Vladimir Prus's message of "Wed, 28 Nov 2007 23:04:16 +0300")


Vladimir Prus <vladimir at codesourcery.com> writes:
>> The steps I wrote don't address the case of watchpoints that aren't
>> frame-relative.  I wonder how we should be dealing with those.
>> 
>> If we have a watchpoint on a static variable local to some file or
>> block, then I don't honestly see how we can possibly re-set it
>> correctly after a symbol reload with the data we have now.  We can't
>> tell whether b->exp_valid_block is a dangling pointer or not, and
>> b->watchpoint_frame will be null on such watchpoints.
>
> I haven't run into any case when b->exp_valid_block is not-NULL,
> but b->watchpoint_frame is NULL.

By 'dangling pointer', I mean that it's referring to a block that was
freed when we freed the objfile it belongs to.  My point was just that
neither of those fields would be useful in addressing the problem I
described.

> In fact, we don't need to care about blocks for global watchpoints --
> just like ordinary breakpoint on 'foo' does not care which shared library
> 'foo' comes from, global watchpoint on 'important_data_structure' need
> not care about where that variable comes from. If we re-parse watchpoint
> expression on each solib load, things are fine.

Our messages crossed paths: I think we should worry about re-parsing
global watchpoints in the proper scope.

For example, we do take care to remember which function breakpoints
refer to when there is more than one possible referent.  In the
transcript below, note that the breakpoint set on the static 'foo' in
t2.c, as opposed to the global 'foo' in t1.c, remains there even when
we re-read the main executable.

Watchpoints should behave the same way.

  $ cat t1.c
  #include <stdio.h>

  void bar (void);

  void
  foo (void)
  {
    puts ("t1.c: foo");
  }

  int
  main (int argc, char **argv)
  {
    foo ();
    bar ();

    return 0;
  }

  $ cat t2.c
  #include <stdio.h>

  static void 
  foo (void)
  {
    puts ("t2.c: foo");
  }


  void
  bar (void)
  {
    foo ();
  }
  $ gcc -g t1.c t2.c -o t
  $ ~/gdb/pub/bin/gdb t
  GNU gdb 6.7.50.20071127-cvs
  Copyright (C) 2007 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) break bar
  Breakpoint 1 at 0x80483de: file t2.c, line 13.
  (gdb) run
  Starting program: /home/jimb/play/t 
  t1.c: foo

  Breakpoint 1, bar () at t2.c:13
  13        foo ();
  (gdb) break foo
  Breakpoint 2 at 0x80483ca: file t2.c, line 6.
  (gdb) i br
  Num     Type           Disp Enb  Address    What
  1       breakpoint     keep y    0x080483de in bar at t2.c:13
          breakpoint already hit 1 time
  2       breakpoint     keep y    0x080483ca in foo at t2.c:6
  (gdb) c
  Continuing.

  Breakpoint 2, foo () at t2.c:6
  6         puts ("t2.c: foo");
  (gdb) shell touch t
  (gdb) run
  The program being debugged has been started already.
  Start it from the beginning? (y or n) y
  `/home/jimb/play/t' has changed; re-reading symbols.
  Starting program: /home/jimb/play/t 
  t1.c: foo

  Breakpoint 1, bar () at t2.c:13
  13        foo ();
  (gdb) info break
  Num     Type           Disp Enb  Address    What
  1       breakpoint     keep y    0x080483de in bar at t2.c:13
          breakpoint already hit 1 time
  2       breakpoint     keep y    0x080483ca in foo at t2.c:6
  (gdb) c
  Continuing.

  Breakpoint 2, foo () at t2.c:6
  6         puts ("t2.c: foo");
  (gdb) 


  reply	other threads:[~2007-11-28 22:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 17:14 Vladimir Prus
2007-11-27 23:00 ` Jim Blandy
2007-11-28 15:59   ` Vladimir Prus
2007-11-28 16:23     ` Vladimir Prus
2007-11-28 19:46     ` Jim Blandy
2007-11-28 20:04       ` Vladimir Prus
2007-11-28 22:37         ` Jim Blandy [this message]
2007-11-29  6:09           ` Vladimir Prus
2007-11-28 22:50         ` Jim Blandy
2007-11-28 22:18     ` Jim Blandy
2007-11-29  4:24       ` Eli Zaretskii
2007-11-29  7:04         ` Vladimir Prus
2007-11-29 18:54           ` Jim Blandy
2007-11-29 19:03             ` Variable identification (Was: [RFA] Don't reset watchpoint block on solib load.) Vladimir Prus
2007-11-30  1:22               ` Michael Snyder
2007-11-30  5:52                 ` Vladimir Prus
2007-11-30 20:53                 ` Eli Zaretskii
2007-12-01  1:39                 ` Variable identification Jim Blandy
2007-12-01  1:47                   ` Michael Snyder
2008-01-16  1:29     ` [RFA] Don't reset watchpoint block on solib load Jim Blandy
2008-01-23  9:58       ` Vladimir Prus
2008-01-29 15:23         ` Daniel Jacobowitz
2007-11-29  6:55   ` Vladimir Prus
2007-11-29 18:40     ` Jim Blandy
2007-11-29 18:45       ` Vladimir Prus

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=m3r6iauhe4.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=vladimir@codesourcery.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