Fix ARM machine state testcase failures

  Hi,

When running GDB's reverse debugging testsuite against a few ARM 
multilibs, i noticed failures in the machinestate* testcases.

Further investigation showed that push and pop instruction encodings A1 
and A2 were not being handled properly, thus we missed saving important 
contents from registers and memory. When going backwards, such contents 
were not restored and thus we ended up with a corrupted state that did 
not correspond to the real values we had at a particular point in time.

Attached is a patch that fixes around 36 failures for both 
gdb.reverse/machinestate.exp and gdb.reverse/machinestate-precsave.exp 
testcases, making them fully pass. This is for both armv7 and armv4. I 
still see failures for armv4 thumb though, so it needs a bit more 
investigation.

I see no regressions due to this patch for armv7, armv7 thumb, armv4 and 
armv4 thumb.

Ok for trunk?

Regards,
Luis
  

Luis Machado <lgustavo@codesourcery.com> writes:

> Further investigation showed that push and pop instruction encodings
> A1 and A2 were not being handled properly, thus we missed saving
> important contents from registers and memory. When going backwards,
> such contents were not restored and thus we ended up with a corrupted
> state that did not correspond to the real values we had at a
> particular point in time.

Luis,
I agree on your analysis, but I have a question to the code.  Do we
really need to handle PUSH and POP as a special case in LDR/STR
instructions?  AFAICS, PUSH/POP is just one kind of LDR/STR instruction
with post-indexed addressing.  Probably, we just need to tweak
arm_record_ld_st_imm_offset and arm_record_ld_st_multiple for
post-indexed addressing, at least LDR with post-indexed are not
handled in arm_record_ld_st_imm_offset.  What do you think?
  

Hi Yao,

On 10/17/2014 05:35 AM, Yao Qi wrote:
> Luis Machado <lgustavo@codesourcery.com> writes:
>
>> Further investigation showed that push and pop instruction encodings
>> A1 and A2 were not being handled properly, thus we missed saving
>> important contents from registers and memory. When going backwards,
>> such contents were not restored and thus we ended up with a corrupted
>> state that did not correspond to the real values we had at a
>> particular point in time.
>
> Luis,
> I agree on your analysis, but I have a question to the code.  Do we
> really need to handle PUSH and POP as a special case in LDR/STR
> instructions?  AFAICS, PUSH/POP is just one kind of LDR/STR instruction
> with post-indexed addressing.  Probably, we just need to tweak
> arm_record_ld_st_imm_offset and arm_record_ld_st_multiple for
> post-indexed addressing, at least LDR with post-indexed are not
> handled in arm_record_ld_st_imm_offset.  What do you think?
>

Can PUSH/POP always be described as a LD/ST instruction though? The 
documentation seems to indicate this is not always the case.

For POP, we have two encodings: A1 and A2. For A1, the documentation [1] 
states that we should use LDM/LDMIA/LDFD if BitCount(register_list) < 2. 
I interpreted this as "Unless we are popping only a single register, we 
should use the POP instruction".

For PUSH, it seems to be the same case, but with STMDB/STMFD.

Disassembler output sometimes shows push/pop alongside the equivalent 
ld/st syntax, but other times only push/pop is shown.

Base on the above, there is indeed a little overlap between the handling 
of st/ld and push/pop instructions. For the sake of better code 
organization and readability, i went for special-casing push/pop and 
making it immediately obvious what we were handling, given the amount of 
ARM encodings we need to handle.

Does it make sense?

[1] ARM Architecture Reference Manual - ARMv7-A and ARMv7-R edition
  

Luis Machado <lgustavo@codesourcery.com> writes:

> Can PUSH/POP always be described as a LD/ST instruction though? The

Yes, I think so.  PUSH/POP is the special case of LD/ST instruction, in
terms of instruction encoding, see details blow.

> documentation seems to indicate this is not always the case.
>
> For POP, we have two encodings: A1 and A2. For A1, the documentation
> [1] states that we should use LDM/LDMIA/LDFD if
> BitCount(register_list) < 2. I interpreted this as "Unless we are
> popping only a single register, we should use the POP instruction".

The doc suggests what instructions to use here, nothing to do with
instruction encoding.

 - POP A2 (POP instruction encoding A2) is a special case of LDR
   (immediate, ARM) A1.

   LDR (immediate, ARM), Encoding A1:
   cond  0 1 0 P U 0 W 1 Rn       Rt  imm12
   POP Encoding A2:
   cond  0 1 0 0 1 0 0 1 1 1 0 1  Rt 0 0 0 0 0 0 0 0 0 1 0 0

   we decode POP A2 as a LDR (immediate) A1, that means, P = 0, U = 1,
   W = 0, Rn = 13, imm12 = 4.  Then, index = false, add = true, wback =
   true,

   This is the post-indexed addressing.  IOW, "pop {r1}" is the same
   encoding as "ldr r1, [sp], #4".

 - POP A1 is a special case of LDMIA A1.

   LDMIA Encoding A1:
   cond 1 0 0 0 1 0 W 1 Rn        register_list
   POP Encoding A1:
   cond 1 0 0 0 1 0 1 1 (1 1 0 1) register_list

   we code POP A1 as a LDIMA, that means W = 1, Rn = 13.  IOW,
   "pop {r1, r2}" encoding is the same as "ldmia sp!, {r1, r2}".

 - PUSH A1 is a special case of STMDB A1.

   STMDB A1:
   cond 1 0 0 1 0 0 W 0 Rn      register_list

   PUSH A1:
   cond 1 0 0 1 0 0 1 0 1 1 0 1 register_list

   we decode PUSH A1 as STMDB A1, that means W = 1, Rn = 13.
   "push {r1, r2}" is the same encoding as "stmdb sp!, {r1, r2}".

 - Push A2 is a special case of STR (immediate ARM) A1.

   STR (immediate) A1:
   cond 0 1 0 P U 0 W 0 Rn      Rt imm12

   PUSH A2:
   cond 0 1 0 1 0 0 1 0 1 1 0 1 Rt 0 0 0 0 0 0 0 0 0 1 0 0

   we code PUSH A2 as STR (immediate) A1, then P = 1, U = 0, W = 1, Rn =
   13, imm12 = 4.  This is the STR with pre-indexed addressing mode.  Instruction
   "push {r1}" encoding is the same as "str r1, [sp, #-4]!".

IMO, we should fix gdb handling ld/st instructions in reverse debugging,
instead of handling only push/pop instructions.