Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 (齐尧)


  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