public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-15518-4717@http.sourceware.org/bugzilla/> (raw)

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.


             reply	other threads:[~2013-05-22 20:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 20:40 bccheng at android dot com [this message]
2013-09-17 12:59 ` [Bug gdb/15518] " omair.javaid at linaro dot org
2024-01-01 16:10 ` ssbssa at sourceware dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15518-4717@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).