From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26511 invoked by alias); 5 May 2017 21:33:59 -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 26485 invoked by uid 89); 5 May 2017 21:33:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=rudo, taste X-HELO: mail-pg0-f65.google.com Received: from mail-pg0-f65.google.com (HELO mail-pg0-f65.google.com) (74.125.83.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 May 2017 21:33:57 +0000 Received: by mail-pg0-f65.google.com with SMTP id i63so2193808pgd.2 for ; Fri, 05 May 2017 14:34:00 -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=YS47oApKVWhG5Raw1lkThGd+Lol6TWq9/V6xaxlvtlE=; b=CpuIuFSnUzSVx1JbBvuB4GdN3XI+zrWGQftFyeNKBTCtHX11Mk/2Ip5fojrChorTi9 8FJO3KtIIQVBUNt1Llt6fqmvIs+lL6A3Ga3otf3y11X+01K8A25JxK+mbAOmQMcOMiH5 XCdEh6b+yuiV2MfyHTUUEAZw5ZkLsdCK3QiGDuBucuV3WlRodPZFZH0tUt6kMGbDYqY/ jAFS4AdHM47ggn3QMGxiWI60XAAeXXxXToql6ah4fjSuTf3zyaJkveJ0GAQcA0BkDfoE 112t9CfCdMJ//zgNb3X7YA+oVDnJzhEUjUlMNMc1dTZzU8feICyeVwl7bHu4ngLUQFDN Ah1w== X-Gm-Message-State: AN3rC/7mD6VFc3UAZIdSccXi5mDnuCwxDn5+0hZuvSfqBLiJdPfS04uP vOSEd8cxFcJVf69K X-Received: by 10.84.254.4 with SMTP id b4mr67704499plm.64.1494020039086; Fri, 05 May 2017 14:33:59 -0700 (PDT) Received: from E107787-LIN (gcc114.osuosl.org. [140.211.9.72]) by smtp.gmail.com with ESMTPSA id l7sm7913224pgn.10.2017.05.05.14.33.55 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 05 May 2017 14:33:58 -0700 (PDT) From: Yao Qi To: Philipp Rudo Cc: gdb-patches@sourceware.org, Yao Qi , Peter Griffin , Omair Javaid , Andreas Arnez Subject: Re: [RFC v3 4/8] Add kernel module support for linux-kernel target References: <20170316165739.88524-1-prudo@linux.vnet.ibm.com> <20170316165739.88524-5-prudo@linux.vnet.ibm.com> <868tmf8kn4.fsf@gmail.com> <20170503181620.53d0bd3f@ThinkPad> Date: Fri, 05 May 2017 21:33:00 -0000 In-Reply-To: <20170503181620.53d0bd3f@ThinkPad> (Philipp Rudo's message of "Wed, 3 May 2017 18:16:20 +0200") Message-ID: <86d1bnouo0.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-05/txt/msg00156.txt.bz2 Philipp Rudo writes: >> > +/* Translate a kernel virtual address ADDR to a physical address. */ >> > + >> > +CORE_ADDR >> > +lk_kvtop (CORE_ADDR addr)=20=20 >>=20 >> How about lk_kernel_vir_to_phy_addr? > > I prefer kvtop. It's much shorter and (for my taste) is just as readable= . But > I don't insist on keeping the name. Are there other opinions? > or maybe lk_vir_to_phy? >>=20 >> > +{ >> > + CORE_ADDR pgd =3D lk_read_addr (LK_ADDR (init_mm) >> > + + LK_OFFSET (mm_struct, pgd)); >> > + return LK_HOOK->vtop (pgd, addr); >> > +} >> > + >> > +/* Restore current_target to TARGET. */ >> > +static void >> > +restore_current_target (void *target) >> > +{ >> > + current_target.beneath =3D (struct target_ops *) target; >> > +} >> > + >> > +/* Function for targets to_xfer_partial hook. */ >> > + >> > +enum target_xfer_status >> > +lk_xfer_partial (struct target_ops *ops, enum target_object object, >> > + const char *annex, gdb_byte *readbuf, >> > + const gdb_byte *writebuf, ULONGEST offset, ULONGEST len, >> > + ULONGEST *xfered_len) >> > +{ >> > + enum target_xfer_status ret_val; >> > + struct cleanup *old_chain =3D make_cleanup (restore_current_target, >> > ops);=20=20 >>=20 >> Use make_scoped_restore instead of make_cleanup? > > Using a scoped_restore probably makes sense. Although I don't see the > advantage over old style cleanups other than having marginally shorter co= de ... > We want to reduce the usages of cleanup, and even completely remove it ultimately, so we should avoid using it in new code. >> > + >> > + current_target.beneath =3D ops->beneath; >> > +=20=20 >>=20 >> Any reasons you switch current_target.beneath temporarily? > > Yes. lk_kvtop (at least for s390) reads memory if the address is not > physical. Thus reading a virtual address calls xfer_partial twice. Once= for > the actual address and a second time for the data lk_kvtop needs. This c= an > lead to an endless recursion if there is a bug or memory corruption. Swi= tching > to the target beneath prevents this. > Does it work if you pass ops->beneath to lk_kvtop and all lk_read_XXX apis, so that we can use ops->beneath there instead of current_target. --=20 Yao (=E9=BD=90=E5=B0=A7)