From: "Petr Hluzín" <petr.hluzin@gmail.com>
To: oza Pawandeep <oza.pawandeep@gmail.com>
Cc: Tom Tromey <tromey@redhat.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
chandra krishnappa <chandra_roadking@yahoo.com>
Subject: Re: [PATCH] arm reversible : <phase_2_complete>
Date: Mon, 24 Oct 2011 07:43:00 -0000 [thread overview]
Message-ID: <CAC=yr6DHNy0JtDtg9uRNd8dnEVpaBmgwJZrON4tv1vuATS1T4w@mail.gmail.com> (raw)
In-Reply-To: <CAK1A=4yvDqEOYH7gzUoLB+-=S_GSV=EMno=Wq9Y+17feSZN+aQ@mail.gmail.com>
Hi Oza, hi folks
On 22 October 2011 17:41, oza Pawandeep <oza.pawandeep@gmail.com> wrote:
> @Chandra: please take this patch and run your tests on this. (it is
> integrated with gdb7.3)
You probably meant to say the patch should be applied to gdb-7.3. It
is not there yet.
> +
> +#define INSN_RECORDED(ARM_RECORD) \
> + ((ARM_RECORD->arm_regs || ARM_RECORD->arm_mems))
Is it supposed to return a boolean-like value? If yes then it would be
more descriptive to use INSN_IS_RECORDED. However I do not know if GDB
uses this convention. Tom?
Also there are extra parentheses. There should be parentheses around
ARM_RECORD argument.
Consider adding `== NULL' to the two tests to make it clear the fields
are pointers, not integers or booleans, and that the || is supposed to
be logical, not bit-wise. (I have heard few people have tools good
enough to tell them the types.)
In arm_record_strx:
> + if (ARM_RECORD_STRH == str_type)
> + {
> + *(record_buf_mem) = 2;
> + *(record_buf_mem + 1) = tgt_mem_addr;
Why don't you use `record_buf_mem[0]' and `record_buf_mem[1]' syntax?
> + arm_insn_r->mem_rec_count = 1;
> + }
> + else if (ARM_RECORD_STRD == str_type)
> + {
> + *(record_buf_mem) = 4;
> + *(record_buf_mem + 1) = tgt_mem_addr;
> + *(record_buf_mem + 2) = 4;
> + *(record_buf_mem + 3) = tgt_mem_addr + 4;
The same here and several more places in this function. Search for "*("
In arm_record_extension_space:
> +
> + opcode1 = bits (arm_insn_r->arm_insn, 20, 27);
> + opcode1 = bits (arm_insn_r->arm_insn, 4, 7);
> + if (arm_insn_r->cond)
> + {
> + /* PLD has no affect on architectural state, it just affects
> the caches. */
> + if (5 == ((opcode1 & 0xE0) >> 5))
This condition is never true because `opcode1 = bits
(arm_insn_r->arm_insn, 4, 7)' is value in range 0..15 therefore
`opcode1 & 0xE0' is always zero. I think.
> + {
> + /* BLX(1) */
> + record_buf[0] = ARM_PS_REGNUM;
> + record_buf[1] = ARM_LR_REGNUM;
> + arm_insn_r->reg_rec_count = 2;
> + }
> + /* STC2, LDC2, MCR2, MRC2, CDP2: <TBD>, cprocessor insn. */
Typo cprocessor.
> +
> + opcode1 = bits (arm_insn_r->arm_insn, 23, 27);
> + if ((24 == opcode1) && bit (arm_insn_r->arm_insn, 21) &&
> + !(INSN_RECORDED(arm_insn_r)))
Operators should go to beginning of a new line, not at the end of previous line.
I.e.
if ((24 == opcode1) && bit (arm_insn_r->arm_insn, 21)
&& !(INSN_RECORDED(arm_insn_r)))
It is on multiple places involving the macro.
> + if (!INSN_RECORDED(arm_record))
> + {
> + arm_handle_insn[insn_id] (arm_record);
> + }
> + }
> + else if (THUMB_INSN_SIZE_BYTES == insn_size)
> + {
> + /* As thumb does not have condition codes, we set negatiive. */
Typo negatiive.
In function arm_record_extension_space:
The function stores some values in local variable `uint32_t
record_buf[8]' but these values are never read. I suspect you forgot
to add calls to:
+ REG_ALLOC (arm_insn_r->arm_regs, arm_insn_r->reg_rec_count, record_buf);
+ MEM_ALLOC (arm_insn_r->arm_mems, arm_insn_r->mem_rec_count, record_buf_mem);
In function arm_record_extension_space:
The calls to INSN_RECORDED(arm_insn_r) will always return false,
because the fields referenced by the macro are always 0 at entry to
arm_record_extension_space() and the function does not modify them.
The missing calls to REG_ALLOC() & MEM_ALLOC() would modify them in
the end but it would be late anyway. I guess you will have to either
add a local flag variable or alter control flow - either way the
INSN_RECORDED seems like going to be unused.
(Function arm_record_strx() works differently and is not affected.)
In function arm_record_extension_space:
Consider adding `gdb_assert (!INSN_RECORDED(arm_insn_r))' at the
beginning of the function. That way it will be easy to understand
which part of code does change the state.
In function decode_insn:
Consider adding `gdb_assert (!INSN_RECORDED(arm_insn_r))' just before
call to arm_record_extension_space. That way it will be easy to
understand which part of code does change the state. Or use return
value from arm_record_extension_space() - this would make the
understanding even faster.
In function decode_insn:
Consider adding these assertions at the exit:
+ gdb_assert (arm_record->mem_rec_count == 0 || arm_record->arm_mems != NULL);
+ gdb_assert (arm_record->reg_rec_count == 0 || arm_record->arm_regs != NULL);
This would catch the missing REG_ALLOC calls in arm_record_extension_space().
Issues remaining since the previous revision:
Tom Tromey or someone should decide whether to use gdb_assert or not
(in the situation described in [1]).
Probably turn field `decode' & friends in insn_decode_record_t to
local variables. (Phase 3?)
[1] http://sourceware.org/ml/gdb-patches/2011-10/msg00449.html
--
Petr Hluzin
next prev parent reply other threads:[~2011-10-24 0:13 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 [this message]
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
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='CAC=yr6DHNy0JtDtg9uRNd8dnEVpaBmgwJZrON4tv1vuATS1T4w@mail.gmail.com' \
--to=petr.hluzin@gmail.com \
--cc=chandra_roadking@yahoo.com \
--cc=gdb-patches@sourceware.org \
--cc=oza.pawandeep@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