From: Yao Qi <qiyaoltc@gmail.com>
To: Philipp Rudo <prudo@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org, Yao Qi <yao.qi@linaro.org>,
Peter Griffin <peter.griffin@linaro.org>,
Omair Javaid <omair.javaid@linaro.org>,
Andreas Arnez <arnez@linux.vnet.ibm.com>
Subject: Re: [RFC v3 4/8] Add kernel module support for linux-kernel target
Date: Fri, 05 May 2017 21:33:00 -0000 [thread overview]
Message-ID: <86d1bnouo0.fsf@gmail.com> (raw)
In-Reply-To: <20170503181620.53d0bd3f@ThinkPad> (Philipp Rudo's message of "Wed, 3 May 2017 18:16:20 +0200")
Philipp Rudo <prudo@linux.vnet.ibm.com> writes:
>> > +/* Translate a kernel virtual address ADDR to a physical address. */
>> > +
>> > +CORE_ADDR
>> > +lk_kvtop (CORE_ADDR addr)
>>
>> 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?
>>
>> > +{
>> > + CORE_ADDR pgd = 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 = (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 = make_cleanup (restore_current_target,
>> > ops);
>>
>> 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 code ...
>
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 = ops->beneath;
>> > +
>>
>> 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 can
> lead to an endless recursion if there is a bug or memory corruption. Switching
> 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.
--
Yao (齐尧)
next prev parent reply other threads:[~2017-05-05 21:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 16:57 [RFC v3 0/8] Support for Linux kernel debugging Philipp Rudo
2017-03-16 16:57 ` [RFC v3 1/8] Convert substitute_path_component to C++ Philipp Rudo
2017-04-20 20:02 ` Sergio Durigan Junior
2017-05-03 16:20 ` Philipp Rudo
2017-03-16 16:58 ` [RFC v3 7/8] Add privileged registers for s390x Philipp Rudo
2017-03-16 16:58 ` [RFC v3 6/8] Seperate common s390-tdep.* from s390-linux-tdep.* Philipp Rudo
2017-03-16 16:58 ` [RFC v3 4/8] Add kernel module support for linux-kernel target Philipp Rudo
2017-05-02 13:15 ` Yao Qi
2017-05-03 16:16 ` Philipp Rudo
2017-05-05 21:33 ` Yao Qi [this message]
2017-05-08 9:18 ` Philipp Rudo
2017-05-08 13:05 ` Yao Qi via gdb-patches
2017-03-16 16:58 ` [RFC v3 5/8] Add commands " Philipp Rudo
2017-03-16 16:58 ` [RFC v3 3/8] Add basic Linux kernel support Philipp Rudo
2017-04-16 22:59 ` Omair Javaid
2017-05-03 14:38 ` Philipp Rudo
2017-04-20 11:09 ` Omair Javaid
2017-04-24 15:24 ` Andreas Arnez
2017-05-03 14:13 ` Omair Javaid
2017-05-03 15:20 ` Philipp Rudo
2017-05-03 14:38 ` Philipp Rudo
2017-05-02 11:14 ` Yao Qi
2017-05-03 15:36 ` Philipp Rudo
2017-05-07 23:54 ` Omair Javaid
[not found] ` <20170508132204.7a733dc2@ThinkPad>
[not found] ` <CADrjBPqijRQFH4jthAedFzOzMLchpyvM53aXc9grOCjS2YUNCw@mail.gmail.com>
2017-05-10 9:03 ` Philipp Rudo
2017-05-10 9:36 ` Philipp Rudo
2017-05-19 8:45 ` Yao Qi
2017-05-19 15:24 ` Andreas Arnez
2017-05-19 16:28 ` John Baldwin
2017-05-19 17:05 ` Andreas Arnez
2017-05-19 17:40 ` John Baldwin
2017-05-22 10:18 ` Andreas Arnez
2017-03-16 16:58 ` [RFC v3 8/8] Add S390 support for linux-kernel target Philipp Rudo
2017-03-16 16:58 ` [RFC v3 2/8] Add libiberty/concat styled concat_path function Philipp Rudo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86d1bnouo0.fsf@gmail.com \
--to=qiyaoltc@gmail.com \
--cc=arnez@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=omair.javaid@linaro.org \
--cc=peter.griffin@linaro.org \
--cc=prudo@linux.vnet.ibm.com \
--cc=yao.qi@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox