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

["xdje42 at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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.