From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28833 invoked by alias); 12 May 2011 21:21:04 -0000 Received: (qmail 28824 invoked by uid 22791); 12 May 2011 21:21:02 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_EG X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 May 2011 21:20:47 +0000 Received: by fxm18 with SMTP id 18so1747636fxm.0 for ; Thu, 12 May 2011 14:20:46 -0700 (PDT) Received: by 10.223.134.68 with SMTP id i4mr300004fat.87.1305235246131; Thu, 12 May 2011 14:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.112.141 with HTTP; Thu, 12 May 2011 14:20:26 -0700 (PDT) In-Reply-To: <35206.88376.qm@web112501.mail.gq1.yahoo.com> References: <341905.10459.qm@web112513.mail.gq1.yahoo.com> <208397.95006.qm@web112517.mail.gq1.yahoo.com> <4DA27006.1080607@codesourcery.com> <763549.92092.qm@web112506.mail.gq1.yahoo.com> <335149.24692.qm@web112515.mail.gq1.yahoo.com> <592215.58786.qm@web112508.mail.gq1.yahoo.com> <172713.29831.qm@web112503.mail.gq1.yahoo.com> <35206.88376.qm@web112501.mail.gq1.yahoo.com> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Thu, 12 May 2011 21:21:00 -0000 Message-ID: Subject: Re: [PATCH] arm reversible : To: paawan oza Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00316.txt.bz2 Hi On 7 May 2011 15:49, paawan oza 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 numb= er. > 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 inten= sion > 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. Goo= d.) 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) > + =C2=A0 uint32_t opcode; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0/* insn opcode. =C2=A0*/ > > 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 fie= lds.) > 3) > + start_address =3D start_address + 4 > - start_address =3D start_address - 4 > in two of the four cases. > > If you have a look at the code, start_address initialization is the key f= actor > 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(): >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tdep->arm_swi_record(reg_cach= e); > > 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 system= call 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%0= x " + "at address %s.\n"), + arm_insn_r->arm_insn, + paddress (arm_insn_r->gdbarch, arm_insn_r->this_add= r)); The `arm_insn_r->arm_insn' is a block of 4 bytes (ARM), not a classical num= ber. 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 <=3D 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 exi= st)? 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 =3D 0 , reg_src2=3D 0, reg_dest =3D 0; >+ uint32_t immed_high =3D 0, immed_low =3D 0, offset_12 =3D 0, tgt_mem_ad= dr =3D 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 =3D (0x0F !=3D 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 =3D (0x0F !=3D 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 =3D 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. --=20 Petr Hluzin