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] |
lval_reg_frame_relative is a relatively recent addition, I believe, added to fix some particular problem with values stored in two places. Probably around the HP merge? But that's just a guess.
I think that lval_reg_frame_relative, lval_memory, and lval_register should all be combined to an lval_location which takes the frame and a description of a location, personally.
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}
Agh! That's not right at all! Although I'm not entirely clear on why it moved?
I guess the question is, what _should_ happen if a variable moves? e.g. we switch to a different item on its location list.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |