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: Jeroen N. W. <jn...@xs...> - 2005-11-15 17:08:43
|
> In message <200...@gm...> > Josef Weidendorfer <Jos...@gm...> wrote: > >> On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote: >>> So I use VG_(am_find_nsegment), and see that the returned >>> segment has the DSO associated (SkFileC). >> >> Uhm.. how do I get the segname of a NSegment from a tool? >> I only have fnIdx... >> >> I suppose this needs a function >> Char* VG_(am_get_segname)(Int fnIdx) > > A bit like VG_(am_get_filename) you mean ;-) Which is in coregrind/pub_core_aspacemgr.h, not in include/pub_tool_aspacemgr.h ... I needed to move it, for blanket. I don't see why this interface cannot be public. Jeroen. |
|
From: Tom H. <to...@co...> - 2005-11-15 17:00:55
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote:
>> So I use VG_(am_find_nsegment), and see that the returned
>> segment has the DSO associated (SkFileC).
>
> Uhm.. how do I get the segname of a NSegment from a tool?
> I only have fnIdx...
>
> I suppose this needs a function
> Char* VG_(am_get_segname)(Int fnIdx)
A bit like VG_(am_get_filename) you mean ;-)
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 16:58:22
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 15 November 2005 11:47, Tom Hughes wrote:
>> > Currently, I try to use two different subdirs/Makefile.am's for this,
>> > using in the toplevel Makefile.am
>> >
>> > SUBDIRS = $(CG_SRCDIR)
>> >
>> > CG_SRCDIR is set to the right build directory dependent on what
>> > configure detected.
>>
>> Sounds horrid, but still...
>
> I am not a automake/conf guru.
> Perhaps only one Makefile.am is better. But this would need
> conditional targets? Is this supported?
You can possibly do it with automake conditionals, though you may need
automake 1.7 for that - valgrind does that now though anyway. See any
of the tools for how noinst_PROGRAMS is defined.
>> Sounds like I'm going to have fun getting
>> my in tree builds to work ;-)
>
> Why?
It's a horrid hack I use to build callgrind and valgrind all as part
of a single RPM so I have to patch callgrind to build against the
uninstalled version of valgrind in my build tree and not try and run
the installed valgrind to find out what version it is...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:52:59
|
On Tuesday 15 November 2005 17:03, Josef Weidendorfer wrote: > So I use VG_(am_find_nsegment), and see that the returned > segment has the DSO associated (SkFileC). Uhm.. how do I get the segname of a NSegment from a tool? I only have fnIdx... I suppose this needs a function Char* VG_(am_get_segname)(Int fnIdx) Josef |
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:50:08
|
On Tuesday 15 November 2005 11:47, Tom Hughes wrote: > > Currently, I try to use two different subdirs/Makefile.am's for this, > > using in the toplevel Makefile.am > > > > SUBDIRS = $(CG_SRCDIR) > > > > CG_SRCDIR is set to the right build directory dependent on what > > configure detected. > > Sounds horrid, but still... I am not a automake/conf guru. Perhaps only one Makefile.am is better. But this would need conditional targets? Is this supported? > Sounds like I'm going to have fun getting > my in tree builds to work ;-) Why? > The solution is to set DIST_SUBDIRS to list both directories. Ah, thanks! Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 16:49:10
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> Thanks everybody.
>
> On Tuesday 15 November 2005 12:38, Julian Seward wrote:
>> Yes. VG_(am_find_nsegment) is what you need to call -- this should match
>> (almost) exactly the current state of /proc/self/maps.
>
> Fine.
> So how do I detect that this is in the GOT of some DSO?
Dunno ;-)
> VG_(find_seginfo) will give no SegInfo.
> So I use VG_(am_find_nsegment), and see that the returned
> segment has the DSO associated (SkFileC).
>
> I just saw that only ld.so has this problem (not returning a SegInfo).
Only the text segment will normally have a SegInfo - the full rules
can be found in VG_(di_notify_mmap) in m_debuginfo/symtab.c but it
looks like:
ok = (seg->kind == SkFileC || (seg->kind == SkFileV && allow_SkFileV))
&& seg->offset == 0
&& seg->fnIdx != -1
&& seg->hasR
&& seg->hasX
&& !seg->hasW
&& is_elf_object_file( (const void*)seg->start );
So it has to be a file mapping at offset zero in the file that has read
and execute permission but not write permission. It also needs to look
like an ELF file.
So the data segment of ld.so is ruled out both because it is not at
offset zero and because it has write permission.
> Quite strange.
> For all other DSOs, I get e.g. the following call tree:
>
> > call_init(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0xB5D0]
> .> 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528]
> .> 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]
>
> And at 0x00021160 in libpthread-2.3.5.so, I have the blrl again.
Where does that [GOT] marker come from? What is the logic that
triggers it?
> Another question is why VG_(get_fnname) can not see the function name
> for libpthread-2.3.5.so:0x4500 and 0x4530. objdump and nm get them both
> fine: 4500 is _init, 4530 is call_initialize_minimal...
Which objdump/nm option? static or dynamic symbol table? or both?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:45:24
|
On Tuesday 15 November 2005 16:14, Nicholas Nethercote wrote: > On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > > > I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package. > > Why? Getting the automake/autoconf stuff right is hard enough... why make > it even more difficult for yourself? :) I do not want to do maintenance releases for a "Callgrind/VG 3.0". E.g. Callgrind 0.9.12 supports all stable VG releases from 2.0. This proved useful in the past. VG30 vs. 31 is special, because of the move to static linked tools. But regarding the tool code, it is not much difference, so I really want to keep one package. As long as it works, this seems to be the best way. If you look at the mailing list, there often are support queries for older VG releases, coming with some distro. E.g. if someone with Suse 10.0 is interested in Callgrind, he does not have to update to VG 3.1 before running newest Callgrind. Josef |
|
From: Josef W. <Jos...@gm...> - 2005-11-15 16:03:58
|
Thanks everybody. On Tuesday 15 November 2005 12:38, Julian Seward wrote: > Yes. VG_(am_find_nsegment) is what you need to call -- this should match > (almost) exactly the current state of /proc/self/maps. Fine. So how do I detect that this is in the GOT of some DSO? VG_(find_seginfo) will give no SegInfo. So I use VG_(am_find_nsegment), and see that the returned segment has the DSO associated (SkFileC). I just saw that only ld.so has this problem (not returning a SegInfo). Quite strange. For all other DSOs, I get e.g. the following call tree: > call_init(0x2020202E, 0x2020202E, ...) [ld-2.3.5.so / 0xB5D0] .> 0x04027528(0x2020202E, 0x2020202E, ...) [??? / 0x4027528] .> 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] And at 0x00021160 in libpthread-2.3.5.so, I have the blrl again. Another question is why VG_(get_fnname) can not see the function name for libpthread-2.3.5.so:0x4500 and 0x4530. objdump and nm get them both fine: 4500 is _init, 4530 is call_initialize_minimal... Josef |
|
From: Tom H. <to...@co...> - 2005-11-15 15:51:21
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sat, 12 Nov 2005, Nicholas Nethercote wrote:
>
>> I get this problem building memcheck/tests/stack_switch.c:
>
> I fixed this yesterday. Is there much difference between
> stack_switch.c and stack_changes.c? On my machine stack_changes.c
> fails badly (and always has) -- I get 8 or 9 invalid read/write errors.
I have no idea what stack_changes is testing - stack_switch I wrote
to test that bug I committed the patch for last week.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 15:50:42
|
-- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: <sv...@va...> - 2005-11-15 15:37:35
|
Author: njn Date: 2005-11-15 15:37:21 +0000 (Tue, 15 Nov 2005) New Revision: 230 Log: wibble Modified: trunk/help/projects.html Modified: trunk/help/projects.html =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/help/projects.html 2005-11-15 10:27:41 UTC (rev 229) +++ trunk/help/projects.html 2005-11-15 15:37:21 UTC (rev 230) @@ -5,8 +5,8 @@ try. They range from quite easy hacking projects to research-level problems. If you plan to try one of these projects, you should subscribe to <?php echo vglink( 'vgdevel' ); ?> list, and also write to -it to let us know you are doing the project, and you can ask questions -there also.</p> +it to let us know you are doing the project (just in case someone else i= s +working on it), and you can ask questions there also.</p> =20 <p>Please note that we are very conservative about adding new features. Only features that are useful to many users, and that do not adversely |
|
From: Nicholas N. <nj...@cs...> - 2005-11-15 15:33:45
|
On Fri, 4 Nov 2005, James Begley wrote: > Hmmm ... so thats why the whitespace was screwed up for Memcheck :-) > > The attached patch contains a hack to get round this. The original > function is left unchanged (and is called from within massif (and also > helgrind when that is re-enabled)) and a new version with extra > whitespace has been added, which is called from memcheck. > > With this patch applied, both "valgrind --tool=memcheck --help" and > "valgrind --tool=massif --help" look OK. > > I realise this falls into the category of ugly-brute-force hack. Indeed :) I won't commit this, I don't think it's worth the effort. Thanks for your help. Take a look at http://www.valgrind.org/help/projects.html if you want to do any more stuff like this :) Nick |
|
From: <sv...@va...> - 2005-11-15 15:27:19
|
Author: njn
Date: 2005-11-15 15:27:06 +0000 (Tue, 15 Nov 2005)
New Revision: 5133
Log:
More detail about pre-release testing.
Modified:
trunk/docs/internals/release-HOWTO.txt
Modified: trunk/docs/internals/release-HOWTO.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/release-HOWTO.txt 2005-11-15 02:24:57 UTC (rev 5=
132)
+++ trunk/docs/internals/release-HOWTO.txt 2005-11-15 15:27:06 UTC (rev 5=
133)
@@ -13,7 +13,7 @@
=20
- Tell valgrind-developers you want to do a release. Give a timeframe f=
or
everyone to check in any final features/bug-fixes they want in the
- release.
+ release. (Especially Josef Weidendorfer for Callgrind.)
=20
- Go over the docs, make sure they're up to date.
=20
@@ -51,9 +51,39 @@
releases, bug-fix-only releases might not need one):
=20
- Do pre-release testing:
- - Make sure regtests run ok on all platforms of interest.
- - Make sure Mozilla and OpenOffice run ok on all platforms of interest=
.
=20
+ * Check it builds and regtests on a vanilla gcc-2.96 / RedHat 7.3 dist=
ro.
+ Also check that callgrind builds/installs alongside it OK.
+
+ * Check standard build and regtest on the following cpus:
+ x86, sse2 (P4)
+ x86, sse1 (PIII)
+ x86, no sse (eg older VIA C3s, or perhaps even Pentium-MMX)
+ amd64
+ ppc32, altivec
+ ppc32, no altivec (eg old iMac G3s)
+
+ * Check that the regression tests work with --sanity-level=3D4 on all
+ platforms.
+
+ * Check valgrind-listener works on all archs, also connecting to it
+ from all archs.
+
+ * Check memcheck can run all the insn-set tests. The testsuite
+ only runs those on 'none', but memcheck looks at all primops, and I'=
ve
+ been caught out by this before. Basically all the programs in
+ none/tests/{x86,amd64,ppc32}.
+
+ * Check XML output is still readable by Valkyrie and vk_logmerge tools
+
+ * Test with large applications (firefox and OOo 2.0) on all platforms.
+
+ * Run regression tests from gsl-1.6 on all platforms. This is a good,
+ thorough test of FP. Easy, using the scripts auxprogs/gsl16test.
+
+ * Check that a tarball build of callgrind is buildable/installable
+ against a from-tarball build of valgrind.
+
- Change release number in AC_INIT() in configure.in to "X.Y.Z-rcN", whe=
re
'N' is the release candidate number.
=20
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-15 15:22:40
|
On Sat, 12 Nov 2005, Nicholas Nethercote wrote: > I get this problem building memcheck/tests/stack_switch.c: I fixed this yesterday. Is there much difference between stack_switch.c and stack_changes.c? On my machine stack_changes.c fails badly (and always has) -- I get 8 or 9 invalid read/write errors. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-11-15 15:15:08
|
On Tue, 15 Nov 2005, Josef Weidendorfer wrote: > I plan to release Callgrind both for VG 3.0 and VG 3.1 as one package. Why? Getting the automake/autoconf stuff right is hard enough... why make it even more difficult for yourself? :) Nick |
|
From: Julian S. <js...@ac...> - 2005-11-15 11:45:05
|
On Tuesday 15 November 2005 11:17, Paul Mackerras wrote: > Josef Weidendorfer writes: > > 1) There is a "strange function" with a single instruction "blrl". > > It is called quite often at the start of any code in /lib/ld.so, > > address 0x04027528; ld.so is mapped starting from 0x04000000. > > In the current PPC32 ELF ABI, there is a blrl instruction in the word > before the start of the GOT (global offset table). Shared libraries > use a bl GOT-4 to get the address of the GOT into LR in > position-independent code. I wouldn't consider the bl and blrl to > denote a function call. That would be nice. It's a bit like the the x86 idiom "call lbl; lbl: pop %reg" to get the current PC into %reg, which the x86 front end treats as a single entity. The problem is that the bl and blrl are in different BBs and so it's difficult to get the insn decoder to treat them as a single entity. I think the problem Josef was having is that although the bl is manifestly a call, the blrl is not obviously a return, and so callgrind's call-stack tracking stuff was seeing a lot of calls with no returns. > What particular aspect of that are you asking about? I think this is resolved now -- a query was being made to the wrong part of the system. J |
|
From: Tom H. <to...@co...> - 2005-11-15 11:44:17
|
In message <172...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Tom Hughes writes:
>
>> Why does the data section have execute permission? It wouldn't
>> normally have that on x86/amd64 systems.
>
> Two reasons: (1) you have to be able to execute the blrl at the base
> of the GOT, and (2) procedure calls between objects jump into the PLT,
> which contains instructions for either calling the dynamic linker or
> jumping to the procedure.
The PLT shouldn't be an issue as that is normally adjacent to the
text section so it will be part of the first mapping. Or is that
different on ppc as well?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul M. <pa...@sa...> - 2005-11-15 11:40:28
|
Tom Hughes writes: > Why does the data section have execute permission? It wouldn't > normally have that on x86/amd64 systems. Two reasons: (1) you have to be able to execute the blrl at the base of the GOT, and (2) procedure calls between objects jump into the PLT, which contains instructions for either calling the dynamic linker or jumping to the procedure. Paul. |
|
From: Julian S. <js...@ac...> - 2005-11-15 11:37:42
|
> > Sounds like the segment list and the maps file are out of sync for > > some reason, which is bad. What does --sanity-level=4 say? Does it > > report a sync check failure? > > Oh hang on, you're talking about SegInfo not NSegment... Not finding > a SegInfo just means there is no debug information associated with the > address which is normal if that is the data segment. Ah, good point. > You might be better off querying the address space manager which will > have a segment for all mapped memory. Yes. VG_(am_find_nsegment) is what you need to call -- this should match (almost) exactly the current state of /proc/self/maps. J |
|
From: Julian S. <js...@ac...> - 2005-11-15 11:33:09
|
On Tuesday 15 November 2005 11:07, 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 That does sound like a much better way, yes. Although you need to give --tool= as an explicit arg, else it tries to load the wrong vgpreload_tool.so. Apart from that it seems to work. J |
|
From: Tom H. <to...@co...> - 2005-11-15 11:30:47
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <200...@gm...>
> Josef Weidendorfer <Jos...@gm...> wrote:
>
>> According to callgrind debug output, address 0x04027528 is not attributed
>> to any segment by valgrind (using VG_(find_seginfo)()).
>> Looking at proc/XXX/maps, I get:
>>
>> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
>> 04017000-0401c000 rw-p 04017000 00:00 0
>> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
>> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>>
>> Does anybody have an idea what can cause this?
>
> Sounds like the segment list and the maps file are out of sync for
> some reason, which is bad. What does --sanity-level=4 say? Does it
> report a sync check failure?
Oh hang on, you're talking about SegInfo not NSegment... Not finding
a SegInfo just means there is no debug information associated with the
address which is normal if that is the data segment.
You might be better off querying the address space manager which will
have a segment for all mapped memory.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 11:29:16
|
In message <172...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Josef Weidendorfer writes:
>
>> According to callgrind debug output, address 0x04027528 is not attributed
>> to any segment by valgrind (using VG_(find_seginfo)()).
>> Looking at proc/XXX/maps, I get:
>>
>> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
>> 04017000-0401c000 rw-p 04017000 00:00 0
>> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
>> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>>
>> Does anybody have an idea what can cause this?
>
> What particular aspect of that are you asking about? It looks OK to
> me; the r--p bit is the relro section (relocation read-only), which is
> read/write while relocations are being done and then gets changed to
> read-only. The rwxp is the rest of the data section.
Why does the data section have execute permission? It wouldn't
normally have that on x86/amd64 systems.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-15 11:26:43
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> According to callgrind debug output, address 0x04027528 is not attributed
> to any segment by valgrind (using VG_(find_seginfo)()).
> Looking at proc/XXX/maps, I get:
>
> 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so
> 04017000-0401c000 rw-p 04017000 00:00 0
> 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so
> 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so
>
> Does anybody have an idea what can cause this?
Sounds like the segment list and the maps file are out of sync for
some reason, which is bad. What does --sanity-level=4 say? Does it
report a sync check failure?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul M. <pa...@sa...> - 2005-11-15 11:21:27
|
Josef Weidendorfer writes: > 1) There is a "strange function" with a single instruction "blrl". > It is called quite often at the start of any code in /lib/ld.so, > address 0x04027528; ld.so is mapped starting from 0x04000000. In the current PPC32 ELF ABI, there is a blrl instruction in the word before the start of the GOT (global offset table). Shared libraries use a bl GOT-4 to get the address of the GOT into LR in position-independent code. I wouldn't consider the bl and blrl to denote a function call. > According to callgrind debug output, address 0x04027528 is not attributed > to any segment by valgrind (using VG_(find_seginfo)()). > Looking at proc/XXX/maps, I get: > > 04000000-04017000 r-xp 00000000 03:03 557124 /lib/ld-2.3.5.so > 04017000-0401c000 rw-p 04017000 00:00 0 > 04026000-04027000 r--p 00016000 03:03 557124 /lib/ld-2.3.5.so > 04027000-04028000 rwxp 00017000 03:03 557124 /lib/ld-2.3.5.so > > Does anybody have an idea what can cause this? What particular aspect of that are you asking about? It looks OK to me; the r--p bit is the relro section (relocation read-only), which is read/write while relocations are being done and then gets changed to read-only. The rwxp is the rest of the data section. Paul. |
|
From: <sv...@va...> - 2005-11-15 11:16:34
|
Author: sewardj
Date: 2005-11-15 11:16:30 +0000 (Tue, 15 Nov 2005)
New Revision: 1460
Log:
Implement SSE2 'clflush'.
Modified:
trunk/priv/guest-x86/ghelpers.c
trunk/priv/guest-x86/toIR.c
Modified: trunk/priv/guest-x86/ghelpers.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/priv/guest-x86/ghelpers.c 2005-11-15 10:21:19 UTC (rev 1459)
+++ trunk/priv/guest-x86/ghelpers.c 2005-11-15 11:16:30 UTC (rev 1460)
@@ -2222,8 +2222,7 @@
=20
vex_state->guest_EMWARN =3D EmWarn_NONE;
=20
- /* These should not ever be either read or written, but we
- initialise them anyway. */
+ /* SSE2 has a 'clflush' cache-line-invalidator which uses these. */
vex_state->guest_TISTART =3D 0;
vex_state->guest_TILEN =3D 0;
}
Modified: trunk/priv/guest-x86/toIR.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/priv/guest-x86/toIR.c 2005-11-15 10:21:19 UTC (rev 1459)
+++ trunk/priv/guest-x86/toIR.c 2005-11-15 11:16:30 UTC (rev 1460)
@@ -225,6 +225,8 @@
=20
#define OFFB_EMWARN offsetof(VexGuestX86State,guest_EMWARN)
=20
+#define OFFB_TISTART offsetof(VexGuestX86State,guest_TISTART)
+#define OFFB_TILEN offsetof(VexGuestX86State,guest_TILEN)
=20
/*------------------------------------------------------------*/
/*--- Helper bits and pieces for deconstructing the ---*/
@@ -10339,7 +10341,6 @@
goto decode_success;
}
=20
-
//-- /* FXSAVE/FXRSTOR m32 -- load/store the FPU/MMX/SSE state. */
//-- if (insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0xAE=20
//-- && (!epartIsReg(insn[2]))
@@ -10356,25 +10357,38 @@
//-- DIP("fx%s %s\n", store ? "save" : "rstor", dis_buf );
//-- goto decode_success;
//-- }
-//--=20
-//-- /* CLFLUSH -- flush cache line */
-//-- if (insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0xAE
-//-- && (!epartIsReg(insn[2]))
-//-- && (gregOfRM(insn[2]) =3D=3D 7))
-//-- {
-//-- vg_assert(sz =3D=3D 4);
-//-- pair =3D disAMode ( cb, sorb, eip+2, dis_buf );
-//-- t1 =3D LOW24(pair);
-//-- eip +=3D 2+HI8(pair);
-//-- uInstr3(cb, SSE2a_MemRd, 0, /* ignore sz for internal ops */
-//-- Lit16, (((UShort)0x0F) << 8) | (UShort)0xAE,
-//-- Lit16, (UShort)insn[2],
-//-- TempReg, t1 );
-//-- DIP("clflush %s\n", dis_buf);
-//-- goto decode_success;
-//-- }
=20
+ /* 0F AE /7 =3D CLFLUSH -- flush cache line */
+ if (sz =3D=3D 4 && insn[0] =3D=3D 0x0F && insn[1] =3D=3D 0xAE
+ && !epartIsReg(insn[2]) && gregOfRM(insn[2]) =3D=3D 7) {
=20
+ /* This is something of a hack. We need to know the size of the
+ cache line containing addr. Since we don't (easily), assume
+ 256 on the basis that no real cache would have a line that
+ big. It's safe to invalidate more stuff than we need, just
+ inefficient. */
+ UInt lineszB =3D 256;
+
+ addr =3D disAMode ( &alen, sorb, delta+2, dis_buf );
+ delta +=3D 2+alen;
+
+ /* Round addr down to the start of the containing block. */
+ stmt( IRStmt_Put(
+ OFFB_TISTART,
+ binop( Iop_And32,=20
+ mkexpr(addr),=20
+ mkU32( ~(lineszB-1) ))) );
+
+ stmt( IRStmt_Put(OFFB_TILEN, mkU32(lineszB) ) );
+
+ irbb->jumpkind =3D Ijk_TInval;
+ irbb->next =3D mkU32(guest_EIP_bbstart+delta);
+ dres.whatNext =3D Dis_StopHere;
+
+ DIP("clflush %s\n", dis_buf);
+ goto decode_success;
+ }
+
/* ---------------------------------------------------- */
/* --- end of the SSE2 decoder. --- */
/* ---------------------------------------------------- */
|