You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(15) |
2
(12) |
3
(11) |
4
(20) |
5
(6) |
|
6
(6) |
7
(7) |
8
(8) |
9
(17) |
10
(25) |
11
(27) |
12
(6) |
|
13
(28) |
14
(16) |
15
(20) |
16
(9) |
17
(26) |
18
(7) |
19
(25) |
|
20
(7) |
21
(18) |
22
(25) |
23
(15) |
24
(21) |
25
(32) |
26
(15) |
|
27
(23) |
28
(33) |
|
|
|
|
|
|
From: Robert W. <rj...@du...> - 2005-02-17 16:56:36
|
On Thu, 2005-02-17 at 09:46 +0000, Julian Seward wrote: > Yesterday I managed to run 'hello world' on amd64 using the Vex-based > tree. Whoo-hoo! Excellent! --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Naveen K. <g_n...@ya...> - 2005-02-17 15:02:19
|
well what you could do is find the process mapping
just before it dumped core. I usually insert a {
while(1) sleep(5); } at that point. You can then look
at proc/[pid]/map to find out which object is loaded
around that address. Once you find that you can use
elfdump or some other tool to find out what
function/instruction this failed at. I do this if
loading the symbol-file for the object doesn't work
with gdb(no debugging symbols found).
Naveen
--- Nicholas Nethercote <nj...@cs...> wrote:
> On Tue, 15 Feb 2005, Jeremy Fitzhardinge wrote:
>
> > "x/i $eip" will show you the faulting instuction;
> from that you can
> > determine the effective address it was trying to
> access. You can get
> > register values with "print $<reg>".
>
> I get the following
>
> [~/grind/head2] gdb coregrind/valgrind core
> GNU gdb 5.3
> [...]
> This GDB was configured as "i686-pc-linux-gnu"...
> Core was generated by
> `/u/njn/grind/head2/coregrind/valgrind date'.
> Program terminated with signal 11, Segmentation
> fault.
> #0 0xb805ab88 in ?? ()
> (gdb) x/i $eip
> 0xb805ab88: Cannot access memory at address
> 0xb805ab88
>
> Does that mean it jumped to an address that had no
> underlying mapping?
>
> N
>
>
>
-------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT
> Products from real users.
> Discover which products truly live up to the hype.
> Start reading now.
>
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
>
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
|
|
From: Julian S. <js...@ac...> - 2005-02-17 09:47:07
|
Yesterday I managed to run 'hello world' on amd64 using the Vex-based
tree. This required executing 19370 basic blocks of amd64 code (1564
blocks translated). It means the basic integer instruction set is
beginning to work reliably. See the log below.
Almost everything else is still broken on amd64. Be assured that
Maximum Effort (tm) is being applied to get to something usable as
soon as possible; it will be a while, however.
J
sewardj@grinder:~/VgSVN/trunk$ cat hello64.c
#include <stdio.h>
int main ( void ) {
printf("\nhello, %lu-bit world\n\n", 8 * sizeof(char*));
return 0;
}
sewardj@grinder:~/VgSVN/trunk$ gcc -Wall -g -o hello64 hello64.c
sewardj@grinder:~/VgSVN/trunk$ ./Inst/bin/valgrind --tool=none -v ./hello64
[... misc debugging junk deleted ...]
==27320== Nulgrind, a binary JIT-compiler.
==27320== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==27320== Using valgrind-SVN >= 3207, a dynamic binary instrumentation
framework.
==27320== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==27320== For more details, rerun with: -v
==27320==
--27320-- ignoring --pointercheck (unimplemented)
[... misc debugging junk deleted ...]
hello, 64-bit world
==27320==
--27320-- tt/tc: 3130 tt lookups requiring 3159 probes
--27320-- tt/tc: 3130 fast-cache updates, 2 flushes
--27320-- translate: new 1564 (30850 -> 280640; ratio 90:10)
--27320-- translate: dumped 0 (0 -> ??)
--27320-- translate: discarded 0 (0 -> ??)
--27320-- dispatch: 19370 jumps (bb entries).
--27320-- 28/1635 major/minor sched events.
--27320-- sanity: 29 cheap, 2 expensive checks.
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 07:01:22
|
Nicholas Nethercote wrote:
> Hi,
>
> I've been removing some old junk from the code base. Here's some
> things I wasn't sure about removing:
>
> - FAQ 3.4 -- is that still needed?
Nope.
> - README_PACKAGERS -- the stuff about stripping, is that still
> true/correct?
Hm, not sure.
> - vg_intercepts.c -- does that still need to be generated from
> vg_intercept.c.base? I don't think so. Correspondingly, I think that
> comment about the "gory details" is no longer true.
All the intercepts are gone, so no.
> Does vg_replace_malloc.c still need this preprocessing, and
> the use of VG_INTERCEPT?
> (I really don't understand all that stuff, still.)
Yes; we still need to intercept all the malloc functions. All this
stuff is to make sure we intercept the allocators before they get called.
> - Section 2.8 of the manual talks about support for threads. It's out of
> date, I think it should be nuked. Anyone disagree?
Hm, some of it is still true, but a lot of the details are wrong.
> - I thought VG_USERREQ__MALLOC and all its associates (eg.
> VG_(sk_malloc_called_by_scheduler)) could be removed, but Jeremy,
> you've
> just started using them again in your latest commit. That's a shame,
> they're ugly.
Well, we could lose VG_(sk_malloc_called_by_scheduler) I think.
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 05:55:32
|
Nicholas Nethercote wrote:
> The bad address was 0xb805ab88, ie. within stage2, which doesn't seem
> unreasonable.
It looks like it has been linked as a normal executable, which we're
relocating to somewhere it doesn't expect.
>ELF Header:
> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF32
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
>
>
Hm, this is a normal executable, not an -fpie executable (which would be
DYN)...
> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
> PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
> INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
> [Requesting program interpreter: /lib/ld-linux.so.2]
> LOAD 0x000000 0x08048000 0x08048000 0xba440 0xba440 R E 0x1000
>
>
...loaded at the normal executable address.
J
|
|
From: <js...@ac...> - 2005-02-17 04:00:37
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-02-17 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 196 tests, 11 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-02-17 03:29:22
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-02-17 03:20:05 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 203 tests, 10 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/threadederrno (stderr) none/tests/cmdline2 (stdout) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:23:42
|
Hi, I've been removing some old junk from the code base. Here's some things I wasn't sure about removing: - FAQ 3.4 -- is that still needed? - README_PACKAGERS -- the stuff about stripping, is that still true/correct? - vg_intercepts.c -- does that still need to be generated from vg_intercept.c.base? I don't think so. Correspondingly, I think that comment about the "gory details" is no longer true. Does vg_replace_malloc.c still need this preprocessing, and the use of VG_INTERCEPT? (I really don't understand all that stuff, still.) - Section 2.8 of the manual talks about support for threads. It's out of date, I think it should be nuked. Anyone disagree? - I thought VG_USERREQ__MALLOC and all its associates (eg. VG_(sk_malloc_called_by_scheduler)) could be removed, but Jeremy, you've just started using them again in your latest commit. That's a shame, they're ugly. N |
|
From: Tom H. <th...@cy...> - 2005-02-17 03:23:14
|
Nightly build on audi ( Red Hat 9 ) started at 2005-02-17 03:15:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow int: valgrind --num-callers=4 ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 202 tests, 6 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) none/tests/cmdline2 (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-17 03:18:12
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-02-17 03:10:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 8 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) none/tests/cmdline2 (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-02-17 03:16:25
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-02-17 03:00:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow pushpopseg: valgrind --num-callers=4 ./pushpopseg rcl_assert: valgrind --num-callers=4 ./rcl_assert seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 9 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/cmdline2 (stdout) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:14:54
|
CVS commit by nethercote:
Remove out-of-date paragraph.
M +0 -22 README_PACKAGERS 1.6
--- valgrind/README_PACKAGERS #1.5:1.6
@@ -52,26 +52,4 @@
--- Try and ensure that the /usr/include/asm/unistd.h file on the
- build machine contains an entry for all the system calls that
- the kernels on the target machines can actually support. On my
- Red Hat 7.2 (kernel 2.4.9) box the highest-numbered entry is
- #define __NR_fcntl64 221
- but I have heard of 2.2 boxes where it stops at 179 or so.
-
- Reason for this is that at build time, support for syscalls
- is compiled in -- or not -- depending on which of these __NR_*
- symbols is defined. Problems arise when /usr/include/asm/unistd.h
- fails to give an entry for a system call which is actually
- available in the target kernel. In that case, valgrind will
- abort if asked to handle such a syscall. This is despite the
- fact that (usually) valgrind's sources actually contain the
- code to deal with the syscall.
-
- Several people have reported having this problem. So, please
- be aware of it. If it's useful, the syscall wrappers are
- all done in vg_syscall_mem.c; you might want to have a little
- look in there.
-
-
-- Please test the final installation works by running it on
something huge. I suggest checking that it can start and
|
|
From: Tom H. <th...@cy...> - 2005-02-17 03:12:35
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-02-17 03:05:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 201 tests, 14 stderr failures, 1 stdout failure ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/badjump (stderr) memcheck/tests/post-syscall (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/cmdline2 (stdout) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:12:27
|
On Wed, 16 Feb 2005, Jeremy Fitzhardinge wrote: >> What <pid> do I use? > > The pid of your valgrind which is under the control of gdb. Ie, look at > its maps while it is stopped in gdb. I wasn't running Valgrind under gdb... I was just using gdb to analyse the core file. Anyway, I run Valgrind under GDB and the maps are: 00000000-08048000 ---p 00000000 03:06 16 /tmp/.pad.11393.1 (deleted) 08048000-080a3000 r-xp 00000000 00:12 8428197 /v/filer3/v1q009/njn/grind/head2/inst/bin/valgrind 080a3000-080a6000 rw-p 0005a000 00:12 8428197 /v/filer3/v1q009/njn/grind/head2/inst/bin/valgrind 080a6000-080ca000 rwxp 00000000 00:00 0 080ca000-b1000000 ---p 00000000 03:06 16 /tmp/.pad.11393.1 (deleted) b1000000-b1013000 r-xp 00000000 03:01 26832 /lib/ld-2.2.5.so b1013000-b1014000 rw-p 00013000 03:01 26832 /lib/ld-2.2.5.so b1030000-b1032000 r-xp 00000000 03:01 26903 /lib/libdl-2.2.5.so b1032000-b1033000 rw-p 00001000 03:01 26903 /lib/libdl-2.2.5.so b1033000-b1146000 r-xp 00000000 03:01 26889 /lib/libc-2.2.5.so b1146000-b114c000 rw-p 00113000 03:01 26889 /lib/libc-2.2.5.so b114c000-b1151000 rw-p 00000000 00:00 0 b8048000-b8103000 r-xp 00000000 00:12 8428199 /v/filer3/v1q009/njn/grind/head2/inst/lib/valgrind/stage2 b8103000-b8105000 rw-p 000ba000 00:12 8428199 /v/filer3/v1q009/njn/grind/head2/inst/lib/valgrind/stage2 b8105000-b825b000 rw-p 00000000 00:00 0 bfffe000-c0000000 rwxp fffff000 00:00 0 The bad address was 0xb805ab88, ie. within stage2, which doesn't seem unreasonable. >> Executable range (nil)-0x203f00 is outside theacceptable range >> 0x50000000-0x52bfe000 >> valgrind: failed to load /u/njn/grind/head4/.in_place/stage2: Cannot >> allocate memory >> >> ie. the outer (non-PIE) Valgrind can't even load the PIE one. Now I'm >> confused. > > What does "readelf -hl .in_place/stage2" say? See attachment. N |
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:00:54
|
CVS commit by nethercote:
Removed a bunch of stuff no longer needed since the libpthread/proxyLWP
removal:
- Deleted NOTES.syscalls, which was about testing of the proxyLWP stuff
- Deleted coregrind/dosyms, which checked the symbols in our libpthread.so
matched the real one
- Massif no longer needs to know about vg_libpthread.c:my_malloc()
- filter_stderr_basic no longer needs to filter vg_libpthread.c
- arch_thread_aux type no longer used
- updated some comments
M +3 -4 coregrind/core.h 1.84
M +1 -1 coregrind/vg_syscalls.c 1.246
M +0 -10 coregrind/x86/core_arch.h 1.24
M +0 -1 massif/ms_main.c 1.24
M +0 -3 tests/filter_stderr_basic 1.21
R NOTES.syscalls 1.1
R coregrind/dosyms 1.2
--- valgrind/coregrind/core.h #1.83:1.84
@@ -909,8 +909,7 @@ extern void VG_(send_bytes_to_logging_si
// Functions for printing from code within Valgrind, but which runs on the
-// sim'd CPU. Defined here because needed for vg_libpthread.c,
-// vg_replace_malloc.c, plus the rest of the core. The weak attribute
-// ensures the multiple definitions are not a problem. They must be functions
-// rather than macros so that va_list can be used.
+// sim'd CPU. Defined here because needed for vg_replace_malloc.c. The
+// weak attribute ensures the multiple definitions are not a problem. They
+// must be functions rather than macros so that va_list can be used.
__attribute__((weak))
--- valgrind/coregrind/vg_syscalls.c #1.245:1.246
@@ -1728,5 +1728,5 @@ PRE(sys_execve, Special)
{
// Remove the valgrind-specific stuff from the environment so the
- // child doesn't get our libpthread and other stuff. This is
+ // child doesn't get vg_inject.so, vgpreload.so, etc. This is
// done unconditionally, since if we are tracing the child,
// stage1/2 will set up the appropriate client environment.
--- valgrind/coregrind/x86/core_arch.h #1.23:1.24
@@ -328,14 +328,4 @@ arch_thread_t;
/* ---------------------------------------------------------------------
- libpthread stuff
- ------------------------------------------------------------------ */
-
-struct arch_thread_aux {
- void* tls_data;
- int tls_segment;
- unsigned long sysinfo;
-};
-
-/* ---------------------------------------------------------------------
Signal stuff (should be plat)
------------------------------------------------------------------ */
--- valgrind/massif/ms_main.c #1.23:1.24
@@ -266,5 +266,4 @@ static Char* alloc_fns[MAX_ALLOC_FNS] =
"calloc",
"realloc",
- "my_malloc", // from vg_libpthread.c
"memalign",
};
--- valgrind/tests/filter_stderr_basic #1.20:1.21
@@ -23,7 +23,4 @@
sed "s/vg_intercept.c:[0-9]*/vg_intercept.c:.../" |
-# Anonymise vg_libpthread lines
-sed "s/vg_libpthread.c:[0-9]*/vg_libpthread.c:.../" |
-
# Hide suppressed error counts
sed "s/^\(ERROR SUMMARY[^(]*(suppressed: \)[0-9]*\( from \)[0-9]*)$/\10\20)/" |
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 03:00:02
|
CVS commit by nethercote:
Fix for new cmd line option.
M +1 -0 cmdline2.stdout.exp 1.12
--- valgrind/none/tests/cmdline2.stdout.exp #1.11:1.12
@@ -48,4 +48,5 @@
--trace-sched=no|yes show thread scheduler details? [no]
--wait-for-gdb=yes|no pause on startup to wait for gdb attach
+ --model-pthreads=yes|no model the pthreads library [no]
debugging options for Valgrind tools that report errors
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 02:50:40
|
Nicholas Nethercote wrote:
> What <pid> do I use?
The pid of your valgrind which is under the control of gdb. Ie, look at
its maps while it is stopped in gdb.
>> What happens if you try running the PIE valgrind under a non-PIE
>> valgrind with (mem|addr)check; does that give any more information?
>
>
> Doesn't work:
>
> Executable range (nil)-0x203f00 is outside theacceptable range
> 0x50000000-0x52bfe000
> valgrind: failed to load /u/njn/grind/head4/.in_place/stage2: Cannot
> allocate memory
>
> ie. the outer (non-PIE) Valgrind can't even load the PIE one. Now I'm
> confused.
What does "readelf -hl .in_place/stage2" say?
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-02-17 02:17:06
|
On Wed, 16 Feb 2005, Jeremy Fitzhardinge wrote: > While it is sitting crashed in GDB, you can look at /proc/<pid>/maps to > see where 0xb805ab88 lies in relationship to everything else in the > address space. That might give you a clue about what's going wrong. What <pid> do I use? > What happens if you try running the PIE valgrind under a non-PIE > valgrind with (mem|addr)check; does that give any more information? Doesn't work: Executable range (nil)-0x203f00 is outside theacceptable range 0x50000000-0x52bfe000 valgrind: failed to load /u/njn/grind/head4/.in_place/stage2: Cannot allocate memory ie. the outer (non-PIE) Valgrind can't even load the PIE one. Now I'm confused. N |
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:57:35
|
CVS commit by fitzhardinge:
An initial implementation of thread modelling. This allows valgrind to
obvserve and model the client's use of the native libpthread library,
and use that model to report on usage problems, and feed thread-related
events to tools such as helgrind.
This is definitely work in progress; this code won't do anything terribly
useful yet. You can enable it with --model-pthreads=yes.
A coregrind/vg_pthreadmodel.c 1.1 [GPL (v2+)]
A coregrind/vg_threadmodel.c 1.1 [GPL (v2+)]
A docs/tm-mutexstates.dot 1.1
A docs/tm-threadstates.dot 1.1
M +3 -0 coregrind/Makefile.am 1.108
M +50 -36 coregrind/core.h 1.83
M +5 -16 coregrind/vg_errcontext.c 1.67
M +35 -1 coregrind/vg_intercept.c.base 1.4
M +12 -0 coregrind/vg_main.c 1.250
M +15 -3 coregrind/vg_redir.c 1.5
M +4 -1 coregrind/vg_scheduler.c 1.222
M +4 -1 coregrind/vg_symtab2.c 1.103
--- valgrind/coregrind/Makefile.am #1.107:1.108
@@ -66,4 +66,6 @@
vg_signals.c \
vg_symtab2.c \
+ vg_threadmodel.c \
+ vg_pthreadmodel.c \
vg_redir.c \
vg_dwarf.c \
@@ -131,4 +133,5 @@
vg_intercept.c
vg_inject_so_CFLAGS = $(AM_CFLAGS) -fpic
+vg_inject_so_LDADD = -ldl
vg_inject_so_LDFLAGS = \
-shared \
--- valgrind/coregrind/core.h #1.82:1.83
@@ -278,4 +278,6 @@ extern Bool VG_(clo_trace_symtab);
/* DEBUG: print thread scheduling events? default: NO */
extern Bool VG_(clo_trace_sched);
+/* DEBUG: print pthreads calls? default: NO */
+extern Bool VG_(clo_trace_pthreads);
/* Display gory details for the k'th most popular error. default:
Infinity. */
@@ -304,4 +306,6 @@ extern Bool VG_(clo_show_below_main);
client address space bounds */
extern Bool VG_(clo_pointercheck);
+/* Model the pthread library */
+extern Bool VG_(clo_model_pthreads);
/* Set up the libc freeres wrapper */
@@ -544,41 +548,19 @@ extern Bool VG_(sk_malloc_called_by_sche
/* ---------------------------------------------------------------------
- Exports of vg_libpthread.c
+ Exports of vg_threadmodel.c
------------------------------------------------------------------ */
-/* Replacements for pthread types, shared between vg_libpthread.c and
- vg_scheduler.c. See comment in vg_libpthread.c above the other
- vg_pthread_*_t types for a description of how these are used. */
-
-struct _vg_pthread_fastlock
-{
- long int __vg_status; /* "Free" or "taken" or head of waiting list */
- int __vg_spinlock; /* Used by compare_and_swap emulation. Also,
- adaptive SMP lock stores spin count here. */
-};
-
-typedef struct
-{
- int __vg_m_reserved; /* Reserved for future use */
- int __vg_m_count; /* Depth of recursive locking */
- /*_pthread_descr*/ void* __vg_m_owner; /* Owner thread (if recursive or errcheck) */
- int __vg_m_kind; /* Mutex kind: fast, recursive or errcheck */
- struct _vg_pthread_fastlock __vg_m_lock; /* Underlying fast lock */
-} vg_pthread_mutex_t;
-
-typedef struct
-{
- struct _vg_pthread_fastlock __vg_c_lock; /* Protect against concurrent access */
- /*_pthread_descr*/ void* __vg_c_waiting; /* Threads waiting on this condition */
+extern void VG_(tm_threadcreate)(ThreadId creator, ThreadId tid, Bool detached);
+extern void VG_(tm_threadexit) (ThreadId tid);
+extern void VG_(tm_threadjoin) (ThreadId joiner, ThreadId joinee);
+extern void VG_(tm_switchto) (ThreadId tid);
- // Nb: the following padding removed because it was missing from an
- // earlier glibc, so the size test in the CONVERT macro was failing.
- // --njn
+extern void VG_(tm_mutex_init) (ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_destroy)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_trylock)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_giveup) (ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_acquire)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_unlock) (ThreadId tid, Addr mutexp);
- // Padding ensures the size is 48 bytes
- /*char __vg_padding[48 - sizeof(struct _vg_pthread_fastlock)
- - sizeof(void*) - sizeof(long long)];
- long long __vg_align;*/
-} vg_pthread_cond_t;
@@ -1039,7 +1021,11 @@ extern ExeContext* VG_(get_ExeContext2)
------------------------------------------------------------------ */
-extern void VG_(load_suppressions) ( void );
+typedef
+ enum {
+ ThreadErr = -1, // Thread error
+ }
+ CoreErrorKind;
-extern void VG_(record_pthread_error) ( ThreadId tid, Char* msg );
+extern void VG_(load_suppressions) ( void );
extern void VG_(show_all_errors) ( void );
@@ -1849,4 +1835,32 @@ extern void VGA_(interrupted_syscall)(Th
/* ---------------------------------------------------------------------
+ Thread modelling
+ ------------------------------------------------------------------ */
+extern void VG_(tm_thread_create) (ThreadId creator, ThreadId tid, Bool detached);
+extern void VG_(tm_thread_exit) (ThreadId tid);
+extern Bool VG_(tm_thread_exists) (ThreadId tid);
+extern void VG_(tm_thread_detach) (ThreadId tid);
+extern void VG_(tm_thread_join) (ThreadId joiner, ThreadId joinee);
+extern void VG_(tm_thread_switchto)(ThreadId tid);
+
+extern void VG_(tm_mutex_init) (ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_destroy)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_trylock)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_giveup) (ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_acquire)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_tryunlock)(ThreadId tid, Addr mutexp);
+extern void VG_(tm_mutex_unlock) (ThreadId tid, Addr mutexp);
+extern Bool VG_(tm_mutex_exists) (Addr mutexp);
+
+/* ----- pthreads ----- */
+extern void VG_(pthread_init) ();
+extern void VG_(pthread_startfunc_wrapper)(Addr wrapper);
+
+struct vg_pthread_newthread_data {
+ void *(*startfunc)(void *arg);
+ void *arg;
+};
+
+/* ---------------------------------------------------------------------
Finally - autoconf-generated settings
------------------------------------------------------------------ */
--- valgrind/coregrind/vg_errcontext.c #1.66:1.67
@@ -59,9 +59,4 @@ static Supp* is_suppressible_error ( Err
/* Note: it is imperative this doesn't overlap with (0..) at all, as tools
* effectively extend it by defining their own enums in the (0..) range. */
-typedef
- enum {
- PThreadErr = -1, // Pthreading error
- }
- CoreErrorKind;
/* Errors. Extensible (via the 'extra' field). Tools can use a normal
@@ -206,5 +201,5 @@ static Bool eq_Error ( VgRes res, Error*
switch (e1->ekind) {
- case PThreadErr:
+ case ThreadErr:
vg_assert(VG_(needs).core_errors);
if (e1->string == e2->string)
@@ -233,5 +228,5 @@ static void pp_Error ( Error* err, Bool
switch (err->ekind) {
- case PThreadErr:
+ case ThreadErr:
vg_assert(VG_(needs).core_errors);
VG_(message)(Vg_UserMsg, "%s", err->string );
@@ -335,5 +330,5 @@ static void gen_suppression(Error* err)
VG_(printf)(" <insert a suppression name here>\n");
- if (PThreadErr == err->ekind) {
+ if (ThreadErr == err->ekind) {
VG_(printf)(" core:PThread\n");
@@ -522,5 +517,5 @@ void VG_(maybe_record_error) ( ThreadId
/* update `extra', for non-core errors (core ones don't use 'extra') */
- if (VG_(needs).skin_errors && PThreadErr != ekind) {
+ if (VG_(needs).skin_errors && ThreadErr != ekind) {
extra_size = SK_(update_extra)(p);
@@ -601,10 +596,4 @@ Bool VG_(unique_error) ( ThreadId tid, E
/* These are called not from generated code but from the scheduler */
-void VG_(record_pthread_error) ( ThreadId tid, Char* msg )
-{
- if (! VG_(needs).core_errors) return;
- VG_(maybe_record_error)( tid, PThreadErr, /*addr*/0, msg, /*extra*/NULL );
-}
-
void VG_(show_all_errors) ( void )
{
@@ -945,5 +934,5 @@ Bool supp_matches_error(Supp* su, Error*
switch (su->skind) {
case PThreadSupp:
- return (err->ekind == PThreadErr);
+ return (err->ekind == ThreadErr);
default:
if (VG_(needs).skin_errors) {
--- valgrind/coregrind/vg_scheduler.c #1.221:1.222
@@ -662,5 +662,5 @@ VgSchedReturnCode VG_(scheduler) ( Threa
/* nothing */
VG_(set_running)(tid);
- VG_TRACK( thread_run, tid );
+ VG_(tm_thread_switchto)(tid);
/* OK, do some relatively expensive housekeeping stuff */
@@ -757,4 +757,7 @@ VgSchedReturnCode VG_(scheduler) ( Threa
VGP_POPCC(VgpSched);
+ if (VG_(clo_model_pthreads))
+ VG_(tm_thread_exit)(tid);
+
return tst->exitreason;
}
--- valgrind/coregrind/vg_main.c #1.249:1.250
@@ -1450,4 +1450,5 @@ Bool VG_(clo_trace_signals) = False;
Bool VG_(clo_trace_symtab) = False;
Bool VG_(clo_trace_sched) = False;
+Bool VG_(clo_trace_pthreads) = False;
Int VG_(clo_dump_error) = 0;
Int VG_(clo_backtrace_size) = 4;
@@ -1459,4 +1460,5 @@ Bool VG_(clo_show_below_main) = False;
Bool VG_(clo_pointercheck) = True;
Bool VG_(clo_branchpred) = False;
+Bool VG_(clo_model_pthreads) = False;
static Bool VG_(clo_wait_for_gdb) = False;
@@ -1515,4 +1517,5 @@ void usage ( Bool debug_help )
" --trace-sched=no|yes show thread scheduler details? [no]\n"
" --wait-for-gdb=yes|no pause on startup to wait for gdb attach\n"
+" --model-pthreads=yes|no model the pthreads library [no]\n"
"\n"
" debugging options for Valgrind tools that report errors\n"
@@ -1684,5 +1687,7 @@ static void process_cmd_line_options( UI
else VG_BOOL_CLO("--trace-symtab", VG_(clo_trace_symtab))
else VG_BOOL_CLO("--trace-syscalls", VG_(clo_trace_syscalls))
+ else VG_BOOL_CLO("--trace-pthreads", VG_(clo_trace_pthreads))
else VG_BOOL_CLO("--wait-for-gdb", VG_(clo_wait_for_gdb))
+ else VG_BOOL_CLO("--model-pthreads", VG_(clo_model_pthreads))
else VG_STR_CLO ("--db-command", VG_(clo_db_command))
@@ -2569,4 +2574,11 @@ int main(int argc, char **argv, char **e
//--------------------------------------------------------------
+ // Initialise the pthread model
+ // p: ?
+ //--------------------------------------------------------------
+ if (VG_(clo_model_pthreads))
+ VG_(pthread_init)();
+
+ //--------------------------------------------------------------
// Initialise the signal handling subsystem
// p: n/a
--- valgrind/coregrind/vg_redir.c #1.4:1.5
@@ -499,4 +499,6 @@ void VG_(wrap_before)(ThreadState *tst,
Addr argp = (Addr)&ARCH_FUNC_ARG(tst->arch, 0);
void *nonce = NULL;
+ Bool mf = VG_(my_fault);
+ VG_(my_fault) = True;
if (wrapper->before) {
@@ -532,4 +534,6 @@ void VG_(wrap_before)(ThreadState *tst,
} else
vg_assert(nonce == NULL);
+
+ VG_(my_fault) = mf;
}
@@ -540,8 +544,13 @@ void VG_(wrap_after)(ThreadState *tst)
Addr ESP = ARCH_STACK_PTR(tst->arch); /* pointer to args */
Word ret = ARCH_RETVAL(tst->arch); /* return value */
+ struct call_instance *call;
+ Bool mf = VG_(my_fault);
- struct call_instance *call = find_call(EIP, ESP, tst->tid);
+ VG_(my_fault) = True;
+ call = find_call(EIP, ESP, tst->tid);
+ if (0)
VG_(printf)("wrap_after(%p,%p,%d) -> %p\n", EIP, ESP, tst->tid, call);
+
if (call != NULL) {
if (call->wrapper->after)
@@ -551,4 +560,5 @@ void VG_(wrap_after)(ThreadState *tst)
VG_(SkipNode_Free)(&wrapped_frames, call);
}
+ VG_(my_fault) = mf;
}
@@ -608,4 +618,6 @@ Bool VG_(is_wrapper_return)(Addr eip)
}
+/* Mark eip as being the return address of a wrapper, so that the
+ codegen will generate the appropriate call. */
void wrapper_return(Addr eip)
{
--- valgrind/coregrind/vg_symtab2.c #1.102:1.103
@@ -821,5 +821,8 @@ static
void handle_wrapper( SegInfo* si, Char* symbol, Elf32_Sym* sym)
{
+ if (VG_(strcmp)(symbol, STR(VG_WRAPPER(freeres))) == 0)
VGA_(intercept_libc_freeres_wrapper)((Addr)(si->offset + sym->st_value));
+ else if (VG_(strcmp)(symbol, STR(VG_WRAPPER(pthread_startfunc_wrapper))) == 0)
+ VG_(pthread_startfunc_wrapper)((Addr)(si->offset + sym->st_value));
}
--- valgrind/coregrind/vg_intercept.c.base #1.3:1.4
@@ -1,3 +1,3 @@
-
+// -*- c -*-
/*--------------------------------------------------------------------*/
/*--- Intercepts for various libc functions we want to capture ---*/
@@ -69,4 +69,5 @@
#include <unistd.h>
#include <signal.h>
+#include <dlfcn.h>
/* ---------------------------------------------------------------------
@@ -87,4 +88,37 @@
}
+/*
+ The pthread_create wrapper repoints the "start_routine" argument to
+ this function. This function is here calls pthread_self(), which
+ the pthread model will notice and create the mapping from pthread_t
+ to Valgrind's internal ThreadId.
+ */
+void *VG_WRAPPER(pthread_startfunc_wrapper)(void *v)
+{
+ struct vg_pthread_newthread_data *data = (struct vg_pthread_newthread_data *)v;
+ void *(*func)(void *) = data->startfunc;
+ void *arg = data->arg;
+ int ret;
+ static pthread_t (*pthread_selfp)(void);
+
+ //VALGRIND_PRINTF("intercepted thread start: real start is %p(%p)\n", func, arg);
+
+ /* Do this rather than a direct call so we don't make an explicit
+ dependency on libpthread. One presumes that libpthread has
+ already been loaded if we've got to this point though. */
+ if (pthread_selfp == NULL)
+ pthread_selfp = dlsym(NULL, "pthread_self");
+
+ if (pthread_selfp != NULL)
+ (*pthread_selfp)(); /* just calling this is enough */
+
+ /* Free the data the before_pthread_create wrapper left for us. */
+ VALGRIND_MAGIC_SEQUENCE(ret, 0, VG_USERREQ__FREE, data, 0, 0, 0);
+
+ return (*func)(arg);
+
+ /* XXX should we tell core the thread returned? */
+}
+
/*--------------------------------------------------------------------*/
/*--- end vg_intercept.c ---*/
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:53:38
|
CVS commit by fitzhardinge:
If an address has multiple symbols, tend to prefer the shortest name,
since its likely the one most commonly used (ie, prefer "free" to "cfree",
or "__libc_GI_free_internal"). One exception to this rule is that we
prefer versioned symbols (@GLIBC_2.1) over non-versioned ones.
M +11 -57 vg_symtab2.c 1.102
--- valgrind/coregrind/vg_symtab2.c #1.101:1.102
@@ -409,70 +409,24 @@ static Int compare_RiSym(void *va, void
/* Two symbols have the same address. Which name do we prefer?
- In general we prefer the longer name, but if the choice is between
- __libc_X and X, then choose X (similarly with __GI__ and __
- prefixes).
+ The shortest. Always. Hm, well, prefer the ones with '@' symbol versioning in them.
+ If they're the same length, then alphabetical.
*/
static RiSym *prefersym(RiSym *a, RiSym *b)
{
- Int pfx;
Int lena, lenb;
- Int i;
- static const struct {
- const Char *prefix;
- Int len;
- } prefixes[] = {
-#define PFX(x) { x, sizeof(x)-1 }
- /* order from longest to shortest */
- PFX("__GI___libc_"),
- PFX("__GI___"),
- PFX("__libc_"),
- PFX("__GI__"),
- PFX("__GI_"),
- PFX("__"),
-#undef PFX
- };
+ Bool va = VG_(strchr)(a->name, '@') != NULL;
+ Bool vb = VG_(strchr)(b->name, '@') != NULL;
lena = VG_(strlen)(a->name);
lenb = VG_(strlen)(b->name);
-
- /* rearrange so that a is the long one */
- if (lena < lenb) {
- RiSym *t;
- Int lt;
-
- t = a;
- a = b;
- b = t;
-
- lt = lena;
- lena = lenb;
- lenb = lt;
- }
-
- /* Ugh. If we get a "free", always choose it. This is because
- normally, this function would choose "cfree" over free. cfree is
- an alias for free. If there's any more symbols like this, we may
- want to consider making this mechanism more generic.
- */
- if(VG_(strcmp)(a->name, "free") == 0)
+ if (va || lena < lenb)
return a;
-
- if(VG_(strcmp)(b->name, "free") == 0)
- return b;
-
- for(i = pfx = 0; i < sizeof(prefixes)/sizeof(*prefixes); i++) {
- Int pfxlen = prefixes[i].len;
-
- if (pfxlen < lena &&
- VG_(memcmp)(a->name, prefixes[i].prefix, pfxlen) == 0) {
- pfx = pfxlen;
- break;
- }
- }
-
- if (pfx != 0 && VG_(strcmp)(a->name + pfx, b->name) == 0)
+ else if (vb || lenb < lena)
return b;
+ if (VG_(strcmp)(a->name, b->name) < 0)
return a;
+ else
+ return b;
}
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:51:44
|
CVS commit by fitzhardinge:
Don't crash if the tool doesn't implement SK_(malloc)/(free) and the
client uses the MALLOC/FREE client requests. This is needed so the core
can allocate memory for the client, which the client can then free.
M +5 -4 gen_toolint.pl 1.7
M +2 -4 vg_default.c 1.26
--- valgrind/coregrind/gen_toolint.pl #1.6:1.7
@@ -85,4 +85,5 @@
print "$ret $pfxmap{$pfx}($func)($args);\n";
+ print "$ret VG_(missing_$func)($args);\n";
print "Bool VG_(defined_$func)(void);\n";
}
@@ -100,9 +101,9 @@
my $args = join ", ", @args;
- print "static $ret missing_${pfx}_$func($args) {\n";
+ print "__attribute__ ((weak))\n$ret VG_(missing_$func)($args) {\n";
print " VG_(missing_tool_func)(\"${pfx}_$func\");\n";
print "}\n";
print "Bool VG_(defined_$func)(void) {\n";
- print " return $struct.${pfx}_$func != missing_${pfx}_$func;\n";
+ print " return $struct.${pfx}_$func != VG_(missing_$func);\n";
print "}\n\n";
};
@@ -136,5 +137,5 @@
my ($pfx, $ret, $func, @args) = @_;
- print "$indent.${pfx}_$func = missing_${pfx}_$func,\n"
+ print "$indent.${pfx}_$func = VG_(missing_$func),\n"
};
$indent = " ";
@@ -150,5 +151,5 @@
{
if (func == NULL)
- func = missing_${pfx}_$func;
+ func = VG_(missing_$func);
if (VG_(defined_$func)())
VG_(printf)("Warning tool is redefining $func\\n");
--- valgrind/coregrind/vg_default.c #1.25:1.26
@@ -79,6 +79,5 @@ Bool VG_(sk_malloc_called_by_scheduler)
malloc()-replacing tool cannot forget to implement SK_(malloc)() or
SK_(free)(). */
-__attribute__ ((weak))
-void* SK_(malloc)( SizeT size )
+void* VG_(missing_malloc)( SizeT size )
{
if (VG_(sk_malloc_called_by_scheduler))
@@ -88,6 +87,5 @@ void* SK_(malloc)( SizeT size )
}
-__attribute__ ((weak))
-void SK_(free)( void* p )
+void VG_(missing_free)( void* p )
{
/* see comment for SK_(malloc)() above */
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:50:31
|
CVS commit by fitzhardinge:
Convert the "before" wrapper function to use a va_list for getting the
wrapped function's arguments.
M +1 -6 core.h 1.82
M +4 -2 vg_redir.c 1.4
M +3 -0 x86/core_arch.h 1.23
--- valgrind/coregrind/core.h #1.81:1.82
@@ -508,9 +508,4 @@ extern Bool VG_(is_empty_arena) ( Arena
#define VG_USERREQ__LIBC_FREERES_DONE 0x3029
-/*
-In core_asm.h:
-#define VG_USERREQ__SIGNAL_RETURNS 0x4001
-*/
-
#define VG_INTERCEPT_PREFIX "_vgi__"
#define VG_INTERCEPT_PREFIX_LEN 6
@@ -1108,5 +1103,5 @@ enum return_type {
typedef struct _FuncWrapper FuncWrapper;
struct _FuncWrapper {
- void *(*before)(ThreadState *tst);
+ void *(*before)(va_list args);
void (*after) (void *nonce, enum return_type, Word retval);
};
--- valgrind/coregrind/vg_redir.c #1.3:1.4
@@ -500,6 +500,8 @@ void VG_(wrap_before)(ThreadState *tst,
void *nonce = NULL;
- if (wrapper->before)
- nonce = (*wrapper->before)(tst);
+ if (wrapper->before) {
+ va_list args = ARCH_VA_LIST(tst->arch);
+ nonce = (*wrapper->before)(args);
+ }
if (wrapper->after) {
--- valgrind/coregrind/x86/core_arch.h #1.22:1.23
@@ -58,4 +58,7 @@
#define ARCH_RETVAL(regs) ((regs).m_eax)
+/* va_list on x86 is just a pointer to the first arg */
+#define ARCH_VA_LIST(regs) ((va_list)(ARCH_STACK_PTR(regs)+sizeof(Addr)))
+
#define ARCH_CLREQ_ARGS(regs) ((regs).m_eax)
#define ARCH_PTHREQ_RET(regs) ((regs).m_edx)
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:50:02
|
I'm checking in a work-in-progress snapshot of the pthread modelling
stuff. It handles thread creation, exit and join, and (non-recursive)
mutex operations. I've only tested it on little toy programs, nothing
real. The error reporting is just a stand-in.
This is just so people can get an idea of what I'm thinking, and with
luck, start jumping in when things are a little more stable. I'd like
to get this into working shape ASAP for the 2.4 release, so I think more
hands will help.
This is enabled with --model-pthreads=yes. Without that, none of this
code is ever called, and it should have no effect. That's why I'm not
worried about checking it in in this state.
There are two components: a thread model, and a libpthread binding for
the thread model. The thread model is almost completely abstract, and
has very little to do with the rest of Valgrind. It doesn't directly
interact with the concrete threads machinery at all.
The libpthread binding uses the wrapping machinery I checked in a while
ago to wrap calls to libthread, and generate a series of events for the
thread model.
TODO:
* do proper error reporting
* implement recursive mutexes
* implement condition variables
* implement rwlocks
* work out how to handle cancellation
* handle thread attributes
* handle mutex attributes
* test it against real programs/test suites
* fix helgrind
* make pthread-binding as implementation-neutral as possible
FUTURE TODO:
* implement (potential) deadlock detection (generate lock-ranking
graphs)
* handle the rest of libpthread (barriers, semaphores, etc)
* implement client callbacks for thread operations (for non-pthreads
private thread libraries)
* give thread model a separate abstract notion of a thread id
* handle N:1 and N:M thread models
J
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:36:55
|
CVS commit by fitzhardinge:
Remove the totally unused VG_USERREQ__SIGNAL_RETURNS.
M +0 -6 core_asm.h 1.7
M +0 -1 vg_scheduler.c 1.221
--- valgrind/coregrind/core_asm.h #1.6:1.7
@@ -62,10 +62,4 @@
#define VG_TT_FAST_MASK ((VG_TT_FAST_SIZE) - 1)
-/* Constants for the fast original-code-write check cache. */
-
-
-/* Assembly code stubs make this request */
-#define VG_USERREQ__SIGNAL_RETURNS 0x4001
-
// XXX: all this will go into x86/ eventually...
/*
--- valgrind/coregrind/vg_scheduler.c #1.220:1.221
@@ -992,5 +992,4 @@ void do_client_request ( ThreadId tid )
case VG_USERREQ__GET_SIGRT_MAX:
case VG_USERREQ__ALLOC_RTSIG:
- case VG_USERREQ__SIGNAL_RETURNS: /* not pthreads, but obsolete */
VG_(message)(Vg_UserMsg, "It looks like you've got an old libpthread.so* ");
VG_(message)(Vg_UserMsg, "installed in \"%s\".", VG_(libdir));
|
|
From: Jeremy F. <je...@go...> - 2005-02-17 01:34:40
|
Nicholas Nethercote wrote:
> I get the following
>
> [~/grind/head2] gdb coregrind/valgrind core
> GNU gdb 5.3
> [...]
> This GDB was configured as "i686-pc-linux-gnu"...
> Core was generated by `/u/njn/grind/head2/coregrind/valgrind date'.
> Program terminated with signal 11, Segmentation fault.
> #0 0xb805ab88 in ?? ()
> (gdb) x/i $eip
> 0xb805ab88: Cannot access memory at address 0xb805ab88
>
> Does that mean it jumped to an address that had no underlying mapping?
Yep, that means there was nothing at that address; the SEGV was from the
instruction fetch rather than from something the instruction did.
While it is sitting crashed in GDB, you can look at /proc/<pid>/maps to
see where 0xb805ab88 lies in relationship to everything else in the
address space. That might give you a clue about what's going wrong.
What happens if you try running the PIE valgrind under a non-PIE
valgrind with (mem|addr)check; does that give any more information? The
trouble with jumps into the void is that there's very little information
about where it came from (hence bug #98993). "x/x $esp" will show you
the top of the stack, which might be a return address.
J
|