From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91083 invoked by alias); 2 May 2019 14:56:52 -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 91070 invoked by uid 89); 2 May 2019 14:56:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 May 2019 14:56:50 +0000 Received: by mail-wr1-f68.google.com with SMTP id l2so3796816wrb.9 for ; Thu, 02 May 2019 07:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rh45FcTJEBOZ3qVZeLcZFiJKUHqnoI/tC5rqXgh3Uo0=; b=WstnH+tmBk+sUCz8KH5roqXaUZpo4l8Vv35j/RulUqwNqY1XDBR8Oi2GL0EUa+8rLE L+gt2smB0566sde1pHEGOolzDkiR4eMAPlf9WI+hSYlmW9AYvb+dzlwJQHfaOksjCHl6 MqvW4k2Qp6IKObEkxmZ+YyDSKv97K4ltW223QCXX/Snmp0PdSKXETQrJJ0+dNX9SIZjI S+RE/HISRVAsHPXweFZ2zjXz2pU+2EFrmPYou+jM68C3MpvyLevTdBOl8L9ew0bo/bdb DF67zzxgMhTgkGLk9wC3WW5SBfwyc51vKrIgQzYu2dyIGW55YtfWJ40P9303XqSWEI8j rFPg== Return-Path: Received: from localhost (host109-154-100-57.range109-154.btcentralplus.com. [109.154.100.57]) by smtp.gmail.com with ESMTPSA id b10sm15874975wrh.59.2019.05.02.07.56.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 02 May 2019 07:56:47 -0700 (PDT) Date: Thu, 02 May 2019 14:56:00 -0000 From: Andrew Burgess To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/rust: Handle printing structures containing strings Message-ID: <20190502145646.GU2737@embecosm.com> References: <20190501235246.7982-1-andrew.burgess@embecosm.com> <875zqtynrv.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <875zqtynrv.fsf@tromey.com> X-Fortune: No skis take rocks like rental skis! X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00036.txt.bz2 * Tom Tromey [2019-05-02 07:44:04 -0600]: > >>>>> "Andrew" == Andrew Burgess writes: > > Andrew> When printing a rust structure that contains a string GDB can > Andrew> currently fail to read the fields that define the string. This is > Andrew> because GDB mistakenly treats a value that is the parent structure as > Andrew> though it is the structure that defines the string, and then fails to > Andrew> find the fields needed to extract a string. > > Andrew> The solution is to create a new value to represent the string field of > Andrew> the parent value. > > Thank you for doing this. > > Andrew> if (rust_slice_type_p (type) && strcmp (TYPE_NAME (type), "&str") == 0) > Andrew> { > Andrew> + /* If what we are printing here is actually a string within a > Andrew> + structure then VAL will be the original parent value, while TYPE > Andrew> + will be the type of the structure representing the string we want > Andrew> + to print. > Andrew> + However, RUST_VAL_PRINT_STR looks up the fields of the string > Andrew> + inside VAL, assuming that VAL is the string. > Andrew> + So, recreate VAL as a value representing just the string. */ > Andrew> + val = value_at_lazy (type, value_address (val) + embedded_offset); > Andrew> rust_val_print_str (stream, val, options); > Andrew> return; > > It took me a while to understand this, but I get it now. At first it > looked like this code was misplaced, but what's going on is that > rust_val_print_str only takes a value, so in a "val_print" context we > must reconstruct one. If you'd like to suggest some new words I'd be happy to include them. I spent too long trying to write a helpful comment here, and like you I wasn't really happy with what I ended up with.... > > We really ought to get rid of the val_print / value_print distinction > someday. It doesn't provide any benefit and it leads to bugs like this. > > Andrew> +gdb_test "print st" " = simple::StringAtOffset {field1: \"hello\", field2: 1, field3: \"world\"}" > > I think this line should probably be split after the first argument. > Ok with this change. > > Tom