From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5545 invoked by alias); 16 Jan 2017 15:48:49 -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 5468 invoked by uid 89); 16 Jan 2017 15:48:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=redetects, re-detects X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 15:48:46 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 868757EBCB; Mon, 16 Jan 2017 15:48:46 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0GFluR4029252; Mon, 16 Jan 2017 10:47:57 -0500 Subject: Re: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting To: Yao Qi , Dave Martin References: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com> <1484220369-23970-9-git-send-email-Dave.Martin@arm.com> <20170116122038.GG28060@E107787-LIN> <20170116133231.GO3699@e103592.cambridge.arm.com> <20170116151156.GI28060@E107787-LIN> Cc: linux-arch@vger.kernel.org, Florian Weimer , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Joseph Myers , Szabolcs Nagy , linux-arm-kernel@lists.infradead.org, Alan Hayward , Torvald Riegel , Christoffer Dall From: Pedro Alves Message-ID: Date: Mon, 16 Jan 2017 15:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170116151156.GI28060@E107787-LIN> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-01/txt/msg00024.txt.bz2 On 01/16/2017 03:11 PM, Yao Qi wrote: > >> > >> > gdb must already re-detect the vector length on stop, since the target >> > could have called the prctl() in the meantime. > Yes, gdb assumes the vector length may be changed, so it re-detects on > every stop, but I don't see the need for gdb to change the vector length. > Do we need to consider inferior function calls here? Say the program is stopped in code that assumes "vector length N", and the user does "print some_function_that_assumes_some_other_vector_length ()". Is that a use case we need to cover? If so, to make it work correctly, the debugger needs to be able to change the vector length to the length assumed by that called function, and then restore it back after the call completes (or is aborted). I have no idea whether the debugger will be able to figure out a function's assumed vector length from debug info or some such. Thanks, Pedro Alves