Re: [PATCH] arm reversible : <phase_2_complete>

[Petr HluzÃn <petr dot hluzin at gmail dot com>]

Hi

On 7 May 2011 15:49, paawan oza <paawan1982@yahoo.com> wrote:
> Hi Petr and Tom,
>
> I have implemented most of your comments..
> The comments which I could not put it in are below with explanation.
>
> 1) ARM_RECORD_ARCH_LIST_ADD_REG is used only at 2 places, but probably I wanted
> to
>
> give clear interface where it just takes only one argument, register number.
> I should have done it for memory, but have not done yet.
>
> sure, it hides local variable usage and it doesnt look good, but my intension
> was to give clear interface
>
> to function process_record modifiers.
>
> I am still thinking over it.

(The third revision (2011-05-12) of the patch no longer uses the macro. Good.)

Clear interface... yes, the macro hides one parameter, but I do not
see it as an advantage. In fact the hiding looks more like an
disadvantage - it is harder to reason what the code does. (This would
apply to its memory variant if you did one.)

Why do you think there is an use for an interface?
Are there going to be more register-memory-recording implementations
behind the interface?

If not then the interface would be only a scaffolding prepared for an
event which will not happen. Sure, the need to add another
implementation of change-recording may arise one day but it may not
and if it does then altering the code is matter of doing "find all
references" in IDE. In theory any part of a program can have an
alternate implementation.

> 2) > + Â uint32_t opcode; Â Â Â Â Â Â Â/* insn opcode. Â*/
>
> I understand that above is one of the fields of arm_insn_record, but why I am
> usiong it as global field,
> because the decoding bits by this field kind of global and common to most of the
> insns.
>
> probably I would like to just extract it once and use anywhere, but
> unfortunately I have extracted in every function
> and seems local, will work on that though.

FYI: The struct field is always initialized by "bits
(arm_insn_r->arm_insn, 21, 24)" - except in
arm_handle_coproc_data_proc_insn(). If it is not a bug then the
initializations cannot be merged to one place.

(For me: the 3rd revision of the patch still uses the opcode and decode fields.)

> 3)
> + start_address = start_address + 4
> - start_address = start_address - 4
> in two of the four cases.
>
> If you have a look at the code, start_address initialization is the key factor
> for addressing mode.
> not how start_address later gets incremented.. so even in decrement mode,
> increment is necessary but
> initialization is different.

Oh, I now see. You are right. I was confused because I would wrote
that differently, but your version is good.

> 4)
> In arm_handle_coproc_data_proc_insn():
>> + Â Â Â Â Â Âtdep->arm_swi_record(reg_cache);
>
> When this line is executed this function still returns -1 (i.e. failure).
> I guess the two if's are intended to return success then.
>
> oza: the coprocessor insns are not implemented and syscall record too. so in
> both cases we return
> -1.

But when it does become implemented the branch will incorrectly return
a failing value.

I assume the recording of the instruction OS-dependent, right?
And OS-kind will be run-time configurable?

If yes, then I suggest documenting the variability, e.g.:
-/* Parse swi insn args, sycall record.  */
+/* Parse swi insn args, OS-dependent.  */

> 5)
> The return value is never tested. What is its meaning?
>
> The parsed args seem to be stored as a side-effect. Where are they stored?
> (Answers should go to comments.)
> (Since this is an indirect call, the documentation should be more
> verbose than usual cases.)
>
> Oza: swi basically equivalent to sysenter an int80 insn on x86, so systemcall is
> implemented that way.
> I am going to work on that implementation in phase 3.
> phase 2 does not support it.

OK. I guess it will use `arm_insn_r' to record the changes - which
would have to be added as an argument. FYI.

Moving on.
Comments on the version 3 (2011-05-12) of the patch.
http://sources.redhat.com/ml/gdb/2011-05/msg00028.html

Typos: recors, mendatory,
preccedded (-> preceded), accorindly, addresing - addressing,
wihtout optmization
(Some typos were fixed in v3 before I could reply to v2. Good.)

A function arm_handle_data_pro_mic_load_str_insn() in old patch is named as
arm_handle_data_pro_mic_load_str_insn()
in the last patch. The previous name contained more familiar
word/contractions ("misc", "proc")
Was that accidental?

+#define GET_REG_VAL(REGCACHE,NO,VAL)  \
+        regcache_raw_read_unsigned (REGCACHE, NO, VAL);
+
+#define GET_REG_VAL_SIGNED(REGCACHE,NO,VAL)  \
+        regcache_raw_read_unsigned (REGCACHE, NO, VAL);

What do you gain by hiding calls by the macros?
E.g. do you expect the the function to be changed?

My concern is the slight difficulty reading the code: a reader is more
likely to be familiar with the regcache_raw_read..() functions than
the macros.


In arm_handle_data_pro_mic_load_str_insn()
+  struct
+    {
+      ULONGEST unsigned_regval;
+    } u_buf[2];

You can get the same result (and simpler code) with
ULONGEST u_buf[2];
or maybe also better name with
ULONGEST u_regvals[2];

The same applies to other functions.

in handle_extension_space():
+    printf_unfiltered (_("Process record does not support instruction 0x%0x "
+                       "at address %s.\n"),
+                       arm_insn_r->arm_insn,
+                       paddress (arm_insn_r->gdbarch, arm_insn_r->this_addr));

The `arm_insn_r->arm_insn' is a block of 4 bytes (ARM), not a classical number.
Therefore I feel its more appropriate to include leading zeroes, i.e.
use "0x%08x" format.
Which formating prefer other fellows?
(Does have '0' in "%0x" have any effect?)
(In multiple functions.)


In arm_handle_data_pro_mic_load_str_insn()
>+   /* following is always true, in case none of the above conditions meet, it will */
>+  else if (arm_insn_r->opcode <= 15)

You can add "else assert(false)" branch and get rid of the comment.
The assert statement has exact meaning, the meaning is faster to read
and machines check it. (Even some tools may understand it.)
A comment may go wrong over time as a code is changed (and may be
wrong even now).

The same goes for arm_handle_data_proc_imm_insn().

>+#define NO_OF_TYPE_OF_ARM_INSNS 8
>+#define NO_OF_TYPE_OF_THUMB_INSNS 8

These are used only for arm_handle_insn[] and thumb_handle_insn[]
array initializations.
So far they have the meaning of "the size of the arrays" - which can
be easily deduced from the arrays itself.
Plus they are fixed by the instruction set architecture - not
configurable, unlikely to change, perhaps not to be used on more
places - therefore the usual guideline of not embedding magic
constants does not apply here.
It is a minor point.

How do other people feel about it (an identifier which does not have to exist)?
Oza, do you plan to use them at more places?


> > > +  struct regcache *regcache;
> >
> > Many functions use unnecesary cast to init local var, e.g. `(struct
> > regcache*) thumb_insn_r->regcache'.
> > Most functions do not actually use the var.

This is still true.


In arm_handle_ld_st_imm_offset_insn()
>+  uint32_t reg_src1 = 0 , reg_src2= 0, reg_dest = 0;
>+  uint32_t immed_high = 0, immed_low = 0, offset_12 = 0, tgt_mem_addr = 0;
>+  uint32_t record_buf[8], record_buf_mem[8];

Vars reg_src2, immed_high, immed_low are unused.
There are also some unused variables with whole-function scope in
other functions. Should I report them?


> > The ? and : should be at the begging.
> > GNU style guideline: "When you split an expression into multiple
> > lines, split it before an operator, not after one."
> > Also I find it more readable.
>
>+      ret = (0x0F != arm_record->cond) \
>+            ? \
>+            arm_handle_insn[insn_id] (arm_record) \
>+            : \
>+            handle_extension_space(arm_record);

Erm, this is even weirder. It is supposed to look like:
      ret = (0x0F != arm_record->cond)
            ? arm_handle_insn[insn_id] (arm_record)
            : handle_extension_space(arm_record);

Also the patch seems to have extra slashes ('\') at the end.
They are unnecessary. Maybe even incorrect. (Did an email client do that?)


In thumb_handle_ld_st_reg_offset_insn ():
Consider applying this change:
-    }
-
-  opcode1 = bits (thumb_insn_r->arm_insn, 10, 12);
-  if (opcode1)
+  } else if(bits (thumb_insn_r->arm_insn, 10, 12))

This would allow you to get rid of the `goto' statements.


In decode_insn()
> +  struct
> +    {
> +      ULONGEST unsigned_regval;
> +      gdb_byte buf[insn_size];
> +    } u_buf;

The `unsigned_regval' field is not referenced.

-- 
Petr Hluzin