From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42822 invoked by alias); 6 May 2019 21:17:52 -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 42812 invoked by uid 89); 6 May 2019 21:17:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 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, continued, H*r:sk:gdb@sou, H*i:sk:5954fa7 X-HELO: mail-wm1-f53.google.com Received: from mail-wm1-f53.google.com (HELO mail-wm1-f53.google.com) (209.85.128.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 May 2019 21:17:50 +0000 Received: by mail-wm1-f53.google.com with SMTP id s18so6065915wmh.0 for ; Mon, 06 May 2019 14:17:50 -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=8SdYBvDIzSHG3uLadDYeNNqeKHJZKsghEl73MuROlhw=; b=WhoZPAho36EArWO3q+H6u4yWpcjkkKvKy8drA+IUQJHyrelpHK0a7tOOfi1nvtBqoI s6mXD8rwSv6o5SU9vs/oKzwFVTcUiMbRRQpTLCSu0qEFlKHbb1Icu9uOqlAlwTRr2cst riqt8B8Dlynwbean1xeHKMq9rWUqguBbR4H2f8oUZB90C06rMNo/G1STuhpzeb1Ywj+Z +WxYrHaXvJ6Ti8NenG8KGt86/B10p0jT3YLHd3v5DoHPiasgJtEr1f+uhOQld7gVtBTN 4k3IyaohU8cwzL0XAlmoHwY+J9kQeSEFusLoqjkg6qMsUwQWa6oBi1JKFgk0ZLMQBJkV h+xw== MIME-Version: 1.0 References: <5954fa76-7b6a-1544-6516-5d11cb395b26@FreeBSD.org> In-Reply-To: <5954fa76-7b6a-1544-6516-5d11cb395b26@FreeBSD.org> From: Xiaozhu Meng Date: Mon, 06 May 2019 21:17: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/msg00013.txt.bz2 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 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 >