From: oza Pawandeep <oza.pawandeep@gmail.com>
To: Tom Tromey <tromey@redhat.com>
Cc: "Petr Hluzín" <petr.hluzin@gmail.com>,
"paawan oza" <paawan1982@yahoo.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
"chandra krishnappa" <chandra_roadking@yahoo.com>
Subject: Re: [PATCH] arm reversible : <phase_2_complete>
Date: Sat, 19 Nov 2011 09:43:00 -0000 [thread overview]
Message-ID: <CAK1A=4wz=2uU71yFz39EdOMvrLEyR+dX9TEogJ6vRR2Pu4pDNw@mail.gmail.com> (raw)
In-Reply-To: <m3vcqieb48.fsf@fleche.redhat.com>
Hi Tom,
I have fixed most of your comments.
as far as formatting is concerned, I am still trying to hard to get it
right. but at the end mailer ends up messing it up :(
following are the comments.
We try not to put FIXME comments into new code.
Nobody ever fixes them.
You can just write an informative comment instead: "We have no way to
read the SPSR value". Assuming that is accurate.
Oza >> removed FIX ME comments and put appropriate comments.
The enclosing function, arm_record_extension_space, takes care to return
a value, but (1) the meaning of the return value is not documented in
the function's introductory comment (this problems affects many of the
new functions), and (2) the only caller does not check it.
oza >> thanks for pointing that out, I have added descirption and
caler must be checking return value which I have corrected.
What happens if the user hits an instruction which is not handled?
Right now a message is printed. But shouldn't it abort the operation in
some other way? That is, is emitting a message really sufficient?
Oza >> I have chaged the description a bit, the abort message is
printed, but at the same time return value is -1, which will cause gdb
standard stack unwinding, with error(...) symentics.
Formatting looks weird.
A typedef for the function type would probably make this look less
strange.
oza >> converted to typedef defination, it looks simpler now.
No need for this backslash.
Oza >> removed.
oza> + if (arm_record.arm_regs)
oza> + xfree (arm_record.arm_regs);
oza> + if (arm_record.arm_mems)
oza> + xfree (arm_record.arm_mems);
This is fine as long as you have proved that nothing in any possible
call path here can throw an exception. If anything throws an exception,
then you are leaking memory and should instead use a cleanup.
Oza >> I have added a new function deallocate_reg_arm....
the design is in such a way, that any function goes for allocation
until and unless it supports the insn; otherwise memory is always
local/cache, so in case of exception it simply unwinds wihtout
affecting dymanic memory.
and in case we have allocated memory, we make sure that we come to the
end of the process_record funntion and we free them irrespective of
success or failure;
oza> + /* Parse swi insn args, sycall record. */
oza> + int (*arm_swi_record) (struct regcache *regcache);
Since this is only used in your Phase 3 patch, it belongs there.
Oza >> In my thinking, it was necessary to add this function pointer
because I had already added logic of decoding insn in phase 2, where I
am just checking if this fp is NULL.
where this fp was initialised to NULL, which will be replaced with
valid fp in phase 3.
wihtout including this, phase 2 would have missed on insn decoding.
Regards,
Oza.
On Fri, Nov 18, 2011 at 2:10 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "oza" == oza Pawandeep <oza.pawandeep@gmail.com> writes:
>
> oza> please find the latest patch below.
>
> No ChangeLog entry.
>
> No NEWS entry.
>
> Patch got mangled by your mailer again.
>
> oza> + memcpy(®S[0],&RECORD_BUF[0],sizeof(uint32_t)*LENGTH); \
>
> Wrong spacing.
>
> oza> + memcpy(&MEMS->len,&RECORD_BUF[0],sizeof(struct arm_mem_r) * LENGTH); \
>
> Likewise.
>
> oza> +}arm_record_strx_t;
>
> Spacing.
>
> oza> +}record_type_t;
>
> Again.
>
> oza> +
> oza> +static int
> oza> +arm_record_strx (insn_decode_record *arm_insn_r, uint32_t *record_buf,
> oza> + uint32_t *record_buf_mem, arm_record_strx_t str_type)
>
> Indentation.
>
> oza> + if ((14 == arm_insn_r->opcode) || (10 == arm_insn_r->opcode))
>
> Too many parens.
>
> oza> + else if ((12 == arm_insn_r->opcode) || (8 == arm_insn_r->opcode))
>
> Again.
>
> oza> + else if ((11 == arm_insn_r->opcode) || (15 == arm_insn_r->opcode)
> oza> + || (2 == arm_insn_r->opcode) || (6 == arm_insn_r->opcode))
>
> Again, plus indentation.
>
> oza> + regcache_raw_read_unsigned (reg_cache, reg_src1
> oza> + , &u_regval[0]);
>
> Formatting -- "," is on the wrong line.
>
> I see most of these issues multiple times. Please go over the entire
> patch and fix them all. I feel like I asked this before.
>
> oza> + /* FIX ME: How to read SPSR value? */
>
> We try not to put FIXME comments into new code.
> Nobody ever fixes them.
>
> You can just write an informative comment instead: "We have no way to
> read the SPSR value". Assuming that is accurate.
>
> The enclosing function, arm_record_extension_space, takes care to return
> a value, but (1) the meaning of the return value is not documented in
> the function's introductory comment (this problems affects many of the
> new functions), and (2) the only caller does not check it.
>
> What happens if the user hits an instruction which is not handled?
> Right now a message is printed. But shouldn't it abort the operation in
> some other way? That is, is emitting a message really sufficient?
>
> oza> +/* Decode arm/thumb insn depending on condition cods and opcodes; and
> oza> dispatch it. */
> oza> +
> oza> +static int
> oza> +decode_insn (insn_decode_record *arm_record, record_type_t record_type,
> oza> + uint32_t insn_size)
>
> E.g., here the return value should be documented.
>
> oza> + static int (*const arm_handle_insn[8])
> oza> + (insn_decode_record*) =
>
> Formatting looks weird.
> A typedef for the function type would probably make this look less
> strange.
>
> oza> + /* if this insn has fallen into extension space then we need
> oza> not decode it anymore. */
> oza> + if (!INSN_RECORDED(arm_record))
> oza> + {
> oza> + arm_handle_insn[insn_id] (arm_record);
>
> ... it seems like there should be a check of the return value here.
> I don't understand this.
>
> oza> + if (record_arch_list_add_mem \
>
> No need for this backslash.
>
> oza> + ((CORE_ADDR)arm_record.arm_mems[no_of_rec].addr,
> oza> + arm_record.arm_mems[no_of_rec].len))
>
> Really messed up formatting.
>
> oza> + if (arm_record.arm_regs)
> oza> + xfree (arm_record.arm_regs);
> oza> + if (arm_record.arm_mems)
> oza> + xfree (arm_record.arm_mems);
>
> This is fine as long as you have proved that nothing in any possible
> call path here can throw an exception. If anything throws an exception,
> then you are leaking memory and should instead use a cleanup.
>
> oza> + /* Parse swi insn args, sycall record. */
> oza> + int (*arm_swi_record) (struct regcache *regcache);
>
> Since this is only used in your Phase 3 patch, it belongs there.
>
> Tom
>
next prev parent reply other threads:[~2011-11-19 9:43 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-29 15:38 paawan oza
2011-05-31 18:05 ` Tom Tromey
2011-06-03 7:44 ` paawan oza
2011-06-03 7:51 ` paawan oza
2011-07-12 21:10 ` Tom Tromey
2011-07-13 3:17 ` chandra krishnappa
2011-07-13 5:36 ` paawan oza
2011-07-13 15:20 ` Tom Tromey
2011-07-14 4:49 ` chandra krishnappa
2011-07-14 15:01 ` Yao Qi
2011-07-13 6:57 ` paawan oza
[not found] ` <1316327455.23344.YahooMailNeo@web112509.mail.gq1.yahoo.com>
2011-09-19 7:37 ` paawan oza
2011-09-22 17:12 ` oza Pawandeep
2011-09-27 6:52 ` oza Pawandeep
2011-10-06 18:01 ` oza Pawandeep
[not found] ` <CAK1A=4xuUT++WRzdUnZc0KodYF0AiukUyJa7Pr=wzb4i-OQ5eQ@mail.gmail.com>
2011-10-08 2:50 ` Fwd: " paawan oza
2011-10-11 18:11 ` [PATCH] arm reversible : <phase_2_complete> how to go ahead ? paawan oza
2011-10-11 19:02 ` Tom Tromey
2011-10-14 20:13 ` [PATCH] arm reversible : <phase_2_complete> Tom Tromey
2011-10-15 3:46 ` paawan oza
2011-10-15 7:01 ` chandra krishnappa
2011-10-15 9:32 ` Yao Qi
2011-10-15 13:33 ` Yao Qi
2011-10-15 16:34 ` oza Pawandeep
2011-10-15 17:38 ` oza Pawandeep
2011-10-16 8:00 ` oza Pawandeep
2011-10-16 8:44 ` oza Pawandeep
2011-10-17 4:25 ` Yao Qi
2011-10-17 3:18 ` Yao Qi
2011-10-17 4:28 ` oza Pawandeep
2011-10-17 15:42 ` chandra krishnappa
2011-11-03 17:10 ` Tom Tromey
2011-11-04 16:27 ` Yao Qi
2011-10-16 23:32 ` Petr Hluzín
2011-10-22 15:42 ` oza Pawandeep
2011-10-23 10:17 ` oza Pawandeep
2011-10-24 7:43 ` Petr Hluzín
2011-10-25 7:20 ` Yao Qi
2011-11-03 17:41 ` Tom Tromey
2011-11-05 17:36 ` Petr Hluzín
2011-11-03 17:38 ` Tom Tromey
2011-11-05 17:35 ` Petr Hluzín
2011-11-07 15:39 ` Tom Tromey
2011-11-08 6:02 ` oza Pawandeep
2011-11-08 10:17 ` Yao Qi
2011-11-08 10:45 ` oza Pawandeep
2011-11-09 5:28 ` oza Pawandeep
2011-11-09 6:08 ` oza Pawandeep
2011-11-17 9:24 ` oza Pawandeep
2011-11-17 9:52 ` Yao Qi
2011-11-17 20:40 ` Tom Tromey
2011-11-18 3:18 ` oza Pawandeep
2011-11-18 17:22 ` Tom Tromey
2011-11-19 9:43 ` oza Pawandeep [this message]
2011-11-19 11:39 ` oza Pawandeep
2011-12-02 18:36 ` Tom Tromey
2011-12-03 8:20 ` oza Pawandeep
2011-12-03 14:18 ` oza Pawandeep
2011-12-03 16:32 ` Petr Hluzín
2011-12-03 18:46 ` oza Pawandeep
2011-12-03 19:02 ` oza Pawandeep
2011-12-03 20:30 ` Petr Hluzín
[not found] ` <1322975560.12415.YahooMailNeo@web112518.mail.gq1.yahoo.com>
2011-12-04 7:09 ` paawan oza
2011-12-04 1:47 ` Yao Qi
2011-12-04 8:26 ` oza Pawandeep
2011-12-04 11:33 ` oza Pawandeep
2011-12-04 13:29 ` Petr Hluzín
2011-12-04 14:46 ` Yao Qi
2011-12-04 17:00 ` oza Pawandeep
2011-12-04 23:46 ` Yao Qi
2011-12-05 5:35 ` oza Pawandeep
2011-12-05 8:12 ` Yao Qi
2011-12-05 16:02 ` oza Pawandeep
2011-12-19 6:26 ` oza Pawandeep
2011-12-20 19:11 ` Tom Tromey
2011-12-28 12:43 ` oza Pawandeep
2012-01-05 11:01 ` oza Pawandeep
2012-01-05 12:03 ` Eli Zaretskii
2012-01-05 16:17 ` Tom Tromey
2012-01-05 18:17 ` oza Pawandeep
2012-01-06 8:06 ` oza Pawandeep
2012-01-06 19:13 ` Tom Tromey
2012-01-07 6:31 ` oza Pawandeep
2012-01-09 16:25 ` Tom Tromey
2012-02-02 6:29 ` oza Pawandeep
[not found] ` <m38vkfoiut.fsf@fleche.redhat.com>
[not found] ` <CAK1A=4xrUBzcG1i7NHyEtmAjwx0nbYmkePFS9_kQcS3E1gaduA@mail.gmail.com>
[not found] ` <m3haz19ezl.fsf@fleche.redhat.com>
[not found] ` <CAK1A=4w+yq9AvRMukPcKpZnGjrVnPbE3zdScwRd1Skubt0KHWA@mail.gmail.com>
2012-03-07 5:35 ` oza Pawandeep
2012-03-08 16:32 ` Tom Tromey
2012-03-09 9:30 ` oza Pawandeep
2012-03-09 16:47 ` Tom Tromey
2012-03-12 6:23 ` oza Pawandeep
2012-03-12 6:55 ` Yao Qi
2012-03-12 9:14 ` oza Pawandeep
2012-03-12 15:32 ` oza Pawandeep
2012-03-12 19:43 ` Tom Tromey
2012-03-13 5:41 ` oza Pawandeep
2011-12-03 15:06 ` oza Pawandeep
2011-12-20 19:05 ` Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2011-08-10 17:09 chandra krishnappa
2011-08-11 1:34 ` Yao Qi
[not found] <BANLkTins056mmtd_9U_4iYXEeC2jRZSRsA@mail.gmail.com>
2011-06-06 17:42 ` chandra krishnappa
2011-07-05 8:47 ` oza Pawandeep
2011-05-24 7:19 paawan oza
[not found] <341905.10459.qm@web112513.mail.gq1.yahoo.com>
[not found] ` <m3d3m8xdf7.fsf@fleche.redhat.com>
[not found] ` <208397.95006.qm@web112517.mail.gq1.yahoo.com>
[not found] ` <4DA27006.1080607@codesourcery.com>
2011-04-16 21:03 ` [PATCH] arm reversible : progress <phase_2_complete> paawan oza
2011-04-20 19:16 ` [PATCH] arm reversible : <phase_2_complete> paawan oza
2011-04-21 20:55 ` Petr Hluzín
2011-04-22 5:49 ` paawan oza
2011-04-22 5:55 ` oza Pawandeep
2011-04-25 14:03 ` paawan oza
2011-05-01 1:20 ` Petr Hluzín
2011-05-02 14:47 ` Tom Tromey
2011-05-04 21:33 ` Petr Hluzín
2011-05-05 15:29 ` Tom Tromey
2011-05-07 13:50 ` paawan oza
2011-05-09 14:57 ` Tom Tromey
2011-05-10 5:42 ` paawan oza
2011-05-10 15:37 ` Tom Tromey
2011-05-12 5:06 ` paawan oza
2011-05-10 5:50 ` paawan oza
2011-05-12 21:21 ` Petr Hluzín
2011-05-24 6:44 ` paawan oza
2011-05-07 13:56 ` paawan oza
[not found] ` <172713.29831.qm__351.089161313389$1303740245$gmane$org@web112503.mail.gq1.yahoo.com>
2011-04-25 19:57 ` Tom Tromey
2011-04-28 18:26 ` paawan oza
2011-04-28 19:00 ` Tom Tromey
2011-04-28 19:22 ` paawan oza
[not found] ` <727567.12089.qm__13056.408687453$1304018591$gmane$org@web112511.mail.gq1.yahoo.com>
2011-04-28 19:36 ` Tom Tromey
2011-04-30 16:16 ` paawan oza
2011-05-02 13:28 ` Tom Tromey
2011-04-20 19:10 [PATCH] arm reversible <phase_2_complete> oza Pawandeep
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='CAK1A=4wz=2uU71yFz39EdOMvrLEyR+dX9TEogJ6vRR2Pu4pDNw@mail.gmail.com' \
--to=oza.pawandeep@gmail.com \
--cc=chandra_roadking@yahoo.com \
--cc=gdb-patches@sourceware.org \
--cc=paawan1982@yahoo.com \
--cc=petr.hluzin@gmail.com \
--cc=tromey@redhat.com \
/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