Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Variable objects laziness
Date: Wed, 29 Nov 2006 08:59:00 -0000	[thread overview]
Message-ID: <17773.19183.730566.545997@kahikatea.snap.net.nz> (raw)


> > With the new changes to varobj.c, -var-assign doesn't work for references.

> This is embarrassing. However, it also validates my claim that we should a
> single invariant-preserving function to assign new value. This crash
> happens, for all appearances, because varobj_set_value directly sets new
> value.

> I've checked in the attached, that fixes the crash, and causes no
> regressions.

I find this way works well but it's not how things are done here.  You need to
post the patch first and get approval from an appropriate maintainer _before_
committing it (I don't think your change counts as an obvious fix).  See the
MAINTAINERS file.  I'm assuming that you have Write After Approval (clearly you
have write access) but AFAICS you've not added your name to MAINTAINERS.

Anyway the patch does indeed seem to do what you say.  Thanks.

> Attached (references.diff) is the patch that makes gdb sense the changes in
> reference values, and eliminates the address from the output. Any opinions?

Doesn't appear to be attached but I'm only reading the archives.  If you
reply to an e-mail from me on gdb-patches could you please include me as I'm
not subscribed to the mailing list (I'd rather receive two than none anyway).
I think that's general accepted protocol.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


             reply	other threads:[~2006-11-29  8:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29  8:59 Nick Roberts [this message]
2006-11-29  2:08 ` Nick Roberts
2006-11-29  2:55   ` Daniel Jacobowitz
2006-11-29  4:14     ` Nick Roberts
2006-11-29  7:25   ` Vladimir Prus
2006-11-29 13:45     ` Daniel Jacobowitz
2006-11-29 13:56       ` Vladimir Prus
2006-11-29 20:25       ` Nick Roberts
2006-11-29  9:09 ` Vladimir Prus
  -- strict thread matches above, loose matches on Subject: below --
2006-11-15  2:45 Nick Roberts
2006-11-15  9:22 ` Vladimir Prus
2006-11-14 13:43 Vladimir Prus
2006-11-14 20:47 ` Daniel Jacobowitz
2006-11-15  9:04   ` Vladimir Prus
2006-11-15 16:25     ` Daniel Jacobowitz
2006-11-17  9:23       ` Vladimir Prus
2006-11-17 10:40         ` Mark Kettenis
2006-11-17 10:45           ` Vladimir Prus
2006-11-17 14:22             ` Daniel Jacobowitz
2006-11-17 15:01               ` Vladimir Prus
2006-11-17 17:19                 ` Vladimir Prus
2006-11-17 18:12                   ` Daniel Jacobowitz
2006-11-18  9:48                     ` Vladimir Prus
2006-11-28 17:09                       ` Daniel Jacobowitz
2006-12-04 19:27                         ` 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=17773.19183.730566.545997@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /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