Re: [PATCH] arm reversible : <phase_2_complete>

paawan oza
2011-04-28T19:22:59Z

but whole operation happens on target memory, so

after
GET_REG_VAL (reg_cache, ARM_PC_REGNUM, &u_buf.buf[0]);

we get scalar u_buf.s_word again in big-endian.

+ start_address = u_buf.s_word - \
+ (4 * (bit (thumb_insn_r->arm_insn, 8) + register_count)) ;

and above math is again in target memory in big endian machine and record is
saved to target memory.

I think it never gets fetched to host for any reason, Am I thinking correct?

Regards,
Oza.

----- Original Message ----
From: Tom Tromey <tromey@redhat.com>
To: paawan oza <paawan1982@yahoo.com>
Cc: Petr Hluzín <petr.hluzin@gmail.com>; gdb@sourceware.org;
gdb-patches@sourceware.org
Sent: Fri, April 29, 2011 12:30:05 AM
Subject: Re: [PATCH] arm reversible : <phase_2_complete>

>>>>> "Oza" == paawan oza <paawan1982@yahoo.com> writes:

Tom> It seems to me that extract_typed_address or something similar would be
Tom> better.

Oza> 1) are suggesting to use something else than unions ? whatever you have
Oza> described about union is right.

Oza> 2) why could I use extract_typed_address instead of direct assignment ?

extract_typed_address handles endianess and conversion from "array of
bytes" to "host scalar".

Oza> 3) in my understanding cross debug would not affect endianess
Oza> because all the record saving done on target memory and played back
Oza> in target memory. they never get fetched to host machine I think.
Oza> please clarify how would it affect host/target endianness issue ?

Here is a snippet from the patch:

+ GET_REG_VAL (reg_cache, ARM_PC_REGNUM, &u_buf.buf[0]);
[...]
+ start_address = u_buf.s_word - \
+ (4 * (bit (thumb_insn_r->arm_insn, 8) + register_count)) ;

Here, this fetches the raw register bits from the cache, which, IIUC,
are in target order. Then it uses the union to turn this into a scalar,
and does math on the scalar value.

So, if the host and target endianness differ, you will get the wrong
result.

Maybe I am missing something here?

Tom