From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23859 invoked by alias); 23 Jan 2018 13:32:51 -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 23850 invoked by uid 89); 23 Jan 2018 13:32:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=opinion, our X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Jan 2018 13:32:49 +0000 Received: by mail-wm0-f43.google.com with SMTP id v123so1907343wmd.5 for ; Tue, 23 Jan 2018 05:32:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SSm+yAl/wz8C1HCXcpF4frxSQ0ZIlcUy6yRt8/Ty6rE=; b=MQA6MmFVbsQWFRuGIzGzd6SfmVoXc6Nn1fZFpfkgvDNvZkP8hhDka6Xae30GIWVvQr eSGvPi1fnw/OnIomVaDt7khMXdX15yoDa/UK3yoOHLa08JQOHuJOOY6O57DfMjkXxO9+ HTXEzC0aXQ8E11bUC3wEPbq26mPav5cmG+ykOEIAJc/1vDmozaisJfAwJziXHsXx+jHr BmawXP2AldzKAMrmTC2ZVFhgB9jk8eYc7g+7FwGjCJWJnWfK7/IAcQ2kDWW5+SitzlaH tjLPSu2N9lb7NYqn4hR0pNSFNCmULQA4xMZhedEgVYO1rjWaHoapDIirdToxSRg0tAsP yX6A== X-Gm-Message-State: AKwxytcpEhHuXAoqAI4N698JZLs7UDjSrWhOHzXC+T540H9gCHWINZYw Ez75dSMm7JICKgzSK90oeROIsWJ6fmAZu2mYIoc= X-Google-Smtp-Source: AH8x226eirIw6WSQByYU3OlOozhRGIWwehYGlp4O0/GxVHWPxX06JkHT5sUMimzT62L6TdB/OQ5EKLlXLYVTLYAfmDc= X-Received: by 10.80.146.134 with SMTP id k6mr18974322eda.107.1516714367138; Tue, 23 Jan 2018 05:32:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.137.36 with HTTP; Tue, 23 Jan 2018 05:32:46 -0800 (PST) In-Reply-To: <20180123115152.26mi46zogpbuodn7@adacore.com> References: <87vafxk3us.fsf@tromey.com> <20180123115152.26mi46zogpbuodn7@adacore.com> From: Matt Rice Date: Tue, 23 Jan 2018 13:32:00 -0000 Message-ID: Subject: Re: [RFC] expected behavior for "bt" command used with "set language ..." ? To: Joel Brobecker Cc: Tom Tromey , Xavier Roirand , "gdb-patches@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00455.txt.bz2 On Tue, Jan 23, 2018 at 3:51 AM, Joel Brobecker wrote: >> Xavier> When printing one frame arguments, should we do it using the language >> Xavier> of the frame, and it may be different for each frame in a single "bt" >> Xavier> command or should we leave things as they are, and possibly allow the >> Xavier> "bt" command to display weird values for frame arguments or even >> Xavier> worse, crash GDB because the user set language manually so he has to >> Xavier> know what he's doing ? >> >> I tend to think the answer should be: >> >> * If the language is "auto", then use each frame's language; otherwise >> * If the user specified a particular language, use that language for >> everything. > > I don't really have a strong opinion on this. But I thought I'd mention > that using a language to dump the value of a variable described using > another language can be a bit iffy, and lead to fairly mysterious > errors. If I was a fan of FUD, I might even say it can lead to crashes, > if the code is not careful enough. For instance, who knows what it's > going to look like asking Ada to print come C++ stuff, or vice-versa... > > As a user, the few times I have forced the language was to execute > one command (eg: print this Ada variable using pure C), and I tend > to switch back to "auto" asap. But it's easy to forget, and when > that happens, linking the weird printing in our backtrace back to > the language change we did a few commands ago may sometimes not be > all that obvious. > > That being said, it looks like this is the behavior we've had for > quite a while, now, so it confirms the current approach probably > is not that much of any issue (if at all). Hence the lack of strong > opinion :). > > For now, we'll go ahead with what Tom suggests. The only strong opinion that I have about this is about an edge case, where the frame language is not the user specified language and the frame language is unknown to gdb. It should prefer the user specified language upon fallback, rather than e.g. minimal, this is somewhat implicit in the current behavior, but if it changes, or you guys carry patches for this. I thought I would mention it. >> Xavier> This can also probably be done by adding frame language parameter to a >> Xavier> lot of language specific functions for each language and finally to >> Xavier> value_cast but this second solution requires a huge amount of work. >> >> That would be good to have but I don't think it ought to be tied to >> this particular project. Certainly plenty of other code already just >> sets and resets the global. > > Agreed. > > Thanks Tom! > -- > Joel