From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121229 invoked by alias); 19 Jun 2017 13:35:32 -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 120856 invoked by uid 89); 19 Jun 2017 13:35:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2045, HX-HELO:sk:mail-lf, xxx, our X-HELO: mail-lf0-f54.google.com Received: from mail-lf0-f54.google.com (HELO mail-lf0-f54.google.com) (209.85.215.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Jun 2017 13:35:30 +0000 Received: by mail-lf0-f54.google.com with SMTP id m77so56264766lfe.0 for ; Mon, 19 Jun 2017 06:35:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5Oj94bTEjBth/eW1dVN0aXrxQWKitGvL5i+Vj07CYjE=; b=o1i0CsUTIOtIlYom6xa42CUZ3wzv71VDJZb8kmXcVUIg0tIbjq0ac1InGqy10VkRjo Mv/tzTMSWItYYCECIONte0UxhsDShBqLlmGrMChikozMZNmcb1CDdHaXz3aPiNBky+Zm vVoFLez8bsVsyp5HK1o3WjE1Fd1SyyCLWPF+cfGF9bj57RuIi4frLoQCP+5iF5htWOe4 1qDD00pjTb7guQYHraTz8PEqGe6iCdCYvF2yQ6bMiXurF0lczpnLiM+bb7jjqxhNLbWZ ZlDCHLYMVFT9xdZv9KBQ4iGrvHduyMmWnwt+Ii/YYWFvVUnGzbUnkh1TWzagF7RSv34m /Lkw== X-Gm-Message-State: AKS2vOx9/im56vA7qnCmhdxCnUh2KwtgXF186zQ93u2PdFFQ9LkPuBbd nPqcoQF7PyqndgAGDThxP3e6AyqjMjvm X-Received: by 10.46.74.1 with SMTP id x1mr4448911lja.27.1497879332983; Mon, 19 Jun 2017 06:35:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.203.4 with HTTP; Mon, 19 Jun 2017 06:35:02 -0700 (PDT) In-Reply-To: <8637awpanu.fsf@gmail.com> References: <20170612170836.25174-1-prudo@linux.vnet.ibm.com> <20170612170836.25174-4-prudo@linux.vnet.ibm.com> <86vanxtguc.fsf@gmail.com> <20170616121026.024f664b@ThinkPad> <8637awpanu.fsf@gmail.com> From: Omair Javaid Date: Mon, 19 Jun 2017 13:35:00 -0000 Message-ID: Subject: Re: [RFC v4 3/9] Add basic Linux kernel support To: Yao Qi Cc: Philipp Rudo , "gdb-patches@sourceware.org" , Yao Qi , Peter Griffin , Andreas Arnez Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00511.txt.bz2 On 19 June 2017 at 14:52, Yao Qi wrote: > 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 thi= s 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 tha= t the >> kernel ptid, we generate from task_struct, usually has a different lwp t= han the >> same thread reported from the target beneath. Nevertheless we need the = target >> 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 kerne= l ptid. >> >> In short, this represents two different thread views (hardware vs. softw= are >> 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 PTI= D. */ >>> > + >>> > +struct lk_ptid_map >>> > +{ >>> > + struct lk_ptid_map *next; >>> >>> Can you use C++ stl list instead? >> >> As I already wrote Omair, my ptid_map was only meant to "somehow work" b= ut >> never to be permanent. Managing the ptid map will be the main task for = live >> debugging. That's why I think it is best when Omair changes this bit to >> whatever he needs. Hi Phillip, I have sent you my changes where I have also changed lk_ptid_map to a c++ map data type. Please have a look at those before making any further changes to your patch= es. Thanks! > > 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. > > -- > Yao (=E9=BD=90=E5=B0=A7)