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
(15) |
2
(15) |
3
(16) |
4
(16) |
5
(19) |
6
(15) |
|
7
(1) |
8
(4) |
9
|
10
(4) |
11
(14) |
12
(5) |
13
|
|
14
(1) |
15
|
16
|
17
(12) |
18
(25) |
19
(18) |
20
(18) |
|
21
(16) |
22
(1) |
23
(18) |
24
(15) |
25
|
26
(3) |
27
(18) |
|
28
(8) |
29
|
30
(4) |
|
|
|
|
|
From: Rick G. <rcg...@ve...> - 2013-04-17 22:30:46
|
On 4/17/2013 5:58 PM, John Reiser wrote: >> Let us assume that system calls aren't a problem, as we can work around >> those here thanks to QNX's micro kernel nature by simply pushing syscalls >> over an IP link. What would be the next major show stopper, purely from >> within valgrind itself? > The target (ARM) shared libraries. Logically there are two separate > name spaces for "the" filesystem (ARM target vs. x86 host) but physically > there is only one (the x86 host). Of course you can try LD_LIBRARY_PATH, > etc., but probably that's only the beginning. > You are describing a binary translation system - not too bad when the host and target OS's are similar in semantics. DEC's binary translation systems come to mind. Intercept the system call instructions themselves, and revector to jackets. It gets more complicated when the host/target OS's are significantly dissimilar - you have to do stuff like WINE.... But a fork() on Solaris is substatively similar to fork() on Linux. Rick (been there, done that) |
|
From: John R. <jr...@bi...> - 2013-04-17 21:57:54
|
> Let us assume that system calls aren't a problem, as we can work around > those here thanks to QNX's micro kernel nature by simply pushing syscalls > over an IP link. What would be the next major show stopper, purely from > within valgrind itself? The target (ARM) shared libraries. Logically there are two separate name spaces for "the" filesystem (ARM target vs. x86 host) but physically there is only one (the x86 host). Of course you can try LD_LIBRARY_PATH, etc., but probably that's only the beginning. -- |
|
From: Tom H. <to...@co...> - 2013-04-17 20:29:42
|
On 17/04/13 21:22, Niall Douglas wrote: > Let us assume that system calls aren't a problem, as we can work around > those here thanks to QNX's micro kernel nature by simply pushing syscalls > over an IP link. What would be the next major show stopper, purely from > within valgrind itself? I really have no idea - as far as I know nobody has ever tried it and we have always know that the system calls were a massive hurdle so haven't really thought any more about it. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Niall D. <ndo...@bl...> - 2013-04-17 20:22:45
|
> > I was wondering what would be the issues, if any, of valgrinding a > > foreign architecture process e.g. building an x86 build of ARM > > valgrind and then using that to valgrind an ARM executable on an x86 > > machine? Obviously it could load a local set of foreign architecture > > shared libraries etc. easily enough. I can see perhaps though that the > > syscall kernel interface might vary, and that could be a problem. > > > > Other than that though, what would stand in the way? Surely as it > > emulates the instruction set it ought to work right? > > This is not supported at all. > > Yes, in theory VEX might be able to cross translate the code (though I think there > might be problems even there) but the big stumbling block is that there is > absolutely no support for translating system calls from one architecture to > another. Thanks for the answer. Let us assume that system calls aren't a problem, as we can work around those here thanks to QNX's micro kernel nature by simply pushing syscalls over an IP link. What would be the next major show stopper, purely from within valgrind itself? Thanks, Niall |
|
From: Tom H. <to...@co...> - 2013-04-17 20:18:31
|
On 17/04/13 20:55, Niall Douglas wrote: > I was wondering what would be the issues, if any, of valgrinding a foreign > architecture process e.g. building an x86 build of ARM valgrind and then > using that to valgrind an ARM executable on an x86 machine? Obviously it > could load a local set of foreign architecture shared libraries etc. easily > enough. I can see perhaps though that the syscall kernel interface might > vary, and that could be a problem. > > Other than that though, what would stand in the way? Surely as it emulates > the instruction set it ought to work right? This is not supported at all. Yes, in theory VEX might be able to cross translate the code (though I think there might be problems even there) but the big stumbling block is that there is absolutely no support for translating system calls from one architecture to another. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Niall D. <ndo...@bl...> - 2013-04-17 19:55:34
|
Dear Valgrind Developers, I was wondering what would be the issues, if any, of valgrinding a foreign architecture process e.g. building an x86 build of ARM valgrind and then using that to valgrind an ARM executable on an x86 machine? Obviously it could load a local set of foreign architecture shared libraries etc. easily enough. I can see perhaps though that the syscall kernel interface might vary, and that could be a problem. Other than that though, what would stand in the way? Surely as it emulates the instruction set it ought to work right? Thanks, Niall |
|
From: Niall D. <ndo...@bl...> - 2013-04-17 19:46:20
|
I thought the list might appreciate seeing the improved callgrind in action: https://plus.google.com/photos/103330209479934785641/albums/5867891891426048 561 The patch is submitted for release. It should clear within six weeks. Next step is a callgrind output to XML converter. Any complaints if I write the callgrind output parser in Boost.Spirit Josef? I wouldn't want it to be a maintenance headache. Niall > -----Original Message----- > From: Niall Douglas > Sent: 11 April 2013 16:34 > To: val...@li... > Subject: Re: [Valgrind-developers] Details about forthcoming > cachegrind/callgrind patch adding hardware costs > > > Am 11.04.2013 17:10, schrieb Niall Douglas: > > >>> desc: I1 cache: 32768 B, 64 B, 8-way associative, 153 picosec > > > > > Estimated cost times for a cache line, so a D1 cache access costs 153 > > > picosec, whereas a LL cache access costs 1112 picosec. > > > > Ok. "0.153 ns hit latency" may be more descriptive. > > Is 153 picosec hit latency okay? I try to avoid floating point printing. I > think valgrind's sprint now supports %f, but not %e. I had to write my own > %e formatter which is a challenge without a C math library. > > Also, the read_picosecond_timer() suggests picosec. As that's the minimum > resolution offered by POSIX, that seems the right unit. > > > But these numbers are so small... I assume there is prefetching going on, > and > > you are actually measuring the maximal bandwidth from core to a cache > level. I > > would assume that an unpredictable LL access has a latency more in the > range > > of 15-30 cycles (and not 1ns). > > As I mentioned, I do permute the cache line fetches by reversing the last > eight bits of the cache line indexes to make them appear random-ish. I > *really* wish I could just point you at the code, but it's still tied up in > bureaucracy. > > > I get the impression that we always should do prefetch simulation, and add > an > > event "predicted LL miss" to be not totally off with the some time > estimation. > > It's certainly coming to that with Sandy Bridge and later on Intel. We're > not there yet on ARM. > > > So this somehow is the latency of an add instruction, using registers. I > suppose > > with a multiplication it would be slower, and with a divison even more > so... I.e. > > that does not really match with any definition of "max cost" for me ;-) > > There is a bit of method in the madness there. If I have read it correctly, > according to > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.5816&rep=rep1& > ty > pe=pdf roughly speaking, as an average case, most general purpose code has > an ILP of around 1.0, so if you can calculate the clock speed, you more or > less get average instruction cost. > > So this asks the question, how do you portably calculate the clock speed? > And by portably, I mean no assembler and no OS specific code (POSIX is > okay). It turns out this isn't easy. The best approach I could think of was > to calculate for the add instruction given that it is *probably* reasonably > likely to be the same as the clock speed on most contemporary CPUs [1]. > > Therefore when I use max instruction cost in my calculations, it's really a > proxy for average instruction cost based on a number of reasonable > assumptions. > > [1]: The Qualcomm Krait is not one of these CPUs. It incurs a stochastic > non-linear latency on arithmetic instructions. In the end, what can you do > in this situation. > > > > You'll note the max instruction cost is ~300 picosec while the L1 > > > cache line is ~150 picosec for 64 bytes. I would assume Intel > > > deliberately chose that to ensure that a single arithmetic instruction > > > adding across cache lines can run at single cycle speed. > > > > Ah, so these results are from an Intel processor? > > 101 ps means 1 cycle with 10GHz. I wondered which ARM processor you were > > using to get these impressive figures. So it's more like 3.3GHz and 3 add > > instructions throughput per cycle. > > Correct. Sorry if I confused you. As I must prepare a patch for you guys, > and one which must pass Legal, I ported the work from internal valgrind to > Linux valgrind. Which runs inside a VM on my Intel work PC. Hence the > figures are for that machine. Main memory cost is particularly incorrect > inside a VM. > > I'll backport the patch to internal valgrind once internal peer review > approves it. There's absolutely no reason it shouldn't work seamlessly on > ARM though. > > BTW, this is the custom event I added: > > desc: I1 cache: 32768 B, 64 B, 8-way associative, 157 picosec > desc: D1 cache: 32768 B, 64 B, 8-way associative, 157 picosec > desc: LL cache: 6291456 B, 64 B, 12-way associative, 1120 picosec > desc: main memory: 1362 picosec > desc: max instruct cost: 316 picosec > desc: min instruct cost: 107 picosec > > event: EPpsec = 316 Ir + 1120 I1mr + 1120 D1mr + 1120 D1mw + 1362 ILmr + > 1362 DLmr + 1362 DLmw > event: EPpsec : Estimated Possible Picosecs > > I think that's a reasonable calculation, more or less. > > I'll change "picosec" => "picosec hit latency" shortly. > > Niall |
|
From: <sv...@va...> - 2013-04-17 19:07:51
|
mjw 2013-04-17 20:11:05 +0100 (Wed, 17 Apr 2013)
New Revision: 13371
Log:
Fix -Ttext-segment configure check.
Explicitly test together with -static -nodefaultlibs -nostartfiles to mimic
what the tools linking script does. At least on s390 the test might fail for
a non-static AC_LINK, while it does work when using those other flags too.
Modified files:
trunk/configure.in
Modified: trunk/configure.in (+2 -2)
===================================================================
--- trunk/configure.in 2013-04-17 16:23:22 +01:00 (rev 13370)
+++ trunk/configure.in 2013-04-17 20:11:05 +01:00 (rev 13371)
@@ -1718,10 +1718,10 @@
AC_MSG_CHECKING([if the linker accepts -Wl,-Ttext-segment])
safe_CFLAGS=$CFLAGS
-CFLAGS="-Wl,-Ttext-segment=$valt_load_address_pri_norml"
+CFLAGS="-static -nodefaultlibs -nostartfiles -Wl,-Ttext-segment=$valt_load_address_pri_norml"
AC_LINK_IFELSE(
-[AC_LANG_PROGRAM([ ], [return 0;])],
+[AC_LANG_SOURCE([int _start () { return 0; }])],
[
linker_using_t_text="no"
AC_SUBST([FLAG_T_TEXT], ["-Ttext-segment"])
|
|
From: <sv...@va...> - 2013-04-17 15:20:09
|
mjw 2013-04-17 16:23:22 +0100 (Wed, 17 Apr 2013)
New Revision: 13370
Log:
strchr.vgtest mc_replace_strmem.c [r]index and [__GI_]str[r]chr are the same.
Add memcheck/tests/filter_strchr to make it so for the testcase.
Added files:
trunk/memcheck/tests/filter_strchr
Modified files:
trunk/memcheck/tests/Makefile.am
trunk/memcheck/tests/strchr.vgtest
Modified: trunk/memcheck/tests/strchr.vgtest (+1 -0)
===================================================================
--- trunk/memcheck/tests/strchr.vgtest 2013-04-17 14:48:29 +01:00 (rev 13369)
+++ trunk/memcheck/tests/strchr.vgtest 2013-04-17 16:23:22 +01:00 (rev 13370)
@@ -1,3 +1,4 @@
prog: strchr
vgopts: -q
+stderr_filter: filter_strchr
stderr_filter_args: strchr.c
Property changed: trunk/memcheck/tests/filter_strchr (+0 -0)
___________________________________________________________________
Name: svn:executable
+ *
Added: trunk/memcheck/tests/filter_strchr (+8 -0)
===================================================================
--- trunk/memcheck/tests/filter_strchr 2013-04-17 14:48:29 +01:00 (rev 13369)
+++ trunk/memcheck/tests/filter_strchr 2013-04-17 16:23:22 +01:00 (rev 13370)
@@ -0,0 +1,8 @@
+#! /bin/sh
+
+# mc_replace_strmem.c [r]index and [__GI_]str[r]chr are the same.
+./filter_stderr "$@" |
+sed -e "s/: __GI_strchr (mc_replace_strmem.c:/: strchr (mc_replace_strmem.c:/" |
+sed -e "s/: strchr (mc_replace_strmem.c:/: index (mc_replace_strmem.c:/" |
+sed -e "s/: __GI_strrchr (mc_replace_strmem.c:/: strrchr (mc_replace_strmem.c:/" |
+sed -e "s/: strrchr (mc_replace_strmem.c:/: rindex (mc_replace_strmem.c:/"
Modified: trunk/memcheck/tests/Makefile.am (+1 -0)
===================================================================
--- trunk/memcheck/tests/Makefile.am 2013-04-17 14:48:29 +01:00 (rev 13369)
+++ trunk/memcheck/tests/Makefile.am 2013-04-17 16:23:22 +01:00 (rev 13370)
@@ -43,6 +43,7 @@
filter_allocs \
filter_leak_cases_possible \
filter_stderr filter_xml \
+ filter_strchr \
filter_varinfo3 \
filter_memcheck \
filter_memcpy
|
|
From: <sv...@va...> - 2013-04-17 13:45:16
|
mjw 2013-04-17 14:48:29 +0100 (Wed, 17 Apr 2013)
New Revision: 13369
Log:
Simplify read_unitinfo_dwarf2. Only try to read the first DIE.
Bug #305513. We should only read the first DIE of a compilation unit.
Each compilation unit header is followed by a single DW_TAG_compile_unit
(or DW_TAG_partial_unit, but those aren't important here) and its children.
There is no reason to read any of the children at this point. If the first
DIE isn't a DW_TAG_compile_unit we are done, none of the child DIEs will
provide any useful information.
Modified files:
trunk/coregrind/m_debuginfo/readdwarf.c
Modified: trunk/coregrind/m_debuginfo/readdwarf.c (+17 -30)
===================================================================
--- trunk/coregrind/m_debuginfo/readdwarf.c 2013-04-17 11:08:04 +01:00 (rev 13368)
+++ trunk/coregrind/m_debuginfo/readdwarf.c 2013-04-17 14:48:29 +01:00 (rev 13369)
@@ -965,12 +965,14 @@
}
/* Read general information for a particular compile unit block in
- * the .debug_info section.
+ * the .debug_info section. In particular read the name, compdir and
+ * stmt_list needed to parse the line number information.
*
* Input: - unitblock is the start of a compilation
* unit block in .debuginfo section
* - debugabbrev is start of .debug_abbrev section
* - debugstr is start of .debug_str section
+ * - debugstr_alt_img is start of .debug_str section in alt debug file
*
* Output: Fill members of ui pertaining to the compilation unit:
* - ui->name is the name of the compilation unit
@@ -990,7 +992,6 @@
{
UInt acode, abcode;
ULong atoffs, blklen;
- Int level;
UShort ver;
UChar addr_size;
@@ -1021,40 +1022,33 @@
end_img = unitblock_img
+ blklen + (ui->dw64 ? 12 : 4); /* End of this block */
- level = 0; /* Level in the abbrev tree */
abbrev_img = debugabbrev_img
+ atoffs; /* Abbreviation data for this block */
- /* Read the compilation unit entries */
- while ( p < end_img ) {
- Bool has_child;
+ /* Read the compilation unit entry - this is always the first DIE.
+ * See DWARF4 para 7.5. */
+ if ( p < end_img ) {
UInt tag;
acode = read_leb128U( &p ); /* abbreviation code */
- if ( acode == 0 ) {
- /* NULL entry used for padding - or last child for a sequence
- - see para 7.5.3 */
- level--;
- continue;
- }
/* Read abbreviation header */
abcode = read_leb128U( &abbrev_img ); /* abbreviation code */
if ( acode != abcode ) {
- /* We are in in children list, and must rewind to a
- * previously declared abbrev code. This code works but is
- * not triggered since we shortcut the parsing once we have
- * read the compile_unit block. This should only occur when
- * level > 0 */
+ /* This isn't illegal, but somewhat unlikely. Normally the
+ * first abbrev describes the first DIE, the compile_unit.
+ * But maybe this abbrevation data is shared with another
+ * or it is a NULL entry used for padding. See para 7.5.3. */
abbrev_img = lookup_abbrev( debugabbrev_img + atoffs, acode );
}
tag = read_leb128U( &abbrev_img );
- has_child = *(abbrev_img++) == 1; /* DW_CHILDREN_yes */
- if ( has_child )
- level++;
+ if ( tag != 0x0011 /*TAG_compile_unit*/ )
+ return; /* Not a compile unit (might be partial) or broken DWARF. */
+ abbrev_img++; /* DW_CHILDREN_yes or DW_CHILDREN_no */
+
/* And loop on entries */
for ( ; ; ) {
/* Read entry definition */
@@ -1151,16 +1145,9 @@
else if ( name == 0x10 ) ui->stmt_list = cval; /* DW_AT_stmt_list */
}
}
- /* Shortcut the parsing once we have read the compile_unit block
- * That's enough info for us, and we are not gdb ! */
- if ( tag == 0x0011 /*TAG_compile_unit*/ )
- break;
- } /* Loop on each sub block */
-
- /* This test would be valid if we were not shortcutting the parsing
- if (level != 0)
- VG_(printf)( "#### Exiting debuginfo block at level %d !!!\n", level );
- */
+ } /* Just read the first DIE, if that wasn't the compile_unit then
+ * this might have been a partial unit or broken DWARF info.
+ * That's enough info for us, and we are not gdb ! */
}
|
|
From: <sv...@va...> - 2013-04-17 11:18:41
|
sewardj 2013-04-17 12:21:58 +0100 (Wed, 17 Apr 2013)
New Revision: 2707
Log:
Remove some unused ifdeffery that allowed disabling QC flag updating
for Neon.
Modified files:
trunk/priv/guest_arm_toIR.c
Modified: trunk/priv/guest_arm_toIR.c (+0 -68)
===================================================================
--- trunk/priv/guest_arm_toIR.c 2013-04-11 14:57:43 +01:00 (rev 2706)
+++ trunk/priv/guest_arm_toIR.c 2013-04-17 12:21:58 +01:00 (rev 2707)
@@ -1267,7 +1267,6 @@
binop(Iop_GetElem32x2, resR, mkU8(1)) );
}
-#if 1
call1 = mkIRExprCCall(
Ity_I32,
0/*regparm*/,
@@ -1287,39 +1286,6 @@
} else {
res = call1;
}
-#else
- if (Q) {
- res = unop(Iop_1Uto32,
- binop(Iop_CmpNE32,
- binop(Iop_Or32,
- binop(Iop_Or32,
- binop(Iop_Xor32,
- args1[0],
- args1[2]),
- binop(Iop_Xor32,
- args1[1],
- args1[3])),
- binop(Iop_Or32,
- binop(Iop_Xor32,
- args2[0],
- args2[2]),
- binop(Iop_Xor32,
- args2[1],
- args2[3]))),
- mkU32(0)));
- } else {
- res = unop(Iop_1Uto32,
- binop(Iop_CmpNE32,
- binop(Iop_Or32,
- binop(Iop_Xor32,
- args1[0],
- args1[2]),
- binop(Iop_Xor32,
- args1[1],
- args1[3])),
- mkU32(0)));
- }
-#endif
return res;
}
@@ -3201,10 +3167,8 @@
tmp = newTemp(Ity_I64);
}
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(op2, mkexpr(arg_n), mkexpr(arg_m)));
setFlag_QC(mkexpr(res), mkexpr(tmp), Q, condT);
-#endif
DIP("vqadd.%c%d %c%d, %c%d, %c%d\n",
U ? 'u' : 's',
8 << size, reg_t, dreg, reg_t, nreg, reg_t, mreg);
@@ -3613,10 +3577,8 @@
else
tmp = newTemp(Ity_I64);
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(op2, mkexpr(arg_n), mkexpr(arg_m)));
setFlag_QC(mkexpr(res), mkexpr(tmp), Q, condT);
-#endif
DIP("vqsub.%c%u %c%u, %c%u, %c%u\n",
U ? 'u' : 's', 8 << size,
Q ? 'q' : 'd', dreg, Q ? 'q' : 'd', nreg, Q ? 'q' : 'd',
@@ -3801,7 +3763,6 @@
mask = newTemp(Ity_I64);
}
assign(res, binop(op, mkexpr(arg_m), mkexpr(arg_n)));
-#ifndef DISABLE_QC_FLAG
/* Only least significant byte from second argument is used.
Copy this byte to the whole vector element. */
assign(shval, binop(op_shrn,
@@ -3845,7 +3806,6 @@
binop(Q ? Iop_AndV128 : Iop_And64,
mkexpr(arg_m), mkexpr(mask)),
Q, condT);
-#endif
DIP("vqshl.%c%u %c%u, %c%u, %c%u\n",
U ? 'u' : 's', 8 << size,
Q ? 'q' : 'd', dreg, Q ? 'q' : 'd', mreg, Q ? 'q' : 'd',
@@ -4116,7 +4076,6 @@
assign(res, binop(op_add,
binop(op, mkexpr(arg_m), mkexpr(arg_n)),
mkexpr(round)));
-#ifndef DISABLE_QC_FLAG
/* If shift is greater or equal to the element size and element is
non-zero, then QC flag should be set. */
esize = (8 << size) - 1;
@@ -4144,7 +4103,6 @@
binop(Q ? Iop_AndV128 : Iop_And64,
mkexpr(arg_m), mkexpr(mask)),
Q, condT);
-#endif
DIP("vqrshl.%c%u %c%u, %c%u, %c%u\n",
U ? 'u' : 's', 8 << size,
Q ? 'q' : 'd', dreg, Q ? 'q' : 'd', mreg, Q ? 'q' : 'd',
@@ -4547,7 +4505,6 @@
vassert(0);
}
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Q ? Iop_AndV128 : Iop_And64,
binop(op2, mkexpr(arg_n),
Q ? mkU128(imm) : mkU64(imm)),
@@ -4555,7 +4512,6 @@
Q ? mkU128(imm) : mkU64(imm))),
Q ? mkU128(0) : mkU64(0),
Q, condT);
-#endif
DIP("vqdmulh.s%u %c%u, %c%u, %c%u\n",
8 << size, Q ? 'q' : 'd',
dreg, Q ? 'q' : 'd', nreg, Q ? 'q' : 'd', mreg);
@@ -4583,7 +4539,6 @@
vassert(0);
}
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Q ? Iop_AndV128 : Iop_And64,
binop(op2, mkexpr(arg_n),
Q ? mkU128(imm) : mkU64(imm)),
@@ -4591,7 +4546,6 @@
Q ? mkU128(imm) : mkU64(imm))),
Q ? mkU128(0) : mkU64(0),
Q, condT);
-#endif
DIP("vqrdmulh.s%u %c%u, %c%u, %c%u\n",
8 << size, Q ? 'q' : 'd',
dreg, Q ? 'q' : 'd', nreg, Q ? 'q' : 'd', mreg);
@@ -5170,7 +5124,6 @@
res = newTemp(Ity_V128);
tmp = newTemp(Ity_V128);
assign(res, binop(op, getDRegI64(nreg), getDRegI64(mreg)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(op2, getQReg(dreg), mkexpr(res)));
setFlag_QC(mkexpr(tmp), binop(add, getQReg(dreg), mkexpr(res)),
True, condT);
@@ -5179,7 +5132,6 @@
binop(cmp, getDRegI64(mreg), mkU64(imm))),
mkU64(0),
False, condT);
-#endif
putQReg(dreg, binop(add, getQReg(dreg), mkexpr(res)), condT);
DIP("vqdml%cl.s%u q%u, d%u, d%u\n", P ? 's' : 'a', 8 << size, dreg,
nreg, mreg);
@@ -5241,13 +5193,11 @@
}
putQReg(dreg, binop(op, getDRegI64(nreg), getDRegI64(mreg)),
condT);
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Iop_And64,
binop(op2, getDRegI64(nreg), mkU64(imm)),
binop(op2, getDRegI64(mreg), mkU64(imm))),
mkU64(0),
False, condT);
-#endif
DIP("vqdmull.s%u q%u, d%u, d%u\n", 8 << size, dreg, nreg, mreg);
return True;
default:
@@ -5496,7 +5446,6 @@
res = newTemp(Ity_V128);
tmp = newTemp(Ity_V128);
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(op2, getQReg(dreg), mkexpr(res)));
setFlag_QC(binop(Iop_And64,
binop(cmp, mkexpr(arg_n), mkU64(imm)),
@@ -5505,7 +5454,6 @@
False, condT);
setFlag_QC(mkexpr(tmp), binop(add, getQReg(dreg), mkexpr(res)),
True, condT);
-#endif
putQReg(dreg, binop(add, getQReg(dreg), mkexpr(res)), condT);
DIP("vqdml%cl.s%u q%u, d%u, d%u[%u]\n", P ? 's' : 'a', 8 << size,
dreg, nreg, mreg, index);
@@ -5706,13 +5654,11 @@
}
putQReg(dreg, binop(op, mkexpr(arg_n), mkexpr(arg_m)),
condT);
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Iop_And64,
binop(op2, mkexpr(arg_n), mkU64(imm)),
binop(op2, mkexpr(arg_m), mkU64(imm))),
mkU64(0),
False, condT);
-#endif
DIP("vqdmull.s%u q%u, d%u, d%u[%u]\n", 8 << size, dreg, nreg, mreg,
index);
return True;
@@ -5799,7 +5745,6 @@
vassert(0);
}
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Q ? Iop_AndV128 : Iop_And64,
binop(op2, mkexpr(arg_n),
Q ? mkU128(imm) : mkU64(imm)),
@@ -5807,7 +5752,6 @@
Q ? mkU128(imm) : mkU64(imm))),
Q ? mkU128(0) : mkU64(0),
Q, condT);
-#endif
if (Q)
putQReg(dreg, mkexpr(res), condT);
else
@@ -5899,7 +5843,6 @@
vassert(0);
}
assign(res, binop(op, mkexpr(arg_n), mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
setFlag_QC(binop(Q ? Iop_AndV128 : Iop_And64,
binop(op2, mkexpr(arg_n),
Q ? mkU128(imm) : mkU64(imm)),
@@ -5907,7 +5850,6 @@
Q ? mkU128(imm) : mkU64(imm))),
Q ? mkU128(0) : mkU64(0),
Q, condT);
-#endif
if (Q)
putQReg(dreg, mkexpr(res), condT);
else
@@ -6370,10 +6312,8 @@
assign(reg_m, getDRegI64(mreg));
}
assign(res, binop(op, mkexpr(reg_m), mkU8(shift_imm)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(op_rev, mkexpr(res), mkU8(shift_imm)));
setFlag_QC(mkexpr(tmp), mkexpr(reg_m), Q, condT);
-#endif
if (Q)
putQReg(dreg, mkexpr(res), condT);
else
@@ -6563,10 +6503,8 @@
/* VQSHRN, VQSHRUN */
assign(res, binop(op, mkexpr(reg_m), mkU8(shift_imm)));
}
-#ifndef DISABLE_QC_FLAG
setFlag_QC(unop(cvt2, unop(cvt, mkexpr(res))), mkexpr(res),
True, condT);
-#endif
putDRegI64(dreg, unop(cvt, mkexpr(res)), condT);
return True;
case 10:
@@ -6919,7 +6857,6 @@
unop(Q ? Iop_NotV128 : Iop_Not64,
mkexpr(mask)),
neg)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, binop(Q ? Iop_OrV128 : Iop_Or64,
binop(Q ? Iop_AndV128 : Iop_And64,
mkexpr(mask),
@@ -6929,7 +6866,6 @@
mkexpr(mask)),
neg2)));
setFlag_QC(mkexpr(res), mkexpr(tmp), Q, condT);
-#endif
DIP("vqabs.s%u %c%u, %c%u\n", 8 << size, Q ? 'q' : 'd', dreg,
Q ? 'q' : 'd', mreg);
break;
@@ -6962,10 +6898,8 @@
vassert(0);
}
assign(res, binop(op, zero, mkexpr(arg_m)));
-#ifndef DISABLE_QC_FLAG
setFlag_QC(mkexpr(res), binop(op2, zero, mkexpr(arg_m)),
Q, condT);
-#endif
DIP("vqneg.s%u %c%u, %c%u\n", 8 << size, Q ? 'q' : 'd', dreg,
Q ? 'q' : 'd', mreg);
break;
@@ -7463,10 +7397,8 @@
res = newTemp(Ity_I64);
tmp = newTemp(Ity_I64);
assign(res, unop(op, getQReg(mreg)));
-#ifndef DISABLE_QC_FLAG
assign(tmp, unop(op2, getQReg(mreg)));
setFlag_QC(mkexpr(res), mkexpr(tmp), False, condT);
-#endif
putDRegI64(dreg, mkexpr(res), condT);
return True;
} else if (B == 12) {
|
|
From: <sv...@va...> - 2013-04-17 10:04:48
|
tom 2013-04-17 11:08:04 +0100 (Wed, 17 Apr 2013)
New Revision: 13368
Log:
Pay attention to PT_GNU_STACK when deciding what permissions to
use for the client stack.
Modified files:
trunk/coregrind/m_initimg/initimg-linux.c
trunk/coregrind/m_ume/elf.c
trunk/coregrind/pub_core_ume.h
Modified: trunk/coregrind/m_initimg/initimg-linux.c (+1 -1)
===================================================================
--- trunk/coregrind/m_initimg/initimg-linux.c 2013-04-11 18:55:39 +01:00 (rev 13367)
+++ trunk/coregrind/m_initimg/initimg-linux.c 2013-04-17 11:08:04 +01:00 (rev 13368)
@@ -557,7 +557,7 @@
res = VG_(am_mmap_anon_fixed_client)(
anon_start -inner_HACK,
anon_size +inner_HACK,
- VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC
+ info->stack_prot
);
}
if ((!ok) || sr_isError(res)) {
Modified: trunk/coregrind/m_ume/elf.c (+7 -0)
===================================================================
--- trunk/coregrind/m_ume/elf.c 2013-04-11 18:55:39 +01:00 (rev 13367)
+++ trunk/coregrind/m_ume/elf.c 2013-04-17 11:08:04 +01:00 (rev 13368)
@@ -354,6 +354,7 @@
info->phnum = e->e.e_phnum;
info->entry = e->e.e_entry + ebase;
info->phdr = 0;
+ info->stack_prot = VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC;
for (i = 0; i < e->e.e_phnum; i++) {
ESZ(Phdr) *ph = &e->p[i];
@@ -416,6 +417,12 @@
}
break;
+ case PT_GNU_STACK:
+ if ((ph->p_flags & PF_X) == 0) info->stack_prot &= ~VKI_PROT_EXEC;
+ if ((ph->p_flags & PF_W) == 0) info->stack_prot &= ~VKI_PROT_WRITE;
+ if ((ph->p_flags & PF_R) == 0) info->stack_prot &= ~VKI_PROT_READ;
+ break;
+
default:
// do nothing
break;
Modified: trunk/coregrind/pub_core_ume.h (+1 -0)
===================================================================
--- trunk/coregrind/pub_core_ume.h 2013-04-11 18:55:39 +01:00 (rev 13367)
+++ trunk/coregrind/pub_core_ume.h 2013-04-17 11:08:04 +01:00 (rev 13368)
@@ -52,6 +52,7 @@
#if !defined(VGO_darwin)
Addr phdr; // OUT: address phdr was mapped at
Int phnum; // OUT: number of phdrs
+ UInt stack_prot; // OUT: stack permissions
Addr interp_base; // OUT: where interpreter (ld.so) was mapped
#else
Addr stack_start; // OUT: address of start of stack segment (hot)
|