From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44031 invoked by alias); 18 Aug 2015 14:03:10 -0000 Mailing-List: contact gdb-testers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-testers-owner@sourceware.org Received: (qmail 43679 invoked by uid 89); 18 Aug 2015 14:03:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: kwanyin.sergiodj.net Received: from kwanyin.sergiodj.net (HELO kwanyin.sergiodj.net) (176.31.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Aug 2015 14:02:59 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [binutils-gdb/gdb-7.10-branch] PR record/18691: Fix fails in solib-precsave.exp From: sergiodj+buildbot@redhat.com To: gdb-testers@sourceware.org Message-Id: <37419df723ec96b600030970e0fe97aaa82fa2e1@gdb-build> Date: Tue, 18 Aug 2015 14:03:00 -0000 X-SW-Source: 2015-q3/txt/msg08070.txt.bz2 *** TEST RESULTS FOR COMMIT 37419df723ec96b600030970e0fe97aaa82fa2e1 *** Author: Yao Qi Branch: gdb-7.10-branch Commit: 37419df723ec96b600030970e0fe97aaa82fa2e1 PR record/18691: Fix fails in solib-precsave.exp We see the following regressions in testing on x86_64-linux, reverse-step^M Cannot access memory at address 0x2aaaaaed26c0^M (gdb) FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one when GDB reverse step into a function, GDB wants to skip prologue so it requests TARGET_OBJECT_CODE_MEMORY to read some code memory in memory_xfer_partial_1. However in dcache_read_memory_partial, the object becomes TARGET_OBJECT_MEMORY return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL, myaddr, NULL, memaddr, len, xfered_len); in reverse debugging, ops->to_xfer_partial is record_full_core_xfer_partial and it will return TARGET_XFER_E_IO because it can't find any records. The test fails. At this moment, the delegate relationship is like dcache -> record-core -> core -> exec and we want to GDB read memory across targets, which means if the requested memory isn't found in record-core, GDB can read memory from core, and exec even further if needed. I find raw_memory_xfer_partial is exactly what I want. gdb: 2015-08-18 Yao Qi PR record/18691 * dcache.c (dcache_read_memory_partial): Call raw_memory_xfer_partial. * target.c (raw_memory_xfer_partial): Make it non-static. * target.h (raw_memory_xfer_partial): Declare.