You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(17) |
2
(8) |
3
(23) |
4
(16) |
5
(13) |
6
(13) |
|
7
|
8
|
9
|
10
(2) |
11
(4) |
12
(2) |
13
(14) |
|
14
(13) |
15
(7) |
16
(13) |
17
(20) |
18
(15) |
19
(15) |
20
(13) |
|
21
(15) |
22
(13) |
23
(13) |
24
(2) |
25
(5) |
26
(12) |
27
|
|
28
(3) |
29
(13) |
30
(13) |
31
(14) |
|
|
|
|
From: Paralkar Anmol-B. <B0...@fr...> - 2013-07-15 21:24:14
|
Hello Julian, I want to understand the legal requirements to contribute code back to Valgrind. I looked up: http://valgrind.org/docs/manual/manual-intro.html If you contribute code to Valgrind, please ensure your contributions are licensed as "GPLv2, or (at your option) any later version." This is so as to allow the possibility of easily upgrading the license to GPLv3 in future. If you want to modify code in the VEX subdirectory, please also see the file VEX/HACKING.README in the distribution. and I looked up the VEX/HACKING.README and VEX/LICENSE.README, and: http://valgrind.org/help/contributing.html and the valgrind-developers ML. - but what does it mean to license as "GPL v2 or later"? If one submits a patch to the valgrind-developers mailing list - is that enough or does my company have to sign some legal paperwork first? Kindly clarify. If there is any paperwork needed, please could you send it to me? Thank you. Sincerely, Anmol P. Paralkar |
|
From: Paralkar Anmol-B. <B0...@fr...> - 2013-07-15 21:16:24
|
Hello Randy, The Valgrind with e500v2 support is released as a part of Freescale's Linux SDK (v1.4) for QorIQ Processors, please download the ISO from: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SDKLINUX&fpsp=1&tab=Design_Tools_Tab If you need just the source tarball, please do let me know. As regards getting through the legal clearance, I expect it to be months. (Apart from the internal process, I just wrote to Julian to understand the legal requirements for contributing, if there is any paperwork needed, etc.) Thanks very much for your mail. Regards, Anmol. From: Randy MacLeod [mailto:rwm...@gm...] Sent: Wednesday, July 10, 2013 9:23 AM To: Paralkar Anmol-B07584 Cc: Julian Seward; val...@li... Subject: Re: [Valgrind-developers] Freescale Support for e500v2 SPE in Valgrind. Anmol, Any news on getting over the legal hurdles for releasing support for the e500v2 SPE architecture? Do you expect it to be weeks or months? :) // Randy On Wed, Jun 19, 2013 at 1:28 PM, Paralkar Anmol-B07584 <B0...@fr...<mailto:B0...@fr...>> wrote: Hello Julian, I have created: https://bugs.kde.org/show_bug.cgi?id=321396 PS: I do not know how to make the bug 'Assigned To' myself; kindly help with the same. Please note that the patches have to clear an internal legal review process at Freescale before they can be posted externally. (Meanwhile, the port is available via our upcoming SDK-1.4 release). Kindly advise on any copyright assignment/legal paperwork if needed, so that we can work on it as well. A brief overview of the work is: - All of the SPE instructions (about 220) are supported: - FP, Fractional arithmetic instructions are "implemented" as-is via dirty-helpers. - All other instructions (integer arithmetic, load-store, logical, ...) by generating classic Power 32 via expressing in VEX IR. - There is at least one unit-test per instruction, typically tested against a sequence of randomly generated input data (recorded in the test's source code) and creating the test's baseline by running standalone on linux and then verifying that we obtain the same results when run under Valgrind. - Typical UNIX Utilities like: wc(1), grep(1), ls(1), head(1), gcc(1), ... work fine on it, used typically. - TODO's: - Support for e500v2 in Valgrind's internal gdbserver is yet to be added. - ptrace(2), prlimit(2), (and perhaps a lot of other syscalls) yet unsupported. - Need to warn on misaligned SPE load-stores (I suppose the e500v2 linux kernel handles these internally, so we get a difference in behavior). I am sure we'll need to split the patches/rework them some before they become acceptable for submission and I look forward to working with the community. Thank you very much. Regards, Anmol. > -----Original Message----- > From: Julian Seward [mailto:js...@ac...<mailto:js...@ac...>] > Sent: Monday, June 10, 2013 7:10 AM > To: Paralkar Anmol-B07584 > Cc: val...@li...<mailto:val...@li...> > Subject: Re: [Valgrind-developers] Freescale Support for e500v2 SPE in > Valgrind. > > On 05/31/2013 06:50 PM, Paralkar Anmol-B07584 wrote: > > Hello, > > > > Freescale recently added support for the e500v2 SPE architecture based > off of Valgrind-3.8.1; > > this will be available in the upcoming SDK-1.4 release and is intended > to be contributed back > > to the public-domain mainline Valgrind sources. > > Is there a bug in the bug tracker containing the patches, for > review/testing > etc? > > J > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Valgrind-developers mailing list Val...@li...<mailto:Val...@li...> https://lists.sourceforge.net/lists/listinfo/valgrind-developers -- ../Randy/.. |
|
From: Peter B. <be...@vn...> - 2013-07-15 17:03:49
|
On Mon, 2013-07-15 at 09:16 -0700, Carl E. Love wrote: > Remember, this patch was for the proposal to just replace the tbegin > with a branch to execute the failure path for the TM. The tbegin and > tend instructions would not actually get executed. Thus we would need > to go find the address for the failure handler and can not get it from > the TM registers. For Julian's proposal (1), I do not think we should replace the tbegin. with a branch. Instead, we should implement the tbegin. instruction, but in a way that it always returns failure. Since the hw tbegin. initializes TFHAR to CIA+4, you don't need to branch anywhere, just set cr0 to 0x2, and initialize the HTM SPRs like you are currently doing and then continue on to the next instruction. Nothing more is needed. > > Remember that tbegin. initializes the TFHAR to CIA+4, so you > > just have to set failure_tgt to the address of nextInstr. > > If we execute the tbegin, which is not done according to proposal 1. Julian's proposal (1) at a high level is just to make the transaction begin instruction fail so that we always execute the failure path. That doesn't mean we have to replace it with a branch. As I said above and I thought was clear from some of my earlier posts, we should implement a simple tbegin. instruction and execute it. > > Your comment is correct, but you are incorrectly clearing cr0, > > which signifies the tbegin. succeeded. You need to initialize > > it to 0x2. > > Well we are trying to make it execute the failure path, that was the > first proposal, so yes we do need to clear it. No. To execute the failure path, you need to set cr0 to 0x2 to signify a transaction begin failure. If clearing cr0 makes you execute the failure path, then you have a bug somewhere else you need to track down. Probably it is due to you (incorrectly) grabbing the "failure address" from the branch and the compiler has changed the "beq <failure_path>" with a "bne <success_path>". So what you think is the address of the failure handler is really the address of the success handler. In that case, clearing cr0 would make you execute the failure path, but that is just two bugs causing you to accidentally doing the right thing. I will say this more more time so we're all on the same page. For Julian's (1) proposal, we (Power) should implement and execute a tbegin. instruction. It should do: 1) set cr0 to 0x2 2) Initialize TFHAR to CIA+4 3) Initialize TEXASR 4) Initialize TFIAR (probably to CIA, ie, the address of tbegin.) 5) Continue executing at the next instruction. There really isn't anything more it needs to do. Peter |
|
From: Carl E. L. <ce...@li...> - 2013-07-15 16:17:02
|
On Sun, 2013-07-14 at 23:50 -0500, Peter Bergner wrote:
> On Thu, 2013-07-11 at 07:33 -0700, Carl E. Love wrote:
> > The patch causes the execution flow to take
> > the TM failure path as expected. The compiler is generating a branch if not equal to decide if it
> > should take the TM path or the failure path. For now, the Valgrind patch just assumes the compiler
> > will always generate the branch if not equal instruction to take one of the two paths. Furthermore,
> > it is assumed there will always be a failure path. I need to talk with Peter when he gets back about
> > the code generated by the compiler to determine if the compiler might generate different code
> > sequences.
>
Remember, this patch was for the proposal to just replace the tbegin
with a branch to execute the failure path for the TM. The tbegin and
tend instructions would not actually get executed. Thus we would need
to go find the address for the failure handler and can not get it from
the TM registers. So, your comments below really show the issues with
trying to make this work, i.e. we can't rely on the branch being the
next instruction and we have to handle the compiler generating code
using either beq and bne instructions. The patch is just a proof of
concept patch for 64-bit mode only. I didn't worry about the additional
complexity of handling 32-bit mode as well. But this gives us an idea
of what the issues with the first proposal.
I will keep working on the second proposal from Julian where we do let
the CPU execute the TM instructions then pull the needed failure path
address from the TM register.
> The compiler is free to and actually does generate either a beq or a bne
> depending on the circumstances. Specifically, the code it can generate
> can look like:
>
> tbegin.
> ...
> beq <failure handler>
> // fall-through success handler
>
> or
>
> tbegin.
> ....
> bne <success handler>
> // fall-through failure handler
>
> Note that the "...." above denotes possible instructions that
> might be placed between the tbegin. and the conditional branch,
> so you cannot assume the conditional branch immediately follows
> the tbegin. Luckily, you don't need to look at the branch at
> all. You are only looking at it to compute the address of
> the failure handler, but that is not correct. The address of
> the failure handler is stored in the TFHAR register and the
> tbegin. initializes it to CIA+4 (ie, the next instruction).
>
>
> > + case 0x80: // 128
> > + DIP("mfspr r%u (TFHAR)\n", rD_addr);
> > + putIReg( rD_addr, getGST( PPC_GST_TFHAR) );
> > + break;
> > + case 0x81: // 129
> > + DIP("mfspr r%u (TFIAR)\n", rD_addr);
> > + putIReg( rD_addr, getGST( PPC_GST_TFIAR) );
> > + break;
> > + case 0x82: // 130
> > + DIP("mfspr r%u (TEXASR)\n", rD_addr);
> > + putIReg( rD_addr, getGST( PPC_GST_TEXASR) );
> > + break;
>
> Note that the texasr is a 64-bit register in both 32-bit
> and 64-bit modes. In 32-bit mode, the "mfspr TEXASR,rX"
> should just place the lower 32-bits of the texasr into
> rX. Is that what this code ends up doing?
>
> You are also missing the "mfspr TEXASRU,rX", which is
> used by 32-bit code to get the upper 32-bits of the
> texasr into rX.
>
>
>
> > + case 0x80: // 128
> > + DIP("mtspr r%u (TFHAR)\n", rS_addr);
> > + putGST( PPC_GST_TFHAR, mkexpr(rS) );
> > + break;
> > + case 0x81: // 129
> > + DIP("mtspr r%u (TFIAR)\n", rS_addr);
> > + putGST( PPC_GST_TFIAR, mkexpr(rS) );
> > + break;
> > + case 0x82: // 130
> > + DIP("mtspr r%u (TEXASR)\n", rS_addr);
> > + putGST( PPC_GST_TEXASR, mkexpr(rS) );
> > + break;
>
> Ditto here.
>
>
>
> > + DIP("tbegin. %d\n", R);
> > + if (opc1_next == 0x10) { // conditional branch
> [snip]
>
> As mentional above, there is no need to look at the following
> branch, so your "if (opc1_next == 0x10)" test can be removed.
> Just unconditionally execute the then clause code and remove
> the error code in the else clause.
>
>
> > + /* Get the address of the failure handler from the conditional
> > + * branch in the next instruction location.
> > + */
> > + if ( flag_AA )
> > + failure_tgt = mkSzAddr( ty, extend_s_16to64( BD_u16 ) );
> > + else
> > + failure_tgt = mkSzAddr( ty, guest_CIA_curr_instr +
> > + (Long)extend_s_16to64( BD_u16 ) );
>
> To be pedantic, the address of the failure handler is equal to
> the address that is in the TFHAR register, not the address from
> the conditional branch. That is especially true given that the
> compiler is free to generate either:
>
> tbegin.
> ...
> beq <failure handler>
> // fall-through success handler
>
> or
>
> tbegin.
> ....
> bne <success handler>
> // fall-through failure handler
>
> Remember that tbegin. initializes the TFHAR to CIA+4, so you
> just have to set failure_tgt to the address of nextInstr.
If we execute the tbegin, which is not done according to proposal 1.
>
>
>
> > + /* Set the CR0 field to indicate the tbegin failed. Then let
> > + * the code do the branch to the failure path.
> > + *
> > + * 000 || 0 Transaction initiation successful,
> > + * unnested (Transaction state of
> > + * Non-transactional prior to tbegin.)
> > + * 010 || 0 Transaction initiation successful, nested
> > + * (Transaction state of Transactional
> > + * prior to tbegin.)
> > + * 001 || 0 Transaction initiation unsuccessful,
> > + * (Transaction state of Suspended prior
> > + * to tbegin.)
> > + */
> > + if (mode64)
> > + /* 0x0010 takes transactional path */
> > + /* 0x0000 takes the failure path */
> > + set_CR0(mkU64(0x0000));
> > + else
> > + set_CR0(mkU32(0x0000));
>
> Your comment is correct, but you are incorrectly clearing cr0,
> which signifies the tbegin. succeeded. You need to initialize
> it to 0x2.
Well we are trying to make it execute the failure path, that was the
first proposal, so yes we do need to clear it.
>
> Stylistically, using "0x0000" looks like you're trying to stuff
> 4 4-bit nibbles into cr0, but a cr register can only hold 4-bits
> (ie, 1 nibble). You could use 0x2 or 0b0010, which both look more
> like just 1 nibble of data. Then again, I don't know the valgrind
> code formatting rules and maybe that is how things are written?
> If so, just ignore this comment of mine.
OK, will take the stylistic comments. :-)
>
>
> Peter
>
>
|
|
From: <sv...@va...> - 2013-07-15 11:27:55
|
petarj 2013-07-15 12:27:45 +0100 (Mon, 15 Jul 2013)
New Revision: 13453
Log:
mips32: Update list of ignore files
Update list of ignore files for directory none/tests/mips32.
Modified directories:
trunk/none/tests/mips32/
Modified: trunk/none/tests/mips32/
Property changed: trunk/none/tests/mips32 (+0 -0)
___________________________________________________________________
Name: svn:ignore
- Makefile
Makefile.in
.deps
+ Makefile
Makefile.in
.deps
vfp
allexec
LoadStore1
MoveIns
block_size
round
MemCpyTest
FPUarithmetic
branches
MIPS32int
LoadStore
SignalException
bug320057-mips32
|
|
From: <sv...@va...> - 2013-07-15 10:16:23
|
petarj 2013-07-15 11:16:09 +0100 (Mon, 15 Jul 2013)
New Revision: 13452
Log:
mips32: add missing exp file for Bug#320057
r13450 misses the exp file.
Added files:
trunk/none/tests/mips32/bug320057-mips32.stderr.exp
Added: trunk/none/tests/mips32/bug320057-mips32.stderr.exp (+0 -0)
===================================================================
|
|
From: Peter B. <be...@vn...> - 2013-07-15 04:51:01
|
On Thu, 2013-07-11 at 07:33 -0700, Carl E. Love wrote:
> The patch causes the execution flow to take
> the TM failure path as expected. The compiler is generating a branch if not equal to decide if it
> should take the TM path or the failure path. For now, the Valgrind patch just assumes the compiler
> will always generate the branch if not equal instruction to take one of the two paths. Furthermore,
> it is assumed there will always be a failure path. I need to talk with Peter when he gets back about
> the code generated by the compiler to determine if the compiler might generate different code
> sequences.
The compiler is free to and actually does generate either a beq or a bne
depending on the circumstances. Specifically, the code it can generate
can look like:
tbegin.
...
beq <failure handler>
// fall-through success handler
or
tbegin.
....
bne <success handler>
// fall-through failure handler
Note that the "...." above denotes possible instructions that
might be placed between the tbegin. and the conditional branch,
so you cannot assume the conditional branch immediately follows
the tbegin. Luckily, you don't need to look at the branch at
all. You are only looking at it to compute the address of
the failure handler, but that is not correct. The address of
the failure handler is stored in the TFHAR register and the
tbegin. initializes it to CIA+4 (ie, the next instruction).
> + case 0x80: // 128
> + DIP("mfspr r%u (TFHAR)\n", rD_addr);
> + putIReg( rD_addr, getGST( PPC_GST_TFHAR) );
> + break;
> + case 0x81: // 129
> + DIP("mfspr r%u (TFIAR)\n", rD_addr);
> + putIReg( rD_addr, getGST( PPC_GST_TFIAR) );
> + break;
> + case 0x82: // 130
> + DIP("mfspr r%u (TEXASR)\n", rD_addr);
> + putIReg( rD_addr, getGST( PPC_GST_TEXASR) );
> + break;
Note that the texasr is a 64-bit register in both 32-bit
and 64-bit modes. In 32-bit mode, the "mfspr TEXASR,rX"
should just place the lower 32-bits of the texasr into
rX. Is that what this code ends up doing?
You are also missing the "mfspr TEXASRU,rX", which is
used by 32-bit code to get the upper 32-bits of the
texasr into rX.
> + case 0x80: // 128
> + DIP("mtspr r%u (TFHAR)\n", rS_addr);
> + putGST( PPC_GST_TFHAR, mkexpr(rS) );
> + break;
> + case 0x81: // 129
> + DIP("mtspr r%u (TFIAR)\n", rS_addr);
> + putGST( PPC_GST_TFIAR, mkexpr(rS) );
> + break;
> + case 0x82: // 130
> + DIP("mtspr r%u (TEXASR)\n", rS_addr);
> + putGST( PPC_GST_TEXASR, mkexpr(rS) );
> + break;
Ditto here.
> + DIP("tbegin. %d\n", R);
> + if (opc1_next == 0x10) { // conditional branch
[snip]
As mentional above, there is no need to look at the following
branch, so your "if (opc1_next == 0x10)" test can be removed.
Just unconditionally execute the then clause code and remove
the error code in the else clause.
> + /* Get the address of the failure handler from the conditional
> + * branch in the next instruction location.
> + */
> + if ( flag_AA )
> + failure_tgt = mkSzAddr( ty, extend_s_16to64( BD_u16 ) );
> + else
> + failure_tgt = mkSzAddr( ty, guest_CIA_curr_instr +
> + (Long)extend_s_16to64( BD_u16 ) );
To be pedantic, the address of the failure handler is equal to
the address that is in the TFHAR register, not the address from
the conditional branch. That is especially true given that the
compiler is free to generate either:
tbegin.
...
beq <failure handler>
// fall-through success handler
or
tbegin.
....
bne <success handler>
// fall-through failure handler
Remember that tbegin. initializes the TFHAR to CIA+4, so you
just have to set failure_tgt to the address of nextInstr.
> + /* Set the CR0 field to indicate the tbegin failed. Then let
> + * the code do the branch to the failure path.
> + *
> + * 000 || 0 Transaction initiation successful,
> + * unnested (Transaction state of
> + * Non-transactional prior to tbegin.)
> + * 010 || 0 Transaction initiation successful, nested
> + * (Transaction state of Transactional
> + * prior to tbegin.)
> + * 001 || 0 Transaction initiation unsuccessful,
> + * (Transaction state of Suspended prior
> + * to tbegin.)
> + */
> + if (mode64)
> + /* 0x0010 takes transactional path */
> + /* 0x0000 takes the failure path */
> + set_CR0(mkU64(0x0000));
> + else
> + set_CR0(mkU32(0x0000));
Your comment is correct, but you are incorrectly clearing cr0,
which signifies the tbegin. succeeded. You need to initialize
it to 0x2.
Stylistically, using "0x0000" looks like you're trying to stuff
4 4-bit nibbles into cr0, but a cr register can only hold 4-bits
(ie, 1 nibble). You could use 0x2 or 0b0010, which both look more
like just 1 nibble of data. Then again, I don't know the valgrind
code formatting rules and maybe that is how things are written?
If so, just ignore this comment of mine.
Peter
|