From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62921 invoked by alias); 17 Feb 2020 12:37:50 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 62913 invoked by uid 89); 17 Feb 2020 12:37:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:64aad0f, H*i:sk:64aad0f, H*MI:sk:64aad0f, HContent-Transfer-Encoding:8bit X-HELO: mail-qk1-f174.google.com Received: from mail-qk1-f174.google.com (HELO mail-qk1-f174.google.com) (209.85.222.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Feb 2020 12:37:48 +0000 Received: by mail-qk1-f174.google.com with SMTP id v2so16034538qkj.2 for ; Mon, 17 Feb 2020 04:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AiD40u3Qo52Jq15XjWWjyHGclz5QzAgg+aI3GnHhxAo=; b=RMu0nP+4TYPQwlXJS8B6OXvyXfNl7jNm930FJA48LdLD7GNDXQDj60uFbXjsdfqVhI xJBSxCI3ekn4TX+T8QtfB7Pa5YuKgbc8kzPK0u0cPRco/yI3wgF/4HV9aSNpvxga3Xag FIFM94GdnejaFgg98ko0fm45lbqmq/GYqofz1tyW+AhEbQmEYtG9N8fJ086CRWZDZEDX NHGWI4qUHN1bl0BKnFcNBKnbcaVcN30hT19SnZtp6CJTKH8Z9WCD4TnfV/RhzzmoaBiL XeqQRIbWGJZM9X9ldtXaK3H71n2Eft39W3wSIwJKSSd8mHOSHrDC1kGKVVRsDqOdpL2/ 7hcA== Return-Path: Received: from [192.168.0.185] ([191.34.156.101]) by smtp.gmail.com with ESMTPSA id s48sm96446qtc.96.2020.02.17.04.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2020 04:37:45 -0800 (PST) Subject: Re: Is this a bug in gdb To: =?UTF-8?Q?Volker_Wei=c3=9fmann?= , gdb@sourceware.org References: <64aad0f5-5cee-63a6-18cc-1efdef1b1750@gmx.de> From: Luis Machado Message-ID: <6eb16386-eac9-cf5a-6cbe-813eae439df0@linaro.org> Date: Mon, 17 Feb 2020 12:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <64aad0f5-5cee-63a6-18cc-1efdef1b1750@gmx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00039.txt.bz2 On 2/16/20 7:40 PM, Volker Weißmann wrote: > Hello, > > The help text of the watch command claims that the -l option watches the > memory of the variable. When I tried this, I was surprised by the > outcome (reproducible): > > > (gdb) watch this->v_ > Hardware watchpoint 2: this->v_ This command tells GDB to watch the value of this->v_, whatever address &(this->v_) points to. That, of course, can change across the execution of the program. > (gdb) watch -l this->v_ This command tells GDB to watch for changes in a particular location. Since this->v_ is a value rather than a location, the error is thrown. The correct invocation would be ... > A syntax error in expression, near `restrict *) 0x00007fffffffd398'. > (gdb) > > Note: Using print &(this->v_) and  watch (char[8]) > *outputoftheprintcommand worked. > ... the above. It points to an address that will be watched. > > I am asking you whether this is a bug in gdb or not, because if it is a > bug in gdb, I will try to make a minimal example an file a bug report. I don't think it is a bug. But maybe the documentation isn't doing a good enough job of making it clear how to invoke these commands?