This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Use of lval_register?


Um, so ok humor me here. Should value_of_register and value_from_register be using lval_register?

"findvar.c:value_from_register" contains the code snipit:

  VALUE_REGNO (v) = regnum;
  ....
      if ((reg_stor && mem_stor)
          || (mem_stor && !mem_tracking))
        /* Mixed storage; all of the hassle we just went through was
           for some good purpose.  */
        {
          VALUE_LVAL (v) = lval_reg_frame_relative;
          VALUE_FRAME (v) = get_frame_base (frame);
          VALUE_FRAME_REGNUM (v) = regnum;
        }
      else if (mem_stor)
        {
          VALUE_LVAL (v) = lval_memory;
          VALUE_ADDRESS (v) = first_addr;
        }
      else if (reg_stor)
        {
          VALUE_LVAL (v) = lval_register;
          VALUE_ADDRESS (v) = first_addr;
        }
      else
        internal_error (__FILE__, __LINE__,
                        "value_from_register: Value not stored anywhere!");

I'm left wondering why GDB doesn't instead always set the location to lval_reg_frame_relative and be done with it. The other use of lval_register in value of register is similar.

In fact, I'm even wondering if GDB should always be setting it to lval_reg_frame_relative, consider the following:

(gdb) b main
Breakpoint 1 at 0x1802f84: file gdb.c, line 30.
(gdb) run
Starting program: gdb
Breakpoint 1, main (argc=1, argv=0x7fffe434) at /home/scratch/GDB/src/gdb/gdb.c:30
30 memset (&args, 0, sizeof args);
(gdb) n
31 args.argc = argc;
(gdb)
32 args.argv = argv;
(gdb) print args
$1 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0}


At this point $1 contains not just args value but also it's location. Modify the target state ...

(gdb) n
33        args.use_windows = 0;
(gdb) print args
$2 = {argc = 1, argv = 0x7fffe434, use_windows = 0, interpreter_p = 0x0}
(gdb) print $1
$3 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0}

Now, presumably the following (I'm still getting over the shock of what it did) ...

(gdb) set $1.argc = 2
(gdb) print $1
$4 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0}
(gdb) print args
$5 = {argc = 2, argv = 0x7fffe434, use_windows = 0, interpreter_p = 0x0}

needs to find the current location of args and that means, when args is in a register in frame foo, potentially having to re-find where those registers are now saved.

(please lets ignore the possible need to attach a scope breakpoint to the variable so that it knows that the value has gone out of scope ...).

Andrew

PS: I should note that my first attempt at doing this it didn't work. On the MIPS, GDB was having trouble re-finding the frame but I'll attribute that to the codes use of VALUE_FRAME + get_frame_base() instead of VALUE_FRAME_ID + get_frame_id() :-^

PPS: The above also has a bug. When reg_store, VALUE_REGNUM is probably wrong. It should be REALNUM (returned by frame_register_unwind) which is REGNUM's real location.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]