From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59567 invoked by alias); 7 May 2019 02:52:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 59559 invoked by uid 89); 7 May 2019 02:52:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*Ad:U*gdb, jhbfreebsdorg, jhb@freebsd.org, U*jhb X-HELO: mail-wr1-f43.google.com Received: from mail-wr1-f43.google.com (HELO mail-wr1-f43.google.com) (209.85.221.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 May 2019 02:52:36 +0000 Received: by mail-wr1-f43.google.com with SMTP id s15so19926523wra.12 for ; Mon, 06 May 2019 19:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eepWgKA/FCfR9uvq5Nm7QdflIYKRN2m5k5DcrRCFwXo=; b=aC3CGXhT7FEwbitaUwe9LW51GHU2zz51ZxezAnLDA1flEZdYxuadNXfbHFTmQussZk ByDwGcTAmMs8j8cMlyf0HJntJ7dL15AxImyvQEDwbXMtPIkZep9hDWNj+T/8VKGsqqoI 8t90L6Lw5eLfrmpRs1fHdWgZE7xJX7P99U3u/FxCKjojA1tENbngiGAfOtkxWh30pAdV 5+WHCbdGPJGdDb0H8s0xm60fxa6wNhjq0oxZ2bpAJGMVr8CuWy/AH+Mc6sqgtfzd1v2F 2D5Z2+9DWlrOeAtvVXT+wns4ryv30t4arrACxpcnGozoBLvB0KbytcDVyVfg89+BVxz+ RR3w== MIME-Version: 1.0 References: <5954fa76-7b6a-1544-6516-5d11cb395b26@FreeBSD.org> <1b15495b-eb18-d910-2c0b-b446f5649b67@FreeBSD.org> In-Reply-To: <1b15495b-eb18-d910-2c0b-b446f5649b67@FreeBSD.org> From: Xiaozhu Meng Date: Tue, 07 May 2019 02:52:00 -0000 Message-ID: Subject: Re: icache-dcache coherence on ARM To: John Baldwin Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00015.txt.bz2 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 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//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 >