[Bug record/18691] New: Regression in solib-precsave.exp

[Bug record/18691] New: Regression in solib-precsave.exp

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18691

            Bug ID: 18691
           Summary: Regression in solib-precsave.exp
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: record
          Assignee: unassigned at sourceware dot org
          Reporter: xdje42 at gmail dot com
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug record/18691] Regression in solib-precsave.exp

[sergiodj at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18691

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergiodj at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug record/18691] Regression in solib-precsave.exp

[qiyao at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18691

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |qiyao at gcc dot gnu.org
           Assignee|unassigned at sourceware dot org   |qiyao at gcc dot gnu.org

--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
Patch is posted here
https://sourceware.org/ml/gdb-patches/2015-07/msg00853.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug record/18691] Regression in solib-precsave.exp

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18691

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug record/18691] Regression in solib-precsave.exp

[qiyao at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18691

Yao Qi <qiyao at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |7.10

--- Comment #4 from Yao Qi <qiyao at gcc dot gnu.org> ---
Patch is pushed into both master and 7.10 branch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.