From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25139 invoked by alias); 3 Jan 2012 18:12:31 -0000 Received: (qmail 25124 invoked by uid 22791); 3 Jan 2012 18:12:28 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Jan 2012 18:12:13 +0000 Received: by vbbfn1 with SMTP id fn1so15257378vbb.0 for ; Tue, 03 Jan 2012 10:12:12 -0800 (PST) Received: by 10.52.99.74 with SMTP id eo10mr25423692vdb.12.1325614332199; Tue, 03 Jan 2012 10:12:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.99.74 with SMTP id eo10mr25423684vdb.12.1325614332083; Tue, 03 Jan 2012 10:12:12 -0800 (PST) Received: by 10.220.192.204 with HTTP; Tue, 3 Jan 2012 10:12:11 -0800 (PST) In-Reply-To: References: <20111228210206.B6B762461C9@ruffy.mtv.corp.google.com> Date: Tue, 03 Jan 2012 18:12:00 -0000 Message-ID: Subject: Re: [RFC] Initial pass at supporting the Go language From: Doug Evans To: Tom Tromey Cc: gdb-patches@sourceware.org, iant@google.com, Keith Seitz X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-01/txt/msg00105.txt.bz2 On Mon, Jan 2, 2012 at 11:13 AM, Tom Tromey wrote: > Doug> +/* Go objects should be embedded in a DW_TAG_module DIE, > Doug> + =A0 and it's not clear if/how imported objects will appear. > Doug> + =A0 To keep Go support simple until that's worked out, > Doug> + =A0 go back through what we've read and create something usable. > Doug> + =A0 We could do this while processing each DIE, and feels kinda c= leaner, > Doug> + =A0 but that way is more invasive. > Doug> + =A0 This is to, for example, allow the user to type "p var" or "b= main" > Doug> + =A0 without having to specify the package name, and allow lookups > Doug> + =A0 of module.object to work in contexts that use the expression > Doug> + =A0 parser. =A0*/ > > I think this over-exposes some buildsym details to dwarf2read. Sigh. This is what I get for monkey-see-monkey-do hacking. You can't trust any part of gdb to be what the powers-that-be find acceptab= le. [The code in question is far from rare, and any details are certainly not protected in a way that imposes or even suggests a proper API. A day I continue to wish for btw.] > How much more invasive is the alternative? I'd rather keep the hack as one call site at an outer level than embed it into new_symbol or each die handler or some such. > Doug> + =A0And if not, it should be clearly documented why not. > Doug> + =A0OTOH, why are we demangling at all here? > Doug> + =A0new_symbol_full assumes we return the mangled name. > Doug> + =A0I realize things are changing in this area, I just forget how.= =A0*/ > Doug> + =A0 =A0 =A0if (cu->language =3D=3D language_go) > Doug> + { > Doug> +#if 0 > Doug> + =A0 demangled =3D cu->language_defn->la_demangle (mangled, 0); > Doug> +#else > Doug> + =A0 /* This is a lie, but we already lie to the caller new_symbol= _full. > Doug> + =A0 =A0 =A0This just undoes that lie until things are cleaned up.= =A0*/ > Doug> + =A0 demangled =3D NULL; > Doug> +#endif > > I've CC'd Keith to see if he can clear this up. Or I can. This is one of the things I want to clean up before checking in. > Doug> +/* FIXME: IWBN to use c-exp.y's parse_number if we could. =A0*/ > > You could export it as c_parse_number or something like that, I suppose. I wasn't sure that would be acceptable. > Doug> + =A0 FIXME: Hacky, but until things solidify it's not worth much m= ore. =A0*/ > > I think you could safely remove this FIXME. I like it. It reminds me Go's mangling needs to change. > Doug> + =A0 =A0/*{"->", RIGHT_ARROW, BINOP_END}, Doesn't exist in Go. =A0= */ > > Doug> +#if 0 /* -> doesn't exist in Go. =A0*/ > Doug> + if (in_parse_field && tokentab2[i].token =3D=3D RIGHT_ARROW) > Doug> + =A0 last_was_structop =3D 1; > Doug> +#endif > > I think you could zap this dead code. I'll replace it with a similar comment. > Doug> + =A0/* TODO(dje): The encapsulation of what a pointer is belongs i= n value.c. > Doug> + =A0 =A0 I.e. If there's going to be unpack_pointer, there should = be > Doug> + =A0 =A0 unpack_value_field_as_pointer. =A0Do this until we can get > Doug> + =A0 =A0 unpack_value_field_as_pointer. =A0*/ > Doug> + =A0LONGEST addr; > > Eventually I want us to get rid of val_print entirely and only have > value_print. =A0Then this won't be a problem; since you will just use the > value API to access fields. I think that's the general consensus. > Doug> + =A0/* TODO(dje): Perhaps we should pass "UTF8" for ENCODING. > Doug> + =A0 =A0 The target encoding is a global switch. > Doug> + =A0 =A0 Either choice is problematic. =A0*/ > Doug> + =A0i =3D val_print_string (elt_type, NULL, addr, length, stream, = options); > > What is the problem here? The choice of what encoding to use is, ultimately, a property of the thing you are printing, not any global state. Plus Go generally uses utf8; I wasn't willing to have the Go support change the target encoding.