Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: gdb-patches@sourceware.org
Subject: Re: Language of registers
Date: Fri, 01 Dec 2006 14:32:00 -0000	[thread overview]
Message-ID: <20061201143219.GA25854@nevyn.them.org> (raw)
In-Reply-To: <ekhtto$rgd$1@sea.gmane.org>

On Tue, Nov 28, 2006 at 09:07:52PM +0300, Vladimir Prus wrote:
> What I said ("varobjs don't know anything about Ada") is still true,
> though ;-) 
> 
> There are two completely independent languages. One language is that used to
> values and types -- the one changed by "set language". The type output
> above comes from "type_print", that just calls LA_PRINT_TYPE, which is just
> wrapper over current_language->la_print_type.
> 
> On the other hand, varobj->root->lang is internal to varobj.c -- it selects
> which of language specific function inside varobj.c itself are called
> later.

I don't think that's accurate.  They're not independent.
var->root->lang is set from var->root->exp->language_defn, which is
captured from the global current language when the expression is
parsed.

Having -var-create do something magically different for registers is
strange and confusing.  Maybe, if the patch to automatically create
varobjs for registers goes in, that new command should always use
language_c?

> >> The change does not seem very complex, but the changes to testcases will
> >> be huge, so I'd like to check. Does everybody agree with removing
> >> "public" pseudo-field from structures that have only public fields?
> > 
> > We can't tell reliably if something was declared as "struct" or "class"
> > in the source, but I think unions default to public, don't they?
> 
> The *default* to public, but you can have private members in a union.

That's what I meant.  We can see "oh, this is a union" -> "its default
is public".  We don't know for sure if a source construct was "struct"
(public by default) or "class", though.  But it sounds like we can't
remove the public child now anyway.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-12-01 14:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-25 11:22 Vladimir Prus
2006-11-27 14:03 ` Daniel Jacobowitz
2006-11-28 17:12   ` Vladimir Prus
2006-11-28 17:23     ` Daniel Jacobowitz
2006-11-28 18:09       ` Vladimir Prus
2006-12-01 14:32         ` Daniel Jacobowitz [this message]
2006-12-01 18:03           ` Jim Ingham
2006-11-29 10:12   ` Vladimir Prus
2006-11-27  0:43 Nick Roberts
2006-11-27  6:32 ` Vladimir Prus
2006-11-27  7:37   ` Eli Zaretskii
2006-12-06 21:54 Nick Roberts
2006-12-06 22:03 ` Daniel Jacobowitz
2006-12-06 22:55   ` Nick Roberts
2006-12-06 23:10     ` 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=20061201143219.GA25854@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    /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