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
|
2
(1) |
3
(25) |
4
(4) |
5
|
6
(3) |
7
|
|
8
(2) |
9
(3) |
10
|
11
|
12
|
13
(2) |
14
|
|
15
(1) |
16
(3) |
17
(1) |
18
(7) |
19
(4) |
20
(1) |
21
(2) |
|
22
(1) |
23
(3) |
24
(8) |
25
(1) |
26
(6) |
27
(2) |
28
|
|
29
(3) |
30
|
|
|
|
|
|
|
From: Petar J. <mip...@gm...> - 2015-11-26 23:40:12
|
Hi Leonard, Thank you again for the work on Valgrind. I have previously put some comments on the bug tracker, and I am going to repeat it here. > This version sort-of works-for-me. Unless some specific issues are reported the patches will probably remain as they are. > I would appreciate any advice on how to get these into upstream. I know that adding another ABI expands the combinations that need to be tested. My major concern here is that "sort-of works-for-me". As you understand, adding new ABI means somebody needs to test it on a regular basis. Somebody also needs to use it, and while there are some users of n32 systems, it is still the least used MIPS ABI today, I believe. This does not mean it should be neglected though. But if there are people interested in having it in and maintaining it (or at least reporting issues when they pop up, so the code does not become bit rotten), then we should consider it, but it needs to be in very good shape before it lands. > I use this on cavium hardware but I tested an earlier version inside a debian mips64 qemu vm and it works there as well. I also ran regressions at some point (log attached in bug tracker) and the results were sort-of decent. I have taken a look at the log, and it seems you have not run the full 'make regtest'. What are the results if you run that? For comparison, on Cavium hardware (presumably similar to the one you have) MIPS64 N64 port of Valgrind has less than a dozen failures [1] in regtest. Can you make sure your patches are close to that number for n32? At the same time, please run other MIPS variants and make sure you are not introducing issues/regressions elsewhere. Thanks. Regards, Petar [1] http://www.rt-rk.com/mips-buildbot/builders/EP6300C/builds/746/steps/shell/logs/stdio On Thu, Nov 26, 2015 at 11:13 PM, Crestez Dan Leonard <cdl...@gm...> wrote: > Hello, > > Some time ago I posted some patches adding support for the N32 ABI on mips. > * This is tracked as https://bugs.kde.org/show_bug.cgi?id=345763 > * Link to previous thread: > http://valgrind.10908.n7.nabble.com/RFC-MIPS-N32-abi-support-td54279.html > > I rebased my patches on top of valgrind release 3.11.0. There are no > important changes from the last patches I posted but these should apply > cleanly on top of a released tarball rather than some random SVN head. If > you are interested in N32 support it should be relatively easy to apply the > patches (one to valgrind and one to VEX) and check if it works on your > target system. > > My early versions added an entirely new mips64n32 version similar to > ppc64be and such. Based on comments in the issue tracker I added an VGABI_* > define for mips which greatly reduces the amount of ifdefing required. The > patches are still rather large and messy. > > This version sort-of works-for-me. Unless some specific issues are > reported the patches will probably remain as they are. There is currently > only a very minor conflict if you attempt to apply the patches to trunk. > > I would appreciate any advice on how to get these into upstream. I know > that adding another ABI expands the combinations that need to be tested. I > use this on cavium hardware but I tested an earlier version inside a debian > mips64 qemu vm and it works there as well. I also ran regressions at some > point (log attached in bug tracker) and the results were sort-of decent. > > I used git to manage my patches. You can find detailed step-by-step diffs > on github: > * https://github.com/cdleonard/valgrind/commits/mini-mips64n32-3.11.0 > * https://github.com/cdleonard/valgrind-vex/commits/mini-mips64n32-3.11.0 > > Those repos also contain some octeon-specific fixes which are not required > for n32 support. > > Regards, > Leonard > > > ------------------------------------------------------------------------------ > Go from Idea to Many App Stores Faster with Intel(R) XDK > Give your users amazing mobile app experiences with Intel(R) XDK. > Use one codebase in this all-in-one HTML5 development environment. > Design, debug & build mobile apps & 2D/3D high-impact games for multiple > OSs. > http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Crestez D. L. <cdl...@gm...> - 2015-11-26 22:13:25
|
Hello, Some time ago I posted some patches adding support for the N32 ABI on mips. * This is tracked as https://bugs.kde.org/show_bug.cgi?id=345763 * Link to previous thread: http://valgrind.10908.n7.nabble.com/RFC-MIPS-N32-abi-support-td54279.html I rebased my patches on top of valgrind release 3.11.0. There are no important changes from the last patches I posted but these should apply cleanly on top of a released tarball rather than some random SVN head. If you are interested in N32 support it should be relatively easy to apply the patches (one to valgrind and one to VEX) and check if it works on your target system. My early versions added an entirely new mips64n32 version similar to ppc64be and such. Based on comments in the issue tracker I added an VGABI_* define for mips which greatly reduces the amount of ifdefing required. The patches are still rather large and messy. This version sort-of works-for-me. Unless some specific issues are reported the patches will probably remain as they are. There is currently only a very minor conflict if you attempt to apply the patches to trunk. I would appreciate any advice on how to get these into upstream. I know that adding another ABI expands the combinations that need to be tested. I use this on cavium hardware but I tested an earlier version inside a debian mips64 qemu vm and it works there as well. I also ran regressions at some point (log attached in bug tracker) and the results were sort-of decent. I used git to manage my patches. You can find detailed step-by-step diffs on github: * https://github.com/cdleonard/valgrind/commits/mini-mips64n32-3.11.0 * https://github.com/cdleonard/valgrind-vex/commits/mini-mips64n32-3.11.0 Those repos also contain some octeon-specific fixes which are not required for n32 support. Regards, Leonard |
|
From: Mark W. <mj...@re...> - 2015-11-26 19:36:44
|
On Thu, Nov 26, 2015 at 06:52:42PM +0100, Ivo Raisr wrote: > For example test case memcheck/tests/test-plo-no previously showed: > > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > at 0x7FFB04ED2: memalign (vg_replace_malloc.c:450) > by 0x401304: memalign16 (malloc.h:21) > by 0x4014E2: main (test-plo.c:49) > > While now it shows only: > Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd > at 0x7FFB04ED2: memalign (vgpreload_memcheck-amd64-solaris.so) > by 0x401304: memalign16 (malloc.h:21) > by 0x4014E2: main (test-plo.c:49) So, the addresses are exactly the same, but for the address in vgpreload_memcheck-amd64-solaris.so no source line can be found? I am not sure how a change in symbol redirection can cause that. Does --debug-dump=line give any hints/differences? Cheers, Mark |
|
From: <sv...@va...> - 2015-11-26 18:20:51
|
Author: petarj
Date: Thu Nov 26 18:20:44 2015
New Revision: 15739
Log:
mips: get isa level information from /proc/cpuinfo
Rewrite parts of VG_(parse_cpuinfo) (previously VG_(get_machine_model))
function to extract information on supported ISAs. These values are then
packed in hwcaps. This will help Valgrind better distinguish different MIPS
CPUs and raise illegal instructions when required.
Modified:
trunk/coregrind/m_machine.c
Modified: trunk/coregrind/m_machine.c
==============================================================================
--- trunk/coregrind/m_machine.c (original)
+++ trunk/coregrind/m_machine.c Thu Nov 26 18:20:44 2015
@@ -700,8 +700,12 @@
#if defined(VGA_mips32) || defined(VGA_mips64)
-/* Read /proc/cpuinfo and return the machine model. */
-static UInt VG_(get_machine_model)(void)
+/*
+ * Initialize hwcaps by parsing /proc/cpuinfo . Returns False if it can not
+ * determine what CPU it is (it searches only for the models that are or may be
+ * supported by Valgrind).
+ */
+static Bool VG_(parse_cpuinfo)(void)
{
const char *search_Broadcom_str = "cpu model\t\t: Broadcom";
const char *search_Cavium_str= "cpu model\t\t: Cavium";
@@ -713,11 +717,11 @@
Int n, fh;
SysRes fd;
SizeT num_bytes, file_buf_size;
- HChar *file_buf;
+ HChar *file_buf, *isa;
/* Slurp contents of /proc/cpuinfo into FILE_BUF */
fd = VG_(open)( "/proc/cpuinfo", 0, VKI_S_IRUSR );
- if ( sr_isError(fd) ) return -1;
+ if ( sr_isError(fd) ) return False;
fh = sr_Res(fd);
@@ -751,20 +755,66 @@
/* Parse file */
if (VG_(strstr)(file_buf, search_Broadcom_str) != NULL)
- return VEX_PRID_COMP_BROADCOM;
- if (VG_(strstr)(file_buf, search_Netlogic_str) != NULL)
- return VEX_PRID_COMP_NETLOGIC;
- if (VG_(strstr)(file_buf, search_Cavium_str) != NULL)
- return VEX_PRID_COMP_CAVIUM;
- if (VG_(strstr)(file_buf, search_MIPS_str) != NULL)
- return VEX_PRID_COMP_MIPS;
- if (VG_(strstr)(file_buf, search_Ingenic_str) != NULL)
- return VEX_PRID_COMP_INGENIC_E1;
- if (VG_(strstr)(file_buf, search_Loongson_str) != NULL)
- return (VEX_PRID_COMP_LEGACY | VEX_PRID_IMP_LOONGSON_64);
+ vai.hwcaps = VEX_PRID_COMP_BROADCOM;
+ else if (VG_(strstr)(file_buf, search_Netlogic_str) != NULL)
+ vai.hwcaps = VEX_PRID_COMP_NETLOGIC;
+ else if (VG_(strstr)(file_buf, search_Cavium_str) != NULL)
+ vai.hwcaps = VEX_PRID_COMP_CAVIUM;
+ else if (VG_(strstr)(file_buf, search_MIPS_str) != NULL)
+ vai.hwcaps = VEX_PRID_COMP_MIPS;
+ else if (VG_(strstr)(file_buf, search_Ingenic_str) != NULL)
+ vai.hwcaps = VEX_PRID_COMP_INGENIC_E1;
+ else if (VG_(strstr)(file_buf, search_Loongson_str) != NULL)
+ vai.hwcaps = (VEX_PRID_COMP_LEGACY | VEX_PRID_IMP_LOONGSON_64);
+ else {
+ /* Did not find string in the proc file. */
+ vai.hwcaps = 0;
+ VG_(free)(file_buf);
+ return False;
+ }
+
+ isa = VG_(strstr)(file_buf, "isa\t\t\t: ");
- /* Did not find string in the proc file. */
- return -1;
+ if (NULL != isa) {
+ if (VG_(strstr) (isa, "mips32r1") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M32R1;
+ if (VG_(strstr) (isa, "mips32r2") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M32R2;
+ if (VG_(strstr) (isa, "mips32r6") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M32R6;
+ if (VG_(strstr) (isa, "mips64r1") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M64R1;
+ if (VG_(strstr) (isa, "mips64r2") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M64R2;
+ if (VG_(strstr) (isa, "mips64r6") != NULL)
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M64R6;
+ } else {
+ /*
+ * Kernel does not provide information about supported ISAs.
+ * Populate the isa level flags based on the CPU model. That is our
+ * best guess.
+ */
+ switch VEX_MIPS_COMP_ID(vai.hwcaps) {
+ case VEX_PRID_COMP_CAVIUM:
+ case VEX_PRID_COMP_NETLOGIC:
+ vai.hwcaps |= (VEX_MIPS_CPU_ISA_M64R2 | VEX_MIPS_CPU_ISA_M64R1);
+ case VEX_PRID_COMP_INGENIC_E1:
+ case VEX_PRID_COMP_MIPS:
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M32R2;
+ case VEX_PRID_COMP_BROADCOM:
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M32R1;
+ break;
+ case VEX_PRID_COMP_LEGACY:
+ if ((VEX_MIPS_PROC_ID(vai.hwcaps) == VEX_PRID_IMP_LOONGSON_64))
+ vai.hwcaps |= VEX_MIPS_CPU_ISA_M64R2 | VEX_MIPS_CPU_ISA_M64R1 |
+ VEX_MIPS_CPU_ISA_M32R2 | VEX_MIPS_CPU_ISA_M32R1;
+ break;
+ default:
+ break;
+ }
+ }
+ VG_(free)(file_buf);
+ return True;
}
#endif
@@ -1590,12 +1640,9 @@
/* Define the position of F64 bit in FIR register. */
# define FP64 22
va = VexArchMIPS32;
- UInt model = VG_(get_machine_model)();
- if (model == -1)
+ if (!VG_(parse_cpuinfo)())
return False;
- vai.hwcaps = model;
-
# if defined(VKI_LITTLE_ENDIAN)
vai.endness = VexEndnessLE;
# elif defined(VKI_BIG_ENDIAN)
@@ -1633,7 +1680,7 @@
tmp_sigill_act.ksa_handler = handler_unsup_insn;
VG_(sigaction)(VKI_SIGILL, &tmp_sigill_act, NULL);
- if (model == VEX_PRID_COMP_MIPS) {
+ if (VEX_PRID_COMP_MIPS == VEX_MIPS_COMP_ID(vai.hwcaps)) {
/* DSPr2 instructions. */
have_DSPr2 = True;
if (VG_MINIMAL_SETJMP(env_unsup_insn)) {
@@ -1666,7 +1713,7 @@
: "=r" (FIR)
);
if (FIR & (1 << FP64)) {
- vai.hwcaps |= VEX_PRID_CPU_32FPR;
+ vai.hwcaps |= VEX_MIPS_CPU_32FPR;
}
VG_(convert_sigaction_fromK_to_toK)(&saved_sigill_act, &tmp_sigill_act);
@@ -1682,12 +1729,9 @@
#elif defined(VGA_mips64)
{
va = VexArchMIPS64;
- UInt model = VG_(get_machine_model)();
- if (model == -1)
+ if (!VG_(parse_cpuinfo)())
return False;
- vai.hwcaps = model;
-
# if defined(VKI_LITTLE_ENDIAN)
vai.endness = VexEndnessLE;
# elif defined(VKI_BIG_ENDIAN)
|
|
From: <sv...@va...> - 2015-11-26 18:17:42
|
Author: petarj
Date: Thu Nov 26 18:17:33 2015
New Revision: 3205
Log:
mips: add definitions of expected ISA levels
Add values of supported isa level for MIPS CPU models. This extended
information will be packed in 31:24 bits in hwcaps.
Modified:
trunk/priv/guest_mips_toIR.c
trunk/priv/host_mips_isel.c
trunk/priv/main_main.c
trunk/pub/libvex.h
Modified: trunk/priv/guest_mips_toIR.c
==============================================================================
--- trunk/priv/guest_mips_toIR.c (original)
+++ trunk/priv/guest_mips_toIR.c Thu Nov 26 18:17:33 2015
@@ -17290,7 +17290,7 @@
mode64 = guest_arch != VexArchMIPS32;
#if (__mips_fpr==64)
- fp_mode64 = ((VEX_MIPS_REV(archinfo->hwcaps) == VEX_PRID_CPU_32FPR)
+ fp_mode64 = (VEX_MIPS_HAS_32_64BIT_FPRS(archinfo->hwcaps)
|| guest_arch == VexArchMIPS64);
#endif
Modified: trunk/priv/host_mips_isel.c
==============================================================================
--- trunk/priv/host_mips_isel.c (original)
+++ trunk/priv/host_mips_isel.c Thu Nov 26 18:17:33 2015
@@ -4184,7 +4184,7 @@
mode64 = arch_host != VexArchMIPS32;
#if (__mips_fpr==64)
- fp_mode64 = ((VEX_MIPS_REV(hwcaps_host) == VEX_PRID_CPU_32FPR)
+ fp_mode64 = (VEX_MIPS_HAS_32_64BIT_FPRS(hwcaps_host)
|| arch_host == VexArchMIPS64);
#endif
Modified: trunk/priv/main_main.c
==============================================================================
--- trunk/priv/main_main.c (original)
+++ trunk/priv/main_main.c Thu Nov 26 18:17:33 2015
@@ -1738,7 +1738,12 @@
return "Loongson-baseline";
}
- return "mips64-baseline";
+ /* MIPS64 baseline. */
+ if (VEX_MIPS_COMP_ID(hwcaps) == VEX_PRID_COMP_MIPS) {
+ return "mips64-baseline";
+ }
+
+ return "Unsupported baseline";
}
static const HChar* show_hwcaps_tilegx ( UInt hwcaps )
Modified: trunk/pub/libvex.h
==============================================================================
--- trunk/pub/libvex.h (original)
+++ trunk/pub/libvex.h Thu Nov 26 18:17:33 2015
@@ -222,15 +222,32 @@
#define VEX_PRID_IMP_34K 0x9500
#define VEX_PRID_IMP_74K 0x9700
+/*
+ * Instead of Company Options values, bits 31:24 will be packed with
+ * additional information, such as isa level and presence of FPU unit
+ * with 32 64-bit registers.
+ */
+#define VEX_MIPS_CPU_ISA_M32R1 0x01000000
+#define VEX_MIPS_CPU_ISA_M32R2 0x02000000
+#define VEX_MIPS_CPU_ISA_M64R1 0x04000000
+#define VEX_MIPS_CPU_ISA_M64R2 0x08000000
+#define VEX_MIPS_CPU_ISA_M32R6 0x10000000
+#define VEX_MIPS_CPU_ISA_M64R6 0x20000000
/* CPU has FPU and 32 dbl. prec. FP registers */
-#define VEX_PRID_CPU_32FPR 0x00000040
-
+#define VEX_MIPS_CPU_32FPR 0x40000000
+/* Get MIPS Extended Information */
+#define VEX_MIPS_EX_INFO(x) ((x) & 0xFF000000)
/* Get MIPS Company ID from HWCAPS */
#define VEX_MIPS_COMP_ID(x) ((x) & 0x00FF0000)
/* Get MIPS Processor ID from HWCAPS */
#define VEX_MIPS_PROC_ID(x) ((x) & 0x0000FF00)
/* Get MIPS Revision from HWCAPS */
#define VEX_MIPS_REV(x) ((x) & 0x000000FF)
+/* Check if the processor has 32 64-bit FP registers */
+#define VEX_MIPS_HAS_32_64BIT_FPRS(x) (VEX_MIPS_EX_INFO(x) | VEX_MIPS_CPU_32FPR)
+/* Check if the processor supports MIPS32R2. */
+#define VEX_MIPS_CPU_HAS_MIPS32R2(x) (VEX_MIPS_EX_INFO(x) | \
+ VEX_MIPS_CPU_ISA_M32R2)
/* Check if the processor supports DSP ASE Rev 2. */
#define VEX_MIPS_PROC_DSP2(x) ((VEX_MIPS_COMP_ID(x) == VEX_PRID_COMP_MIPS) && \
(VEX_MIPS_PROC_ID(x) == VEX_PRID_IMP_74K))
|
|
From: Ivo R. <iv...@iv...> - 2015-11-26 17:52:50
|
Hi Mark,
Thank you again for having me helped understand the impact
of your changes from r15726 (intercept somalloc functions).
In addition to commit r15728, on Solaris, this change somehow impacted the
ability to print a correct stacktrace for intercepted memalign().
For example test case memcheck/tests/test-plo-no previously showed:
Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd
at 0x7FFB04ED2: memalign (vg_replace_malloc.c:450)
by 0x401304: memalign16 (malloc.h:21)
by 0x4014E2: main (test-plo.c:49)
While now it shows only:
Address 0x7ff706360 is 0 bytes inside a block of size 5 alloc'd
at 0x7FFB04ED2: memalign (vgpreload_memcheck-amd64-solaris.so)
by 0x401304: memalign16 (malloc.h:21)
by 0x4014E2: main (test-plo.c:49)
I investigated the differences on Solaris and Linux and see the following
dubious information in the verbose log (-v -v -v) when executing:
./vg-in-place --partial-loads-ok=no -v -v -v ./memcheck/tests/test-plo
==12622== Adding active redirection:
--12622-- new: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dead memalign
==12622== Ignoring duplicate redirection:
--12622-- old: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dead memalign
--12622-- new: 0x04ebcd80 (memalign ) R-> (1011.0) 0x04c2dcce memalign
This duplicate redirection for memalign was not present before r15726 and I
don't know where it is coming from. I think it is the reason why the
stacktrace cannot be described correctly because address of the new
redirection cannot be mapped to the debug info.
On Linux Ubuntu, test-plo is using the following libraries:
/lib/x86_64-linux-gnu/ld-2.21.so
vgpreload_core-amd64-linux.so
vgpreload_memcheck-amd64-linux.so
/lib/x86_64-linux-gnu/libc-2.21.so
And I see the following *memalign* symbols there:
$ nm /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.21.so | grep memalign
0000000000018af0 W __libc_memalign
$ nm /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.21.so | grep memalign
0000000000084d80 t __GI___libc_memalign
00000000000833f0 t _int_memalign
0000000000084d80 T __libc_memalign
0000000000084d80 W memalign
0000000000084d80 t __memalign
0000000000083610 t memalign_check
0000000000087f70 t memalignhook
00000000003c4bc0 V __memalign_hook
0000000000086030 t memalign_hook_ini
00000000003c6a68 b old_memalign_hook
0000000000087310 t __posix_memalign
0000000000087310 W posix_memalign
0000000000088d70 t tr_memalignhook
00000000003c6a88 b tr_old_memalign_hook
$ nm vgpreload_memcheck-amd64-linux.so | grep memalign
0000000000005cce T _vgr10110ZU_libcZdsoZa_memalign
0000000000005ead T _vgr10110ZU_VgSoSynsomalloc_memalign
0000000000005e21 T _vgr10160ZU_libcZdsoZa_posix_memalign
0000000000005e67 T _vgr10160ZU_VgSoSynsomalloc_posix_memalign
Surprisingly, for e.g. posix_memalign() I do not see any "duplicate
redirection".
What could be wrong and what could be possible hypothesis?
Kind regards,
I.
|