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
next prev parent 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