From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90183 invoked by alias); 16 Jan 2017 12:21:01 -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 90154 invoked by uid 89); 16 Jan 2017 12:21:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:AES128-SHA, sve, 17-01-12, 170112 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f66.google.com Received: from mail-lf0-f66.google.com (HELO mail-lf0-f66.google.com) (209.85.215.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Jan 2017 12:20:59 +0000 Received: by mail-lf0-f66.google.com with SMTP id x1so7050452lff.0; Mon, 16 Jan 2017 04:20:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=4ttkAClAz9U3HTOARQ0zDqmxZx22mgGWYF68x+vCG/s=; b=iNlt8etx4Acdlz6Dyl77HupLo6DJnYsA39+8sQTLLMa4S8yDA3YUEVGwYZ7RBF6f98 S567zEeP1aeZv6bSEEVOD7tXQ6IQxABVoRjvuYXhB73Y+728HH5YS88eEnod1760CeRW HAoJIvUgq0HYrZwGzRMTUYVO2XzIulw4zgPntl+PMY9SElws8i9I8qdOKA8404d4diGM 22YBcP8VtyEwTuWHRxdMAkaO3X/XvgpPsGvtZe2cbXyrUXbgX7OGdTnJVV6VKHpIKBV8 UGgNJVr5N0qieDZftoH2zxk7pVVlc056oF2hOd3cZS+lsVo7sXTajzIh79cC3etoXuFr LYww== X-Gm-Message-State: AIkVDXImmemj7CwQHPtgvlZI29yHwTAu/70K12qzjY7c48PzqAo/orH2aTcIMCDgllCx9g== X-Received: by 10.46.76.18 with SMTP id z18mr1097901lja.32.1484569256487; Mon, 16 Jan 2017 04:20:56 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id c78sm7131028lfc.39.2017.01.16.04.20.50 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 16 Jan 2017 04:20:55 -0800 (PST) Date: Mon, 16 Jan 2017 12:21:00 -0000 From: Yao Qi To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Marc Zyngier , Alan Hayward , Christoffer Dall , linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Florian Weimer , Joseph Myers , Szabolcs Nagy , Torvald Riegel , gdb@sourceware.org Subject: Re: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting Message-ID: <20170116122038.GG28060@E107787-LIN> References: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com> <1484220369-23970-9-git-send-email-Dave.Martin@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1484220369-23970-9-git-send-email-Dave.Martin@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00018.txt.bz2 On 17-01-12 11:26:07, Dave Martin wrote: > This patch adds support for manipulating a task's vector length at > runtime via ptrace. > I hope kernel doesn't provide such interface to ptracer to change vector length. The vector length is sort of a read-only property of thread/process/ program to debugger, unless we really have a clear requirement to modify vector length in debugging. I may miss something because I haven't debug SVE code yet. > As a simplification, we turn the task back into an FPSIMD-only task > when changing the vector length. If the register data is written > too, we then turn the task back into an SVE task, with changed > task_struct layout for the SVE data, before the actual data writing > is done. > > Because the vector length is now variable, sve_get() now needs to > return the real maximum for user_sve_header.max_vl, since .vl may > be less than this (that's the whole point). > -- Yao (齐尧)