Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Xiaozhu Meng <mxz297@gmail.com>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb@sourceware.org
Subject: Re: icache-dcache coherence on ARM
Date: Mon, 06 May 2019 21:17:00 -0000	[thread overview]
Message-ID: <CALjUE38vyfzeg_-A7vzS+rGdADNMX2sDg4eRv393r6jeJyb_hw@mail.gmail.com> (raw)
In-Reply-To: <5954fa76-7b6a-1544-6516-5d11cb395b26@FreeBSD.org>

Hi John,

Thanks for your reply!

I asked this question because our project on Linux actually encountered
this problem where we use ptrace to write new code into the inferior and
then continue the inferior. The continued inferior sometimes works as
expected, but sometimes crashes due to SIGILLs on seemingly legitimate
instructions.

So, I am very interested in seeing how GDB deals with this problem on
Linux.

Thanks,

--Xiaozhu

On Mon, May 6, 2019 at 3:52 PM John Baldwin <jhb@freebsd.org> wrote:

> On 5/6/19 12:30 PM, Xiaozhu Meng wrote:
> > Hi,
> >
> > I am reading gdb's source code to hopefully get answers for a question
> that
> > I have in my other project.
> >
> > On ARM, the architecture does not guarantee that icache and dcache are
> > coherent. When GDB writes a software breakpoint into the inferior's
> address
> > space, is it possible that the inferior executes outdated code in icache
> > and thus miss the software breakpoint?
> >
> > I try to search around the gdb code base to understand whether GDB
> flushes
> > icache or not, but could not find answers.
> >
> > I appreciate any feedback!
>
> I suspect that the cache flushing is done by the host OS kernel in response
> to the write.  This is what happens on FreeBSD at least where any
> executable
> page in a process written to via ptrace(PT_IO) has its i-cache flushed by
> this
> code in sys/kern/sys_process.c in proc_rwmem():
>
>                 /*
>                  * Now do the i/o move.
>                  */
>                 error = uiomove_fromphys(&m, page_offset, len, uio);
>
>                 /* Make the I-cache coherent for breakpoints. */
>                 if (writing && error == 0) {
>                         vm_map_lock_read(map);
>                         if (vm_map_check_protection(map, pageno, pageno +
>                             PAGE_SIZE, VM_PROT_EXECUTE))
>                                 vm_sync_icache(map, uva, len);
>                         vm_map_unlock_read(map);
>                 }
>
>
> --
> John Baldwin
>


  reply	other threads:[~2019-05-06 21:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 19:30 Xiaozhu Meng
2019-05-06 20:52 ` John Baldwin
2019-05-06 21:17   ` Xiaozhu Meng [this message]
2019-05-06 21:37     ` John Baldwin
2019-05-07  2:52       ` Xiaozhu Meng

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=CALjUE38vyfzeg_-A7vzS+rGdADNMX2sDg4eRv393r6jeJyb_hw@mail.gmail.com \
    --to=mxz297@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=jhb@freebsd.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