[RFA] Don't reset watchpoint block on solib load.

Jim Blandy jimb@codesourcery.com
Wed Nov 28 22:37:00 GMT 2007


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) 



More information about the Gdb-patches mailing list