From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23059 invoked by alias); 3 Mar 2020 16:49:48 -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 23051 invoked by uid 89); 3 Mar 2020 16:49:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Mar 2020 16:49:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583254185; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XvDWc19OhVVjd3dsA0WDC301xvyks9L0wyLrK8ybYbY=; b=eDPJtLVHoBVdNMbv4lpckOBlIw/BpLK0ljW5C7woRp2nXSBWt8cn5DAM2E73e01SJSI7WB X5YMyhF0EXE0/7Waw3KUTLu8usvNCtJm0Xcb2bh3qh70v0TQiCY1U37zwZ1ZkyqeNAIqoi r3aHQq8YwPysWMAtYwlb9tDJ8zoIERw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-197-j5eNmklyO5uBL5SxU1V9-w-1; Tue, 03 Mar 2020 11:49:43 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DB031800D48; Tue, 3 Mar 2020 16:49:41 +0000 (UTC) Received: from localhost (unused-10-15-17-54.yyz.redhat.com [10.15.17.54]) by smtp.corp.redhat.com (Postfix) with ESMTP id 77CB860BE1; Tue, 3 Mar 2020 16:49:41 +0000 (UTC) From: Sergio Durigan Junior To: Andrew Burgess Cc: GDB Patches , Philippe Waroquiers , Pedro Alves , Joel Brobecker Subject: Re: [PATCH] Fix printf of a convenience variable holding an inferior address References: <20190610211622.15237-1-philippe.waroquiers@skynet.be> <20200302024616.1049417-1-sergiodj@redhat.com> <20200303133918.GV3317@embecosm.com> <877e01h06g.fsf@redhat.com> Date: Tue, 03 Mar 2020 16:49:00 -0000 In-Reply-To: <877e01h06g.fsf@redhat.com> (Sergio Durigan Junior's message of "Tue, 03 Mar 2020 11:29:11 -0500") Message-ID: <87wo81criy.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00059.txt On Tuesday, March 03 2020, I wrote: > On Tuesday, March 03 2020, Andrew Burgess wrote: > >> * Sergio Durigan Junior [2020-03-01 21:46:16 -0500= ]: >> >>> Back at: >>>=20 >>> commit 1f6f6e21fa86dc3411a6498608f32e9eb24b7851 >>> Author: Philippe Waroquiers >>> Date: Mon Jun 10 21:41:51 2019 +0200 >>>=20 >>> Ensure GDB printf command can print convenience var strings without= a target. >>>=20 >>> GDB was extended in order to allow the printing of convenience >>> variables that are strings without a target. However, this introduced >>> a regression that hasn't been caught by our testsuite (because there >>> were no tests for it). >>>=20 >>> The problem happens when we try to print a convenience variable that >>> holds the address of a string in the inferior. The following >>> two-liners can reproduce the issue: >>>=20 >>> $ echo -e 'int main(){const char a[]=3D"test";return 0;}' | gcc -x c - = -O0-g3 >>> $ ./gdb/gdb --data-directory ./gdb/data-directory -q ./a.out -ex 'start= ' -ex 'set $x =3D (const char *) (&a[0] + 2)' -ex 'printf "%s\n", $x' >>>=20 >>> After some investigation, I found that the problem happens on >>> printcmd.c:printf_c_string. In the case above, we're taking the first >>> branch of the 'if' condition, which assumes that there will be a value >>> to be printed at "value_contents (value)". There isn't. We actually >>> need to obtain the address that the variable points to, and read the >>> contents from memory. >>>=20 >>> It seems to me that we should avoid this branch if the TYPE_CODE of >>> "value_type (value)" is TYPE_CODE_PTR (i.e., a pointer to the >>> inferior's memory). This is what this patch does. >>>=20 >>> I took the liberty to extend the current testcase under >>> gdb.base/printcmds.exp and create a test that exercises this scenario. >>>=20 >>> No regressions have been found on Buildbot. >>>=20 >>> gdb/ChangeLog: >>> 2020-03-02 Sergio Durigan Junior >>>=20 >>> * printcmd.c (print_c_string): Check also for TYPE_CODE_PTR >>> when verifying if dealing with a convenience variable. >>>=20 >>> gdb/testsuite/ChangeLog: >>> 2020-03-02 Sergio Durigan Junior >>>=20 >>> * gdb.base/printcmds.exp: Add test to verify printf of a >>> variable holding an address. >> >> LGTM. > > Thanks, pushed: > > 7b973adce2b486518d3150db257b179e1b9a5d33 BTW, this also affects 9.1 (in fact, that's where I found the bug). I can create a tracking bug and backport it to the branch if the issue and fix are deemed important enough. Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/