From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: Use of lval_register?
Date: Thu, 05 Jun 2003 15:50:00 -0000 [thread overview]
Message-ID: <3EDF66A8.4030003@redhat.com> (raw)
In-Reply-To: <20030605151750.GA25587@nevyn.them.org>
> 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.
Ah.
> 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.
These will all need to live in harmony for a wile though.
>> 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?
The ``print $1''? That output is correct. GDB saves the value so that
it can be refered back to later without having it change.
> I guess the question is, what _should_ happen if a variable moves?
> e.g. we switch to a different item on its location list.
From the users view point, the variable hasn't moved. Hence the
assignment:
$1.argc = N
should always work. Should that assignment update the cached $1 value
as well, hmm....
Andrew
next prev parent reply other threads:[~2003-06-05 15:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-05 14:35 Andrew Cagney
2003-06-05 15:18 ` Daniel Jacobowitz
2003-06-05 15:50 ` Andrew Cagney [this message]
2003-06-05 15:59 ` Daniel Jacobowitz
2003-06-05 16:13 ` Andrew Cagney
2003-06-05 16:23 ` Daniel Jacobowitz
2003-06-05 17:48 ` Andrew Cagney
2003-06-05 18:30 ` 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=3EDF66A8.4030003@redhat.com \
--to=ac131313@redhat.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).