From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65798 invoked by alias); 19 Jun 2017 13:07:14 -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 65266 invoked by uid 89); 19 Jun 2017 13:07:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:209.85.223.196, Hx-spam-relays-external:209.85.223.196, H*r:sk:static. X-HELO: mail-io0-f196.google.com Received: from mail-io0-f196.google.com (HELO mail-io0-f196.google.com) (209.85.223.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 13:07:11 +0000 Received: by mail-io0-f196.google.com with SMTP id j200so11350311ioe.0 for ; Mon, 19 Jun 2017 06:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=TY6IXbR7hfWinNloNnMomBi+yv2j9z3x4PcrD0SBDVQ=; b=je5ii88DI8DDRCKtSAZ2f4iv6bPpz65DsGVWRncQKaL7Ae9zduAPreQq9Czk2G9x5q l2/ioMgHGnhzRCWmOi39Kdc677h9yk0HH/ulKHzhlMo6jwlejH0WbNxQXiZLB8wmcLPd YWKHPQVZ7GZqjKlDElKYSQm6ZCm9gW1B+Jkjke480VHBXNXaoK1TrzjmTev0pYAQjKAl BOHP5oJls8xZMVb+gT9zn4aKjbsXmta4cq+0uE0ht8RCfbBkvPe/NcUXc2JRH9Ijfu4V TTpyZGc5H9V6hgfm/KQU4b6Y6xAFxW0DuZvoGswXXSbXjFxohehyoyc+UXpJopsSFhH8 dM0Q== X-Gm-Message-State: AKS2vOy15qCzK0pOb2as/n/gL6cQnoEYyPf3LSHiBl2a+tqGXvIXoxMf L7sAzLtjRbiLYjiK X-Received: by 10.107.137.169 with SMTP id t41mr24319449ioi.217.1497877635252; Mon, 19 Jun 2017 06:07:15 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id t76sm4075783ita.22.2017.06.19.06.07.13 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 19 Jun 2017 06:07:14 -0700 (PDT) From: Yao Qi To: Philipp Rudo Cc: gdb-patches@sourceware.org, omair.javaid@linaro.org, yao.qi@linaro.org, peter.griffin@linaro.org, arnez@linux.vnet.ibm.com Subject: Re: [RFC v4 8/9] Link frame_info to thread_info References: <20170612170836.25174-1-prudo@linux.vnet.ibm.com> <20170612170836.25174-9-prudo@linux.vnet.ibm.com> Date: Mon, 19 Jun 2017 13:07:00 -0000 In-Reply-To: <20170612170836.25174-9-prudo@linux.vnet.ibm.com> (Philipp Rudo's message of "Mon, 12 Jun 2017 19:08:35 +0200") Message-ID: <86tw3cnn28.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00508.txt.bz2 Philipp Rudo writes: > Linux kernel stacks on S390 are spread over several memory locations. > These locations differ for every kernel task/thread. Thus we need to know > to which task/thread a frame belongs to check whether a stack pointer is > valid and when to stop unwinding. To do so add a pointer to corresponding > thread_info to frame_info. > > This connection already exists implicitly by the fact that switch_to_thre= ad > reinitializes the frame cache. The whole frame cache is created for current thread, from sentinel frame. When the current thread is changed, the frame cache will be re-created. If we see different frame_info objects are about different threads, it must be a bug somewhere. I think frame_info.thread always points to the current thread, no? --=20 Yao (=E9=BD=90=E5=B0=A7)