From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103623 invoked by alias); 19 Jun 2017 09:52:08 -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 102364 invoked by uid 89); 19 Jun 2017 09:52:07 -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*r:sk:static., xxx, our X-HELO: mail-it0-f67.google.com Received: from mail-it0-f67.google.com (HELO mail-it0-f67.google.com) (209.85.214.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 09:52:05 +0000 Received: by mail-it0-f67.google.com with SMTP id g184so8741712ita.0 for ; Mon, 19 Jun 2017 02:52:10 -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=li357rWg6zQ5cI/gyaqnarhnqaRe1GOnRpdotj6eSOY=; b=ip14KqBPUJd4ZBlQBwSc7FHjguOdhgc5mHrx3Uew5xSwCmAHCNNmohROatx0ivTuj1 ToNJCKewuvBFTpYECi8bMldxtaicYeKbVDruoNYl7v1YMq40dSeLA2Hd/fBCjJIASR6y 6rUYx70baPcw6BhGCbKWn+rqkML7FrN9W0S1JABIFWLnkE2D7j1rm8TDagG/cKfquN6F QlNSaBkv17P/yfJq2sLIoGrbMUDOYqCMIMb0GcGdINQV88uzimM7zUYmVZ+/2aBppJVZ y/5MlviNBdQYwCuDUiC5My1yK5+fpx9fvGuzF3kDov4wiO+MAZd0EZdEeRnSYRwGaSxd JdeQ== X-Gm-Message-State: AKS2vOzDpjSxWH14/OvPxPQst0hW09YSsyLsVNbkhJA4JUD9dqLmc0rt bssUQiJSe4KrnPw4 X-Received: by 10.36.194.129 with SMTP id i123mr21156915itg.9.1497865929080; Mon, 19 Jun 2017 02:52:09 -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 u186sm6720530ita.3.2017.06.19.02.52.07 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 19 Jun 2017 02:52:08 -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 3/9] Add basic Linux kernel support References: <20170612170836.25174-1-prudo@linux.vnet.ibm.com> <20170612170836.25174-4-prudo@linux.vnet.ibm.com> <86vanxtguc.fsf@gmail.com> <20170616121026.024f664b@ThinkPad> Date: Mon, 19 Jun 2017 09:52:00 -0000 In-Reply-To: <20170616121026.024f664b@ThinkPad> (Philipp Rudo's message of "Fri, 16 Jun 2017 12:10:26 +0200") Message-ID: <8637awpanu.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/msg00501.txt.bz2 Philipp Rudo writes: >> Sorry, I don't understand this design. Can you elaborate? > > The target beneath reports us a "pid" it thinks is right. For example in = a core > file the register sections are usually named > > .reg/XXX > > where XXX names the thread these registers belong to. In user space this= is > typically the pid of the thread but for kernel dumps it usually is a cpu-= id > (this needn't be the logical cpu-id used in the kernel). Because of that= the > kernel ptid, we generate from task_struct, usually has a different lwp th= an the > same thread reported from the target beneath. Nevertheless we need the t= arget > beneath to give us information for running tasks. That's why we need to > introduce a mapping between the ptid of the target beneath and the kernel= ptid. > > In short, this represents two different thread views (hardware vs. softwa= re > threads). > > Did that answer your question? Or did you mean something different? > Can we use thread_info.priv to store these information rather than using ptid_t? >> > + >> > +/* Private data struct to map between our and the target beneath PTID= . */ >> > + >> > +struct lk_ptid_map >> > +{ >> > + struct lk_ptid_map *next;=20=20 >>=20 >> Can you use C++ stl list instead? > > As I already wrote Omair, my ptid_map was only meant to "somehow work" but > never to be permanent. Managing the ptid map will be the main task for l= ive > debugging. That's why I think it is best when Omair changes this bit to > whatever he needs. The lk_ptid_map is a list, and this patch still iterates it. We need to use C++ stl list, rather than leave it to someone else who does the related work later. --=20 Yao (=E9=BD=90=E5=B0=A7)