From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78168 invoked by alias); 29 Sep 2019 15:28:06 -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 78157 invoked by uid 89); 29 Sep 2019 15:28:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=leads, handles, 2019-09-15, 20190915 X-HELO: mailsec112.isp.belgacom.be Received: from mailsec112.isp.belgacom.be (HELO mailsec112.isp.belgacom.be) (195.238.20.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Sep 2019 15:28:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1569770884; x=1601306884; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=hrQPSUz382N301JpMtXoPU3Xu9wofyngt5HxFHEtmnw=; b=yNWGy6BbeYIGZ7jLa5HZ3wfTkwhJKA7TofG7QkZFuIJ1AIgiz+FR1mK3 HPAH0164motgpz1xiBSWSDwHPDkwuQ==; Received: from 255.38-242-81.adsl-dyn.isp.belgacom.be (HELO md) ([81.242.38.255]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 29 Sep 2019 17:28:02 +0200 Message-ID: Subject: PING Re: [RFAv5 0/3] Convenience functions $_gdb_setting/$_gdb_setting_str From: Philippe Waroquiers To: gdb-patches@sourceware.org Date: Sun, 29 Sep 2019 15:28:00 -0000 In-Reply-To: <20190915185314.19875-1-philippe.waroquiers@skynet.be> References: <20190915185314.19875-1-philippe.waroquiers@skynet.be> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00581.txt.bz2 Ping Thanks Philippe On Sun, 2019-09-15 at 20:53 +0200, Philippe Waroquiers wrote: > As part of the discussion of 'show | set may-call-functions [on|off]', > Eli suggested to have a way to access the GDB settings from > user defined commands. > > So, this patch series implements this. > 4 functions are provided: > * $_gdb_setting_str returning a string value of the setting. > * $_gdb_setting, returning an integer or string value of a setting, > depending on the setting type. > For integer/boolean/auto boolean settings, this is easier to use > than the string version. > * $_gdb_maint_setting, $_gdb_maint_setting_str : same as above, but > for maintenance settings. > > This is v5. > Compared to v4, it handles the comments of Pedro. > In particular, it tests the type of the function results. > > Some notes: > In settings.exp show_setting, I have not added a check that RESET_VALUE > differs from the expected value: this means to add a specific reset_value > to a lot of show_setting calls. As enough different values are verified, > this seems not necessary. > > For what concerns ptype $_gdb_setting("something") always giving type int: > This is "normal". For example, "ptype $_as_string(123)" similarly gives int. > > The reason: ptype evalues the given expression, but in a way that avoids > side effects. This then leads to eval_call in eval.c, that does: > ... > if (noside == EVAL_AVOID_SIDE_EFFECTS) > { > ... > > if (TYPE_CODE (ftype) == TYPE_CODE_INTERNAL_FUNCTION) > { > /* We don't know anything about what the internal > function might return, but we have to return > something. */ > return value_zero (builtin_type (exp->gdbarch)->builtin_int, > not_lval); > > and so any internal GDB function will always have the "type int". > Wondering if it would not be better to report an error such as > ("No type information for GDB functions") rather than lie. > >