From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-prs-return-13720-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Received: (qmail 15400 invoked by alias); 22 May 2013 20:40:14 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Received: (qmail 15377 invoked by uid 48); 22 May 2013 20:40:14 -0000
From: "bccheng at android dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/15518] New: reverse debugging not working for ARM under
 cross-debugging setup
Date: Wed, 22 May 2013 20:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bccheng at android dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-15518-4717@http.sourceware.org/bugzilla/>
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-q2/txt/msg00309.txt.bz2

http://sourceware.org/bugzilla/show_bug.cgi?id=15518

             Bug #: 15518
           Summary: reverse debugging not working for ARM under
                    cross-debugging setup
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
        AssignedTo: unassigned@sourceware.org
        ReportedBy: bccheng@android.com
    Classification: Unclassified


In arm-tdep.c arm_mem_r is declared as the following:

/* ARM memory record structure.  */
struct arm_mem_r
{
  uint32_t len;    /* Record length.  */
  CORE_ADDR addr;   /* Memory address.  */
};

In various places the content is first initialized via the directly-addressed
record_buf_mem buffer:

          uint32_t record_buf_mem[8];
          :
          record_buf_mem[0] = 4;
          record_buf_mem[1] = tgt_mem_addr;

and copied over via the MEM_ALLOC macro:

#define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \
        do  \
          { \
            unsigned int mem_len = LENGTH; \
            if (mem_len) \
            { \
              MEMS =  XNEWVEC (struct arm_mem_r, mem_len);  \
              memcpy(&MEMS->len, &RECORD_BUF[0], \
                     sizeof(struct arm_mem_r) * LENGTH); \
            } \
          } \
          while (0)

The problem is that CORE_ADDR is declared as long and on 64-bit host it is 8
byte. Because of that record_buf_mem[1] is no longer the starting address of
the addr field but a padding space. Here is the memory dump through top-gdb:

(top-gdb) p /x arm_record.arm_mems[0]
$23 = {len = 0x4, addr = 0xe5832000}
(top-gdb) x /4x arm_record.arm_mems
0xb7f8d0:    0x00000004    0x0109e020    0xe5832000    0x00000000

where 0x0109e020 is the desired arm_record.arm_mems[0].addr value.

My temporary hack in my project is to declare thje addr field as uint32_t, but
I think it is not a generic fix and will cause problems for aarch64.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.