From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Received: (qmail 3755 invoked from network); 10 Jan 2003 22:19:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 10 Jan 2003 22:19:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 05EBD3E02 for ; Fri, 10 Jan 2003 17:18:52 -0500 (EST) Message-ID: <3E1F46CB.9060104@redhat.com> Date: Fri, 10 Jan 2003 22:19:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Known problems with dcache? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00176.txt.bz2 Hello, In a recent discussion there was mention made of dcache. How, when enabled, it could make things? Are there any more details. The only problem I know with dcache is with the way it turns a single byte read into a 32 byte read. I think it should instead behave like a register fetch: - request exactly the specified amount - allow the target to supply additional data ex: ask for a byte, get back a page. I even think that, with that fix, the dcache could be enabled by default - it couldn't accidently do things like read beyond the end of memory and in the process trash something for instance. Andrew PS: Thinking about it, given ptrace's 4 byte straw, 32 bytes ~= 8 ptrace calls and that could be enough to make a difference?