Bug 18691 - Regression in solib-precsave.exp
Summary: Regression in solib-precsave.exp
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: record (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 7.10
Assignee: Yao Qi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-18 19:41 UTC by Doug Evans
Modified: 2015-08-18 15:25 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Doug Evans 2015-07-18 19:41:13 UTC
I'm seeing the following regressions in trunk and 7.10:

FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-precsave.exp: run until end part two
FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one

One wart, if not bug, I see is that we drop "object" here in memory_xfer_partial_1:

  if (inf != NULL
      && readbuf != NULL
      /* The dcache reads whole cache lines; that doesn't play well                                                                                              
         with reading from a trace buffer, because reading outside of                                                                                            
         the collected memory range fails.  */
      && get_traceframe_number () == -1
      && (region->attrib.cache
          || (stack_cache_enabled_p () && object == TARGET_OBJECT_STACK_MEMORY)
          || (code_cache_enabled_p () && object == TARGET_OBJECT_CODE_MEMORY)))
    {
      DCACHE *dcache = target_dcache_get_or_init ();

=>    return dcache_read_memory_partial (ops, dcache, memaddr, readbuf,
                                         reg_len, xfered_len);
    }

and then just hardcode TARGET_OBJECT_MEMORY in dcache_read_memory_partial.

=>    return ops->to_xfer_partial (ops, TARGET_OBJECT_MEMORY, NULL,
                                   myaddr, NULL, memaddr, len,
                                   xfered_len);

The first FAIL can be seen with "x/i 0x7ffff7bf56c0", it gets "Cannot access memory". However "x/b 0x7ffff7bf56c0" works.
x/i uses TARGET_OBJECT_CODE_MEMORY.
Comment 1 Yao Qi 2015-07-29 07:18:53 UTC
Patch is posted here https://sourceware.org/ml/gdb-patches/2015-07/msg00853.html
Comment 2 cvs-commit@gcc.gnu.org 2015-07-29 11:44:47 UTC
The master branch has been updated by Yao Qi <qiyao@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cc9f16aa882eb22cb2128c5eb8237fd453ab2988

commit cc9f16aa882eb22cb2128c5eb8237fd453ab2988
Author: Yao Qi <yao.qi@linaro.org>
Date:   Wed Jul 29 12:43:10 2015 +0100

    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-07-29  Yao Qi  <yao.qi@linaro.org>
    
    	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.
Comment 3 cvs-commit@gcc.gnu.org 2015-08-18 13:35:41 UTC
The gdb-7.10-branch branch has been updated by Yao Qi <qiyao@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=37419df723ec96b600030970e0fe97aaa82fa2e1

commit 37419df723ec96b600030970e0fe97aaa82fa2e1
Author: Yao Qi <yao.qi@linaro.org>
Date:   Wed Jul 29 12:43:10 2015 +0100

    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  <yao.qi@linaro.org>
    
    	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.
Comment 4 Yao Qi 2015-08-18 15:25:44 UTC
Patch is pushed into both master and 7.10 branch.