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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(39) |
2
(29) |
3
(27) |
4
(50) |
5
(37) |
|
6
(14) |
7
(28) |
8
(44) |
9
(38) |
10
(32) |
11
(49) |
12
(51) |
|
13
(37) |
14
(32) |
15
(70) |
16
(50) |
17
(43) |
18
(56) |
19
(23) |
|
20
(22) |
21
(36) |
22
(12) |
23
(22) |
24
(10) |
25
(13) |
26
(21) |
|
27
(17) |
28
(16) |
29
(33) |
30
(14) |
|
|
|
|
From: Josef W. <Jos...@gm...> - 2005-11-16 14:34:59
|
On Wednesday 16 November 2005 11:04, Tom Hughes wrote: > In which case my patch was a no-op for callgrind and shouldn't have > changed anything. Sorry. Yes, my previous mail was wrong. Address 21160 was shown as being in GOT of libpthread-2.3.5.so from the beginning. I looked at the wrong place. Relevant is this excerpt: > _dl_start(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0x1960] > 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528] > _dl_start(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0x19D4] > 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528] The line with 0x04027528 should be shown as 0x00027528 [GOT](...) [ld-2.3.5.so / 0x27528] I will try the ASpaceMgr functions. Josef |
|
From: <sv...@va...> - 2005-11-16 12:51:41
|
Author: sewardj
Date: 2005-11-16 12:51:34 +0000 (Wed, 16 Nov 2005)
New Revision: 5144
Log:
Enable sys_rt_sigsuspend. This is needed by LinuxThreads.
Modified:
trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
trunk/coregrind/vki_unistd-ppc32-linux.h
Modified: trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2005-11-16 10:23:15 U=
TC (rev 5143)
+++ trunk/coregrind/m_syswrap/syswrap-ppc32-linux.c 2005-11-16 12:51:34 U=
TC (rev 5144)
@@ -1651,8 +1651,8 @@
//.. LINXY(__NR_rt_sigpending, sys_rt_sigpending), // 175
LINXY(__NR_rt_sigtimedwait, sys_rt_sigtimedwait), // 176
//.. LINXY(__NR_rt_sigqueueinfo, sys_rt_sigqueueinfo), // 177
-//.. LINX_(__NR_rt_sigsuspend, sys_rt_sigsuspend), // 178
-//..=20
+ LINX_(__NR_rt_sigsuspend, sys_rt_sigsuspend), // 178
+
GENXY(__NR_pread64, sys_pread64), // 179
GENX_(__NR_pwrite64, sys_pwrite64), // 180
LINX_(__NR_chown, sys_chown16), // 181
Modified: trunk/coregrind/vki_unistd-ppc32-linux.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/vki_unistd-ppc32-linux.h 2005-11-16 10:23:15 UTC (rev=
5143)
+++ trunk/coregrind/vki_unistd-ppc32-linux.h 2005-11-16 12:51:34 UTC (rev=
5144)
@@ -207,7 +207,7 @@
//#define __NR_rt_sigpending 175
#define __NR_rt_sigtimedwait 176
//#define __NR_rt_sigqueueinfo 177
-//#define __NR_rt_sigsuspend 178
+#define __NR_rt_sigsuspend 178
#define __NR_pread64 179
#define __NR_pwrite64 180
#define __NR_chown 181
|
|
From: Julian S. <js...@ac...> - 2005-11-16 12:50:28
|
I've been looking into problems with LinuxThreads on a ppc system running 2.4.20 and glibc-2.3.2. A strange thing happens. Everything works fine until V tries to deliver a signal -- #32 or #33, one of the ones used internally by LinuxThreads -- to a thread whose SP (r1) points into the bss segment. That I found strange enough -- normally LinuxThreads allocates thread stacks via mmap of 8M chunks. However, I suspect perhaps the signalled thread was the manager thread and perhaps it has a small fixed size stack in bss. (Doesn't sound completely implausible). So all this works fine, the signal handler runs, but when the handler returns there's a problem: it returns to a 2-insn trampoline in the stack (created by stack_mcontext in sigframe-ppc32-linux.c). And that stack is in the bss and so is marked non-executable, and V notices that, and refuses to run that code, declaring a segfault instead. Then it all goes to hell. If I remove that no-translate-if-non-executable check, then it works fine. So I am mystified: - can anyone familiar with LinuxThreads internals comment on whether my inferences about the manager thread stack are correct? - should we be creating a bss segment which is executable as well as r/w-able? J |
|
From: Julian S. <js...@ac...> - 2005-11-16 11:55:52
|
> 3938 func_buf[1] = p[1]; > 3939 patch_op_imm16(func_buf, p, ii16[j]); > 3940 func = (void *)func_buf; > ...... > ...... > 3955 (*func)(); > > This program received a signal SIGILL(Illegal instruction) when it > executed at line 3955. I am not sure of the purpose of this slice of > code, I guess these are done on purpose, but I can't make out exactly. > > This test works util I remove all the tests about immediate args from > all_tests[]. Would any one have a look? Any suggestions are highly > appreciated! I think it is something to do with the global register variables defined near the top of the file. Maybe you can chase this? J |
|
From: <sv...@va...> - 2005-11-16 10:23:28
|
Author: tom
Date: 2005-11-16 10:23:15 +0000 (Wed, 16 Nov 2005)
New Revision: 5143
Log:
Bug status updates.
Modified:
trunk/docs/internals/3_0_BUGSTATUS.txt
Modified: trunk/docs/internals/3_0_BUGSTATUS.txt
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-16 03:51:02 UTC (rev 5=
142)
+++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-16 10:23:15 UTC (rev 5=
143)
@@ -109,8 +109,10 @@
----------------------------------------------------------------
113403 Looks like a segfault in realloc?
=20
-FIXED-TRUNK: TODO
+Not the same bug as the other realloc failures
=20
+FIXED-TRUNK: reporter says it no longer happens
+
----------------------------------------------------------------
113541 vex: the `impossible' happened: Grp5(x86) (alt encoding inc/dec)
case 1
@@ -119,7 +121,7 @@
----------------------------------------------------------------
113642 New: valgrind crashes when trying to read debug information
=20
-FIXED-TRUNK: 4856
+FIXED-TRUNK: vg:4856
=20
----------------------------------------------------------------
113810 priv/guest-x86/toIR.c:7964 (disInstr_X86_WRK): Assertion `sz =3D=
=3D 4'
@@ -133,7 +135,7 @@
Although the underlying cause is still present in the 3.0 code
this bug is only user visible in the 2.4 code base.
=20
-FIXED-TRUNK: 4852
+FIXED-TRUNK: vg:4852
=20
----------------------------------------------------------------
113851 vex x86->IR: (pmaddwd): 0x66 0xF 0xF5 0xC7
@@ -143,12 +145,23 @@
----------------------------------------------------------------
114366 New: vex amd64 cannnot handle __asm__( "fninit" )
=20
+FIXED-TRUNK: vex:1440
+
----------------------------------------------------------------
114412 vex amd64->IR: 0xF 0xAD 0xC2 0xD3 (128-bit shift, shrdq?)
=20
+FIXED-TRUNK: vex:1435
+
----------------------------------------------------------------
-114455: vex amd64->IR: 0xF 0xAC 0xD0 0x1 (also shrdq)
+114455 vex amd64->IR: 0xF 0xAC 0xD0 0x1 (also shrdq)
=20
+FIXED-TRUNK: vex:1436
+
+----------------------------------------------------------------
+116483 shmat failes with invalid argument when trying to attach a shm s=
egment
+
+FIXED-TRUNK: fixed by introduction of SkShmC during aspacem rewrite
+
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D Bugs targeted for 3.1.0 and 3.0.2 =
=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
@@ -180,7 +193,7 @@
----------------------------------------------------------------
n-i-bz Jeroen's XML-to-text FAQ.xml translator
=20
-FIXED-TRUNK: TODO
+FIXED-TRUNK: vg:4830
FIXED-30BRANCH: TODO
=20
----------------------------------------------------------------
@@ -280,18 +293,21 @@
----------------------------------------------------------------
113996 vex amd64->IR: fucomp (0xDD 0xE9 0xDF 0xE0)
=20
-FIXED-TRUNK: TODO
+FIXED-TRUNK: vex:1437
+FIXED-30BRANCH: TODO
=20
----------------------------------------------------------------
114196 vex x86->IR: out %eax,(%dx) (0xEF 0xC9 0xC3 0x90)
=20
FIXED-TRUNK: vex:1425
+FIXED-30BRANCH: TODO
(has good test case)
=20
----------------------------------------------------------------
114250 context record in signal handler contains incorrect values
=20
FIXED-TRUNK: TODO
+FIXED-30BRANCH: TODO
(has good test case)
=20
----------------------------------------------------------------
|
|
From: Tom H. <to...@co...> - 2005-11-16 10:04:58
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Wednesday 16 November 2005 08:13, Tom Hughes wrote:
>> In message <200...@gm...>
>> Josef Weidendorfer <Jos...@gm...> wrote:
>>
>> > On Wednesday 16 November 2005 01:09, sv...@va... wrote:
>> > > Reinstate code to extent SegInfo ranges to cover all PT_LOAD segments
>> > > when VG_(needs_data_syms) has been called by the tool.
>> >
>> > That was the patch fixing my problem, as I see.
>> >
>> > I do not really understand it, but callgrind is not
>> > setting VG_(needs_data_syms)... so the fix seems only to be about
>>
>> Yes it is - line 920 of main.c calls it.
>
> But this is done only with "--collect-data", which is an experimental
> option and not really working nowadays; ie. never used.
> There is no loss by removing it.
In which case my patch was a no-op for callgrind and shouldn't have
changed anything.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-16 09:40:43
|
On Wednesday 16 November 2005 08:13, Tom Hughes wrote: > In message <200...@gm...> > Josef Weidendorfer <Jos...@gm...> wrote: > > > On Wednesday 16 November 2005 01:09, sv...@va... wrote: > > > Reinstate code to extent SegInfo ranges to cover all PT_LOAD segments > > > when VG_(needs_data_syms) has been called by the tool. > > > > That was the patch fixing my problem, as I see. > > > > I do not really understand it, but callgrind is not > > setting VG_(needs_data_syms)... so the fix seems only to be about > > Yes it is - line 920 of main.c calls it. But this is done only with "--collect-data", which is an experimental option and not really working nowadays; ie. never used. There is no loss by removing it. But perhaps it is the right point to discuss a needed tools API feature for this: --collect-data is supposed to keep access/cache miss counters per data structure, not per line. For static data, I need the address ranges of static symbols, from the symbol table. But it is way to slow to let VG look up the list of symbols at every memory access. So I once patched VG for another callback to build up a fast lookup table myself, at symbol reading time. OTOH, this fast table is probably better to be in VG core itself. If I get some time, I'll try to provide a patch. Josef |
|
From: Tom H. <to...@co...> - 2005-11-16 07:13:16
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Wednesday 16 November 2005 01:09, sv...@va... wrote:
> > Reinstate code to extent SegInfo ranges to cover all PT_LOAD segments
> > when VG_(needs_data_syms) has been called by the tool.
>
> That was the patch fixing my problem, as I see.
>
> I do not really understand it, but callgrind is not
> setting VG_(needs_data_syms)... so the fix seems only to be about
Yes it is - line 920 of main.c calls it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <js...@ac...> - 2005-11-16 04:09:06
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-11-16 03:30:02 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 209 tests, 91 stderr failures, 2 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badfree (stderr) memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badloop (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/badrw (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/doublefree (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/fwrite (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc1 (stderr) memcheck/tests/malloc2 (stderr) memcheck/tests/malloc3 (stderr) memcheck/tests/malloc_usable (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel2 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/memalign2 (stderr) memcheck/tests/memalign_test (stderr) memcheck/tests/memcmptest (stderr) memcheck/tests/mempool (stderr) memcheck/tests/mismatches (stderr) memcheck/tests/mmaptest (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/null_socket (stderr) memcheck/tests/oset_test (stderr) memcheck/tests/overlap (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pipe (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/str_tester (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/with-space (stderr) memcheck/tests/writev (stderr) memcheck/tests/x86/fpeflags (stderr) memcheck/tests/x86/insn_basic (stderr) memcheck/tests/x86/insn_cmov (stderr) memcheck/tests/x86/insn_fpu (stderr) memcheck/tests/x86/insn_mmx (stderr) memcheck/tests/x86/insn_sse (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_fork (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/scalar_vfork (stderr) memcheck/tests/x86/tronical (stderr) memcheck/tests/xml1 (stderr) memcheck/tests/zeropage (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: <sv...@va...> - 2005-11-16 03:51:05
|
Author: sewardj
Date: 2005-11-16 03:51:02 +0000 (Wed, 16 Nov 2005)
New Revision: 5142
Log:
Slightly reorder the preamble-printing order, and also print the CPU arch=
/subarch detected.
Modified:
trunk/coregrind/m_main.c
Modified: trunk/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_main.c 2005-11-16 00:11:14 UTC (rev 5141)
+++ trunk/coregrind/m_main.c 2005-11-16 03:51:02 UTC (rev 5142)
@@ -1596,10 +1596,10 @@
=20
if (VG_(clo_verbosity) > 1) {
SysRes fd;
+ VexArch vex_arch;
+ VexArchInfo vex_archinfo;
if (!logging_to_fd)
VG_(message)(Vg_DebugMsg, "");
- VG_(message)(Vg_DebugMsg, "Valgrind library directory: %s", VG_(li=
bdir));
-
VG_(message)(Vg_DebugMsg, "Command line");
if (VG_(args_the_exename))
VG_(message)(Vg_DebugMsg, " %s", VG_(args_the_exename));
@@ -1629,6 +1629,12 @@
VG_(close)(fd.val);
# undef BUF_LEN
}
+
+ VG_(machine_get_VexArchInfo)( &vex_arch, &vex_archinfo );
+ VG_(message)(Vg_DebugMsg, "Arch and subarch: %s, %s",
+ LibVEX_ppVexArch ( vex_arch ),
+ LibVEX_ppVexSubArch( vex_archinfo.subarc=
h ) );
+ VG_(message)(Vg_DebugMsg, "Valgrind library directory: %s", VG_(li=
bdir));
}
}
=20
|
|
From: <js...@ac...> - 2005-11-16 03:45:25
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-11-16 04:40:00 CET Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 175 tests, 18 stderr failures, 0 stdout failures ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/clreq (stderr) cachegrind/tests/dlclose (stderr) massif/tests/toobig-allocs (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/mremap (stderr) |
|
From: Tom H. <to...@co...> - 2005-11-16 03:43:18
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-11-16 03:30:05 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 211 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 211 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 16 03:36:40 2005 --- new.short Wed Nov 16 03:43:04 2005 *************** *** 8,10 **** ! == 211 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) --- 8,10 ---- ! == 211 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) *************** *** 14,15 **** --- 14,16 ---- memcheck/tests/x86/scalar (stderr) + memcheck/tests/xml1 (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2005-11-16 03:31:15
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-11-16 03:15:06 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 210 tests, 18 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 210 tests, 17 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 16 03:23:42 2005 --- new.short Wed Nov 16 03:31:10 2005 *************** *** 8,10 **** ! == 210 tests, 17 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) --- 8,10 ---- ! == 210 tests, 18 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) *************** *** 25,26 **** --- 25,27 ---- memcheck/tests/stack_changes (stderr) + memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) |
|
From: Tom H. <th...@cy...> - 2005-11-16 03:26:33
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-11-16 03:10:08 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 4 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 16 03:20:58 2005 --- new.short Wed Nov 16 03:26:28 2005 *************** *** 8,11 **** ! == 228 tests, 4 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) none/tests/amd64/faultstatus (stderr) --- 8,12 ---- ! == 228 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) + memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) *************** *** 14,15 **** --- 15,17 ---- none/tests/x86/int (stderr) + none/tests/x86/yield (stdout) |
|
From: Tom H. <th...@cy...> - 2005-11-16 03:23:32
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-11-16 03:05:12 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/faultstatus (stderr) none/tests/mremap2 (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 16 03:17:53 2005 --- new.short Wed Nov 16 03:23:26 2005 *************** *** 8,12 **** ! == 228 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/faultstatus (stderr) --- 8,13 ---- ! == 228 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) + memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) *************** *** 15,17 **** none/tests/x86/int (stderr) - none/tests/x86/yield (stdout) --- 16,17 ---- |
|
From: Tom H. <th...@cy...> - 2005-11-16 03:21:24
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-11-16 03:00:03 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 16 03:06:24 2005 --- new.short Wed Nov 16 03:21:14 2005 *************** *** 8,11 **** ! == 228 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) none/tests/amd64/faultstatus (stderr) --- 8,12 ---- ! == 228 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) + memcheck/tests/xml1 (stderr) none/tests/amd64/faultstatus (stderr) |
|
From: Yao Qi <qiy...@cn...> - 2005-11-16 03:09:13
|
On Tue, Nov 15, 2005 at 11:07:29AM +0000, Tom Hughes wrote: > In message <200...@cn...> > Yao Qi <qiy...@cn...> wrote: > > > The part about debugging Valgrind in README_DEVELOPERS is out-of-date. > > I code a patch for this. > > I actually think we should drop all that - there are much easier ways > to debug valgrind now that everything is statically linked with the > tool: > > - Set VALGRIND_LAUNCHER to <prefix>/bin/valgrind > > - Run "gdb <prefix>/lib/valgrind/<platform>/<tool>" > > - Do "handle SIGSEGV nostop noprint" to stop gdb stopping on > a SEGV as valgrindd needs to be able to handle them to do > stack extension > > - Set any breakpoints you want and proceed as normal for gdb It is much simpler than the one I post, and it works well. This part could be replace 'Debugging Valgrind with GDB' in README_DEVELOPERS. I rewrite the part per your comments and list the new patch at the end of this mail. Any comments? Now, we could debug Valgrind in this way, and how about the option '--wait-for-gdb' and VG_(clo_wait_for_gdb)? Do you think it could be removed from coregrind/m_main.c? > > In principle debugging valgrind itself should work, the only problem > is getting control when it starts the tool to set breakpoints. Doing > a "catch exec" doesn't really work as that stops before the exec and > my gdb doesn't implement "catch start" or "catch thread_start". We can set breakpoint at load_client or vgPlain_do_exec, do you think it is OK? > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > Here is the nwe patch, Index: README_DEVELOPERS =================================================================== --- README_DEVELOPERS (revision 5114) +++ README_DEVELOPERS (working copy) @@ -35,22 +35,33 @@ Debugging Valgrind with GDB ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To debug stage 1 just run it under GDB in the normal way. +Now, it would be much easier to debug Valgrind now that everything is +statically linked with the tools, -To debug Valgrind proper (stage 2) with GDB, start Valgrind like this: +(1) Set VALGRIND_LAUNCHER to <prefix>/bin/valgrind - valgrind --tool=none --wait-for-gdb=yes <prog> + export VALGRIND_LAUNCHER=/usr/local/bin/valgrind + +(2) Run "gdb <prefix>/lib/valgrind/<platform>/<tool>" -Then start gdb like this in another terminal: + gdb /usr/local/lib/valgrind/ppc32-linux/lackey - gdb /usr/lib/valgrind/stage2 <pid> +(3) Do "handle SIGSEGV SIGILL nostop noprint" in GDB to prevent GDB from +stopping on a SIGSEGV or SIGILL. -Where <pid> is the pid valgrind printed. Then set whatever breakpoints -you want and do this in gdb: + (gdb) handle SIGILL SIGSEGV nostop noprint - jump *$eip +(4) Set any breakpoints you want and proceed as normal for gdb. The macro +VG_(FUNC) is expanded to vgPlain_FUNC, so If you want to set a breakpoint +on VG_(do_exec), you could do like this in GDB, + (gdb) b vgPlain_do_exec +(5) Run the tool with corresponding options. + + (gdb) run pwd + + Self-hosting ~~~~~~~~~~~~ To run Valgrind under Valgrind: -- Regards, Yao ------------ Yao Qi |
|
From: Josef W. <Jos...@gm...> - 2005-11-16 01:22:55
|
On Wednesday 16 November 2005 01:09, sv...@va... wrote: > Reinstate code to extent SegInfo ranges to cover all PT_LOAD segments > when VG_(needs_data_syms) has been called by the tool. That was the patch fixing my problem, as I see. I do not really understand it, but callgrind is not setting VG_(needs_data_syms)... so the fix seems only to be about > -#if 0 > ... > + mapped = mapped & ~(VKI_PAGE_SIZE-1); > mapped_end = (mapped_end + VKI_PAGE_SIZE - 1) & ~(VKI_PAGE_SIZE-1); I hope it is fine for tools using VG_(needs_data_syms), too. Josef |
|
From: Nicholas N. <nj...@cs...> - 2005-11-16 00:21:17
|
On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > A wish regarding the tool interface for the future: it would be good to > be able to get a string representation of a guest assembler instruction. I think this is a good idea too; it was a suggestion I had back before Vex was written but it got lost along the way. The string could be attached to each IMark. The DIP and DIS macros used in */toIR.c could be used as the basis of this. One neat effect is that it would allow tools to do platform-specific things if they really wanted to. Nick |
|
From: Tom H. <to...@co...> - 2005-11-16 00:13:39
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> There is no VG_(am_get_segname) and there will be no need for it ;-)
>
> I didn't find VG_(am_get_filename) in pub_tool_aspacemgr.h, so I proposed
> a quite bad name for it (because the variable is called segname[]).
>
> I am not sure if I need it, but if tools already have access to ASpaceMgr,
> it is desirable to get the name of a mapped file, too.
> Julian: yes, please put VG_(am_get_filename) into pub_tool_aspacemgr.h.
I've moved it into pub_tool_aspacemgr.h for you.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-16 00:12:59
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> > Does this patch help? It reinstates part of the ifdefed out code.
>
> Yes. 21160 is in GOT of libpthread-2.3.5.so again:
>
> .> 0x00004500(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4500]
> . > 0x00004530(0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x4530]
> . > 0x00021160 [GOT](0x2020202E, 0x2020202E, ...) [libpthread-2.3.5.so / 0x21160]
I've committed that patch now then.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2005-11-16 00:11:17
|
Author: tom
Date: 2005-11-16 00:11:14 +0000 (Wed, 16 Nov 2005)
New Revision: 5141
Log:
Move VG_(am_get_filename) to the tool accessible aspacemgr header file.
Modified:
trunk/coregrind/pub_core_aspacemgr.h
trunk/include/pub_tool_aspacemgr.h
Modified: trunk/coregrind/pub_core_aspacemgr.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/pub_core_aspacemgr.h 2005-11-16 00:09:15 UTC (rev 514=
0)
+++ trunk/coregrind/pub_core_aspacemgr.h 2005-11-16 00:11:14 UTC (rev 514=
1)
@@ -103,7 +103,8 @@
has one. The returned name's storage cannot be assumed to be
persistent, so the caller should immediately copy the name
elsewhere. */
-extern HChar* VG_(am_get_filename)( NSegment* );
+// Is in tool-visible header file.
+// extern HChar* VG_(am_get_filename)( NSegment* );
=20
/* VG_(am_get_segment_starts) is also part of this section, but its
prototype is tool-visible, hence not in this header file. */
Modified: trunk/include/pub_tool_aspacemgr.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/include/pub_tool_aspacemgr.h 2005-11-16 00:09:15 UTC (rev 5140)
+++ trunk/include/pub_tool_aspacemgr.h 2005-11-16 00:11:14 UTC (rev 5141)
@@ -137,6 +137,9 @@
extern NSegment* VG_(am_find_nsegment) ( Addr a );=20
=20
// See pub_core_aspacemgr.h for description.
+extern HChar* VG_(am_get_filename)( NSegment* );
+
+// See pub_core_aspacemgr.h for description.
extern Bool VG_(am_is_valid_for_client) ( Addr start, SizeT len,=20
UInt prot );
=20
|
|
From: <sv...@va...> - 2005-11-16 00:09:18
|
Author: tom
Date: 2005-11-16 00:09:15 +0000 (Wed, 16 Nov 2005)
New Revision: 5140
Log:
Reinstate code to extent SegInfo ranges to cover all PT_LOAD segments
when VG_(needs_data_syms) has been called by the tool.
Modified:
trunk/coregrind/m_debuginfo/symtab.c
Modified: trunk/coregrind/m_debuginfo/symtab.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_debuginfo/symtab.c 2005-11-16 00:05:58 UTC (rev 513=
9)
+++ trunk/coregrind/m_debuginfo/symtab.c 2005-11-16 00:09:15 UTC (rev 514=
0)
@@ -1525,11 +1525,8 @@
else
si->bss_size =3D 0;
}
-#if 0
- /* 20050228: disabled this until VG_(next_segment) can be
- reinstated in some clean incarnation of the low level
- memory manager. */
- mapped =3D mapped & ~(VKI_PAGE_SIZE-1);
+
+ mapped =3D mapped & ~(VKI_PAGE_SIZE-1);
mapped_end =3D (mapped_end + VKI_PAGE_SIZE - 1) & ~(VKI_PAGE_SIZE-1);
=20
if (VG_(needs).data_syms &&
@@ -1537,36 +1534,14 @@
(mapped_end > (si->start+si->size))) {
UInt newsz =3D mapped_end - si->start;
if (newsz > si->size) {
- Segment *seg;
-
if (0)
VG_(printf)("extending mapping %p..%p %d -> ..%p %d\n",=20
si->start, si->start+si->size, si->size,
si->start+newsz, newsz);
=20
- for(seg =3D VG_(find_segment_containing)(si->start);
- seg !=3D NULL && VG_(seg_overlaps)(seg, si->start, si->size);=20
- seg =3D VG_(next_segment)(seg)) {
- if (seg->symtab =3D=3D si)
- continue;
-
- if (seg->symtab !=3D NULL)
- VG_(seginfo_decref)(seg->symtab, seg->addr);
-
- VG_(seginfo_incref)(si);
- seg->symtab =3D si;
- =20
- if (0)
- VG_(printf)("adding symtab %p (%p-%p) to segment %p (%p-%p)\n",
- si, si->start, si->start+newsz,
- seg, seg->addr, seg->addr+seg->len);
- }
- =20
si->size =3D newsz;
}
}
-#endif
-
}
}
=20
@@ -1863,21 +1838,6 @@
VGP_POPCC(VgpReadSyms);
}
=20
-//static void seginfo_decref(SegInfo *si, Addr start)
-//{
-// vg_assert(si);
-// vg_assert(si->ref >=3D 1);
-// if (--si->ref =3D=3D 0)
-// unload_symbols(si->start, si->size);
-//}
-//
-//static void seginfo_incref(SegInfo *si)
-//{
-// vg_assert(si);
-// vg_assert(si->ref > 0);
-// si->ref++;
-//}
-
/*------------------------------------------------------------*/
/*--- Use of symbol table & location info to create ---*/
/*--- plausible-looking stack dumps. ---*/
|
|
From: <sv...@va...> - 2005-11-16 00:05:59
|
Author: tom Date: 2005-11-16 00:05:58 +0000 (Wed, 16 Nov 2005) New Revision: 5139 Log: Update bug status. Modified: trunk/docs/internals/3_0_BUGSTATUS.txt Modified: trunk/docs/internals/3_0_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-16 00:04:58 UTC (rev 5= 138) +++ trunk/docs/internals/3_0_BUGSTATUS.txt 2005-11-16 00:05:58 UTC (rev 5= 139) @@ -104,7 +104,7 @@ 113126 Crash with binaries built with -gstabs+/-ggdb 104065 =3D=3D =20 -FIXED-TRUNK: TODO +FIXED-TRUNK: vg:5138 =20 ---------------------------------------------------------------- 113403 Looks like a segfault in realloc? |
|
From: <sv...@va...> - 2005-11-16 00:05:06
|
Author: tom
Date: 2005-11-16 00:04:58 +0000 (Wed, 16 Nov 2005)
New Revision: 5138
Log:
Fix stabs decoder to allow :: in a method name provided it is inside
a template argument list. Fixes bug #113126.
Modified:
trunk/coregrind/m_debuginfo/stabs.c
Modified: trunk/coregrind/m_debuginfo/stabs.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_debuginfo/stabs.c 2005-11-15 20:56:23 UTC (rev 5137=
)
+++ trunk/coregrind/m_debuginfo/stabs.c 2005-11-16 00:04:58 UTC (rev 5138=
)
@@ -852,29 +852,39 @@
}
=20
while(*p !=3D ';') {
- Char *end;
+ Char *start =3D p;
Char *name;
UInt off, sz;
SymType *fieldty;
=20
- end =3D SKIPPAST(p, ':', "method name") - 1;
+ if (VG_(strncmp)(p, "operator<::", 11) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator>::", 11) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator<=3D::", 12) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator>=3D::", 12) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator<<::", 12) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator>>::", 12) =3D=3D 0 ||
+ VG_(strncmp)(p, "operator->::", 12) =3D=3D 0) {
+ p =3D SKIPPAST(p, ':', "member name");
+ } else {
+ p =3D templ_name(p);
+ EXPECT(':', "member name");
+ }
=20
- if (end[1] =3D=3D ':') {
+ if (p[0] =3D=3D ':') {
/* c++ method names end in :: */
method =3D True;
=20
- if (VG_(strncmp)(p, "op$", 3) =3D=3D 0) {
+ if (VG_(strncmp)(start, "op$", 3) =3D=3D 0) {
/* According to stabs.info, operators are named
( "op$::" OP '.' ), where OP is +=3D, etc. Current
gcc doesn't seem to use this; operators just
appear as "operator=3D=3D::" */
- end =3D SKIPPAST(end, '.', "op$ name");
+ p =3D SKIPPAST(p, '.', "op$ name");
}
- name =3D ML_(addStr)(si, p, end-p);
- p =3D end+2;
+ name =3D ML_(addStr)(si, start, p-start-1);
+ p =3D p+1;
} else {
- name =3D ML_(addStr)(si, p, end-p);
- p =3D end+1;
+ name =3D ML_(addStr)(si, start, p-start-1);
}
=20
if (method) {
|