From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26508 invoked by alias); 27 Apr 2016 16:22:40 -0000 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 Received: (qmail 26491 invoked by uid 89); 27 Apr 2016 16:22:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=experiences, spots, laid, offends X-HELO: gproxy10-pub.mail.unifiedlayer.com Received: from gproxy10-pub.mail.unifiedlayer.com (HELO gproxy10-pub.mail.unifiedlayer.com) (69.89.20.226) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Wed, 27 Apr 2016 16:22:29 +0000 Received: (qmail 2080 invoked by uid 0); 27 Apr 2016 16:22:26 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 27 Apr 2016 16:22:26 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw2 with id nUN81s01D2f2jeq01UNBkM; Wed, 27 Apr 2016 10:22:24 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=PnD2wP_eR3oA:10 a=_v2sUkyEFrwA:10 a=kziv93cY1bsA:10 a=2Jky9qkQiw7r0IilBZQA:9 Received: from [71.215.116.141] (port=57134 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1avSE6-00067O-FS; Wed, 27 Apr 2016 10:22:10 -0600 From: Tom Tromey To: Pedro Alves Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 0/8] Add Rust language support References: <1461725371-17620-1-git-send-email-tom@tromey.com> <5720A6B6.8010505@redhat.com> Date: Wed, 27 Apr 2016 16:22:00 -0000 In-Reply-To: <5720A6B6.8010505@redhat.com> (Pedro Alves's message of "Wed, 27 Apr 2016 12:47:02 +0100") Message-ID: <87inz3c98x.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Identified-User: {36111:box522.bluehost.com:elynrobi:tromey.com} {sentby:smtp auth 71.215.116.141 authed with tom+tromey.com} X-SW-Source: 2016-04/txt/msg00600.txt.bz2 Tom> If anybody cares, I have a list of the ugly bits in gdb I encountered Tom> while writing this series. I think it's all generally well known Tom> though. Pedro> I'd be curious. First, let me say a few words about the good parts. It's easy to add a new language. You pretty much start with struct language_defn and work out -- there are only a couple of small holes with this plan (see below). (FWIW I'm planning to update the wiki with my experiences.) One thing I especially like is that it's possible to do the work piecemeal. I actually started by just copying the C language definition and then replacing individual fields as desired. Now, here's some stuff I ran into that was less good. * struct expression is very hard to deal with. The prefixifying step is bewildering. The need to manually manage slots in the expression makes all the code error-prone, especially because multiple bits of code all have to be modified in sync. Adding a new operation involves making operator_length do the right thing, and also updating two different expression dumpers. Expression evaluation has to handle two special "noside" cases, and one of them, AFAICT, is just fallout from the weird way that struct expression is laid out. I think replacing all of this with a more ordinary AST-like expression object would be a big improvement. * I found val_print pretty ugly as well. Printing a value means implementing a function that take 8 arguments, basically a struct value split into pieces. Exactly what all of these mean is obscure, at least if you haven't been involved in the depths of gdb for a while... back in the day I had wanted to replace this with a printing API that simply passed around values, not exploded values; I think that remains a good idea. * Relatedly, it was a bit of a puzzle to build an object and fill it in. I think the choices were to use pack_* and fill in the bits manually, or allocate on the inferior, use value_assign to fields, and then re-fetch the resulting value. Also only strings and arrays can be automatically pushed to inferior memory, so for struct objects I ended up requesting the allocation by hand. * There's no built-in way to create a struct type and lay it out. This requires a bit of arch support in the form of knowledge of any special ABI rules. * The character and string printing hooks in struct language_defn are poorly factored. Printing a string is very complicated, enough so that I didn't want to duplicate all the code in rust-lang.c. However, despite the fact that there are two different character-printing hooks, it's still not possible to print character escapes in strings using Rust syntax. * Writing a parser currently involves a bunch of global state. There's struct parser_state but it doesn't contain all the relevant state, like innermost_block (this one particularly offends me for some reason) or parse_completion. * There are a few spots that are desirable to update when adding a language that aren't covered by any hooks in language_defn. In this series this includes the patches to dwarf2read; the adding of the ".rs" extension (file extensions could be in an array in the definition); and the change to symbol_find_demangled_name. * Although DWARF encodes namespaces, I think there's no way to get at this information after gdb has made its symbol tables. For Rust I ended up reusing some C++ functions to manipulate symbol names. Tom