[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: icache-dcache coherence on ARM
From:       Xiaozhu Meng <mxz297 () gmail ! com>
Date:       2019-05-07 2:52:23
Message-ID: CALjUE38AvjJQeF9AHwgAgw-0hcZG3FN4hT7CM5so68pUO9k=Cw () mail ! gmail ! com
[Download RAW message or body]

Hi John,

Thanks for hinting that GDB may also use procfs. I replaced ptrace() with
procfs to write code to the inferior and my code is now always working as
expected!

I appreciate your helps!

Thanks,

--Xiaozhu

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

> On 5/6/19 2:17 PM, Xiaozhu Meng wrote:
> > 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.
>
> I do not see any explicit cache management in linux-nat.c or
> arm-linux-nat.c,
> so my best guess is that GDB is relying on the kernel to manage this on
> Linux as well.  I do see that TARGET_OBJECT_MEMORY on Linux can sometimes
> use /proc/<pid>/mem instead of ptrace().  I'm not very familiar with the
> Linux kernel, but one thing to check might be that both ptrace and procfs
> are doing the i-cache invalidation.
>
> --
> John Baldwin
>
[prev in list] [next in list] [prev in thread] [next in thread]