You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(14) |
2
(4) |
3
(1) |
|
4
(5) |
5
(12) |
6
(3) |
7
(2) |
8
(3) |
9
(9) |
10
|
|
11
(4) |
12
(5) |
13
(5) |
14
(8) |
15
(10) |
16
(5) |
17
|
|
18
|
19
(2) |
20
(2) |
21
(3) |
22
(2) |
23
(9) |
24
(1) |
|
25
(3) |
26
(2) |
27
(6) |
28
(2) |
29
(6) |
30
(6) |
31
(3) |
|
From: Zachary D. <za...@si...> - 2005-12-12 08:20:34
|
I have an invalid read error and these messages at the end of the stack. What do they mean? Can they help me in any fashion? I did not find expalnation in the manual. Thanks, Zach. ==21942== Address 0x10 is not stack'd, malloc'd or (recently) free'd --21942-- --21942-- supp: 3 index-not-intercepted-early-enough-HACK-3 --21942-- supp: 1 strlen-not-intercepted-early-enough-HACK-3 --21942-- supp: 2 dl_relocate_object --21942-- supp: 4 realpath stupidity part II --21942-- supp: 78 realpath is inefficiently coded --21942-- supp: 1 strlen/*dl_map_object*(Cond) ==21942== |
|
From: Itay D. <Ita...@ex...> - 2005-12-12 07:51:49
|
I forget our system information,=20
we are using valgrind 3.1.0 And red hat 9 ,=20
The linux kernel version is 2.4.21-27
Sorry,
itay
-----Original Message-----
From: Itay Dar=20
Sent: Monday, December 12, 2005 9:47 AM
To: 'val...@li...'
Subject: Huge tlbfs
Hello,
First of all thank you for creating such a great tool, I used it in the
past on various occasions and it saved me a lot of time and effort.
We are trying to use valgrind on our system to check if we have
allocation problems, our memory management is done using our own
allocation system.
Our allocation system draws its memory from a hugetlbfs file, apparently
valgrind refuses to mmap the memory file.
The problem raises from the fact that when using mmap with no hint on
the address of the map file, valgrind chooses the page address, but the
page address is aligned to 4k boundaries which causes the call to fail
(the hugetlbfs page alignment is 2mb).
If we set the hint in the mmap call, valgrind doesn't change the hint
given and the call succeed.
Good call :=20
void* m1 =3D mmap((void*) 0x200000, 4194304, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED, fd, 0); Strace output taken from valgrind :
map2(0x200000, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3,
0) =3D 0x200000 Bad call=20
m3 =3D mmap(0, mem_size,PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0)) =3D=3D
MAP_FAILED) =20
Strace output taken from valgrind :
mmap2(0x4101000, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3,
0) =3D -1 EINVAL (Invalid argument)
this is what needs to be done to create the hugetlbfs file su mkdir
/var/memory echo 129 > /proc/sys/vm/hugetlb_pool; mount -t hugetlbfs
none /var/memory; dd if=3D/dev/zero of=3D/var/memory/0 bs=3D1M count=3D0
seek=3D128
And this is the test program,=20
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdlib.h>
int
main()
{
int fd=3D open("/var/memory/0", O_RDWR);
if (fd =3D=3D -1){
perror("file open failed");
exit(1);
}
int mem_size =3D 4096*1024;
unsigned long offset =3D 0;
void* m1 =3D mmap((void*) 0x200000, 4194304, =
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED, fd, 0);
if(m1 =3D=3D MAP_FAILED){
perror("error in mmap");
printf("1 no sugar, come back tommorow\n");
exit(1);
}
void* m2 =3D mmap((void*) 0x400000, 4194304,
PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, fd, 4194304);
if(m2 =3D=3D MAP_FAILED){
perror("error in mmap");
printf("2 no sugar, come back tommorow\n");
exit(1);
}
void* m3;
if((m3 =3D mmap(0, mem_size,PROT_READ|PROT_WRITE,MAP_SHARED, fd,
0)) =3D=3D MAP_FAILED) {
perror("error in mmap");
printf("3 no sugar, come back tommorow\n");
exit(1);
}
close(fd);
printf("all sugar\n");
return 0;
}
Thank you in adavance=20
Itay dar
|
|
From: Itay D. <Ita...@ex...> - 2005-12-12 07:47:15
|
Hello,
First of all thank you for creating such a great tool,=20
I used it in the past on various occasions and it saved me a lot of time
and effort.
We are trying to use valgrind on our system to check if we have
allocation problems, our memory management is done using our own
allocation system.
Our allocation system draws its memory from a hugetlbfs file, apparently
valgrind refuses to mmap the memory file.
The problem raises from the fact that when using mmap with no hint on
the address of the map file, valgrind chooses the page address,=20
but the page address is aligned to 4k boundaries which causes the call
to fail (the hugetlbfs page alignment is 2mb).
If we set the hint in the mmap call, valgrind doesn't change the hint
given and the call succeed.
Good call :=20
void* m1 =3D mmap((void*) 0x200000, 4194304, PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED, fd, 0);
Strace output taken from valgrind :
map2(0x200000, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3,
0) =3D 0x200000
Bad call=20
m3 =3D mmap(0, mem_size,PROT_READ|PROT_WRITE,MAP_SHARED, fd, 0)) =3D=3D
MAP_FAILED) =20
Strace output taken from valgrind :
mmap2(0x4101000, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3,
0) =3D -1 EINVAL (Invalid argument)
this is what needs to be done to create the hugetlbfs file
su
mkdir /var/memory
echo 129 > /proc/sys/vm/hugetlb_pool; =20
mount -t hugetlbfs none /var/memory;
dd if=3D/dev/zero of=3D/var/memory/0 bs=3D1M count=3D0 seek=3D128
And this is the test program,=20
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdlib.h>
int
main()
{
int fd=3D open("/var/memory/0", O_RDWR);
if (fd =3D=3D -1){
perror("file open failed");
exit(1);
}
int mem_size =3D 4096*1024;
unsigned long offset =3D 0;
void* m1 =3D mmap((void*) 0x200000, 4194304, =
PROT_READ|PROT_WRITE,
MAP_SHARED|MAP_FIXED, fd, 0);
if(m1 =3D=3D MAP_FAILED){
perror("error in mmap");
printf("1 no sugar, come back tommorow\n");
exit(1);
}
void* m2 =3D mmap((void*) 0x400000, 4194304,
PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, fd, 4194304);
if(m2 =3D=3D MAP_FAILED){
perror("error in mmap");
printf("2 no sugar, come back tommorow\n");
exit(1);
}
void* m3;
if((m3 =3D mmap(0, mem_size,PROT_READ|PROT_WRITE,MAP_SHARED, fd,
0)) =3D=3D MAP_FAILED) {
perror("error in mmap");
printf("3 no sugar, come back tommorow\n");
exit(1);
}
close(fd);
printf("all sugar\n");
return 0;
}
Thank you in adavance=20
Itay dar
|
|
From: Mads J. <mad...@mo...> - 2005-12-12 07:30:47
|
I only build it once on the amd64 box and then installed it there. Mads On Sun, 2005-12-11 at 14:57 +0000, Tom Hughes wrote: > In message <1133958570.25925.34.camel@localhost.localdomain> > Mads Jepsen <mad...@mo...> wrote: > > > I have tried to install valgrind to a non default path: > > ./configure --prefix some-path > > make all > > make install > > There is no problem in the x86 instalation, but for the amd64-linux I > > get the following error message: > > valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No > > such file or directory > > > > Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin > > directory. Which is the same relative path as x86-linux. > > Can I ask you to clarify exactly how you built and installed > valgrind? Did you build it once on an amd64 box or did you try and > build it twice, once for x86 and once for amd64 and then install > them both on the same box? > > Tom |
|
From: Tom H. <to...@co...> - 2005-12-11 15:00:52
|
In message <E7713D602248164BA45AA01734A1F5A105E0C7D8@MERC27.na.sas.com>
"Tom Truscott" <Tom...@sa...> wrote:
> [Hmm, looks like I didn't include the test pgm the first time]
>
> Consider the test program "fe.c" below. If I do cc -g fe.c and then valgrind --trace-children=no a.out
>
> ==4014== Conditional jump or move depends on uninitialised value(s)
> ==4014== at 0x40063D: main (fe.c:12)
>
> This is inside the child! Is that appropriate?
Yes - the option is misnamed. It actually controls whether valgrind
retains control on exec. The fork is always followed on both sides.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-12-11 14:59:24
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Wednesday 07 December 2005 13:29, Mads Jepsen wrote:
>
> > Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin
> > directory. Which is the same relative path as x86-linux.
>
> it should have been installed in ../lib64/...
Not necessarily - configuring by hand will use lib on most systems
and some distributions don't use lib64 at all.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-12-11 14:57:33
|
In message <1133958570.25925.34.camel@localhost.localdomain>
Mads Jepsen <mad...@mo...> wrote:
> I have tried to install valgrind to a non default path:
> ./configure --prefix some-path
> make all
> make install
> There is no problem in the x86 instalation, but for the amd64-linux I
> get the following error message:
> valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No
> such file or directory
>
> Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin
> directory. Which is the same relative path as x86-linux.
Can I ask you to clarify exactly how you built and installed
valgrind? Did you build it once on an amd64 box or did you try and
build it twice, once for x86 and once for amd64 and then install
them both on the same box?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-12-11 14:55:12
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> I've just got the following error with valgrind 3.1.0:
Could you raise a bug for it please...
> ==01:02:38:32.373 2400== Warning: set address range perms: large range
> 268439552, a 1, v 1
> ==01:02:50:00.615 2400== Warning: set address range perms: large range
> 268439552, a 0, v 0
> --01:02:52:57.936 2400-- INTERNAL ERROR: Valgrind received a signal 7 (SIGBUS)
> - exiting
Any time you get an INTERNAL ERROR message like that you have found
a bug of some sort in valgrind and you should open a bug for it.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom T. <Tom...@sa...> - 2005-12-09 21:55:47
|
[Hmm, looks like I didn't include the test pgm the first time]
Consider the test program "fe.c" below. If I do cc -g fe.c and then =
valgrind --trace-children=3Dno a.out
=3D=3D4014=3D=3D Conditional jump or move depends on =
uninitialised value(s)
=3D=3D4014=3D=3D at 0x40063D: main (fe.c:12)
This is inside the child! Is that appropriate?
What I am really trying to do is exec a set-user-id program. Currently =
valgrind fails with EACCES but I prefer that it instead print a warning =
and then just exec the program untraced (which is what "truss"-type =
commands do).
Thanks much for considering this,
Tom Truscott
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#include <stdio.h>
#include <unistd.h>
int main()
{
int uninit;
switch(fork())
{
case -1: perror("fork"); return 1;
case 0: /* child */
if (uninit) printf("child: bletch\n");
execl("/bin/su", "su", NULL);
perror("execl");
return 1;
}
printf("parent: sleeping\n");
sleep(10);
return 0;
}
|
|
From: Joe B. <j....@f5...> - 2005-12-09 18:42:51
|
Hi There,
I'm new to valgrind - so please forgive me if I have made a mess...
I'm trying to simply use the memcheck with a program that's leaking some
memory.
I've run the following commands:
sudo ./configure
sudo make
sudo make install
When I try to run the program I get the following:
valgrind /home/jboyle/p4/main/DynaCache/publish/bin/pvac -n -f
/home/jboyle/p4/main/DynaCache/publish/conf/pvsystem.conf -r -a 23412 -b
/home/jboyle/p4/main/DynaCache/publish/tmp/pvac_hd_info -m 200
valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No
such file or directory
What am I doing wrong?
I did notice that when I ran the make install I got the following output
(with errors at the end regarding memcheck):
make install-recursive
make[1]: Entering directory `/opt/valgrind/valgrind-3.1.0'
Making install in include
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0/include'
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0/include'
make[3]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/include/valgrind" || mkdir -p --
"/usr/local/include/valgrind"
/usr/bin/install -c -m 644 'pub_tool_basics.h'
'/usr/local/include/valgrind/pub_tool_basics.h'
/usr/bin/install -c -m 644 'pub_tool_basics_asm.h'
'/usr/local/include/valgrind/pub_tool_basics_asm.h'
/usr/bin/install -c -m 644 'pub_tool_aspacemgr.h'
'/usr/local/include/valgrind/pub_tool_aspacemgr.h'
/usr/bin/install -c -m 644 'pub_tool_clientstate.h'
'/usr/local/include/valgrind/pub_tool_clientstate.h'
/usr/bin/install -c -m 644 'pub_tool_cpuid.h'
'/usr/local/include/valgrind/pub_tool_cpuid.h'
/usr/bin/install -c -m 644 'pub_tool_debuginfo.h'
'/usr/local/include/valgrind/pub_tool_debuginfo.h'
/usr/bin/install -c -m 644 'pub_tool_errormgr.h'
'/usr/local/include/valgrind/pub_tool_errormgr.h'
/usr/bin/install -c -m 644 'pub_tool_execontext.h'
'/usr/local/include/valgrind/pub_tool_execontext.h'
/usr/bin/install -c -m 644 'pub_tool_hashtable.h'
'/usr/local/include/valgrind/pub_tool_hashtable.h'
/usr/bin/install -c -m 644 'pub_tool_libcbase.h'
'/usr/local/include/valgrind/pub_tool_libcbase.h'
/usr/bin/install -c -m 644 'pub_tool_libcassert.h'
'/usr/local/include/valgrind/pub_tool_libcassert.h'
/usr/bin/install -c -m 644 'pub_tool_libcfile.h'
'/usr/local/include/valgrind/pub_tool_libcfile.h'
/usr/bin/install -c -m 644 'pub_tool_libcprint.h'
'/usr/local/include/valgrind/pub_tool_libcprint.h'
/usr/bin/install -c -m 644 'pub_tool_libcproc.h'
'/usr/local/include/valgrind/pub_tool_libcproc.h'
/usr/bin/install -c -m 644 'pub_tool_libcsignal.h'
'/usr/local/include/valgrind/pub_tool_libcsignal.h'
/usr/bin/install -c -m 644 'pub_tool_machine.h'
'/usr/local/include/valgrind/pub_tool_machine.h'
/usr/bin/install -c -m 644 'pub_tool_mallocfree.h'
'/usr/local/include/valgrind/pub_tool_mallocfree.h'
/usr/bin/install -c -m 644 'pub_tool_options.h'
'/usr/local/include/valgrind/pub_tool_options.h'
/usr/bin/install -c -m 644 'pub_tool_oset.h'
'/usr/local/include/valgrind/pub_tool_oset.h'
/usr/bin/install -c -m 644 'pub_tool_profile.h'
'/usr/local/include/valgrind/pub_tool_profile.h'
/usr/bin/install -c -m 644 'pub_tool_redir.h'
'/usr/local/include/valgrind/pub_tool_redir.h'
/usr/bin/install -c -m 644 'pub_tool_replacemalloc.h'
'/usr/local/include/valgrind/pub_tool_replacemalloc.h'
/usr/bin/install -c -m 644 'pub_tool_signals.h'
'/usr/local/include/valgrind/pub_tool_signals.h'
/usr/bin/install -c -m 644 'pub_tool_stacktrace.h'
'/usr/local/include/valgrind/pub_tool_stacktrace.h'
/usr/bin/install -c -m 644 'pub_tool_threadstate.h'
'/usr/local/include/valgrind/pub_tool_threadstate.h'
/usr/bin/install -c -m 644 'pub_tool_tooliface.h'
'/usr/local/include/valgrind/pub_tool_tooliface.h'
/usr/bin/install -c -m 644 'valgrind.h'
'/usr/local/include/valgrind/valgrind.h'
/usr/bin/install -c -m 644 'vki-linux.h'
'/usr/local/include/valgrind/vki-linux.h'
/usr/bin/install -c -m 644 'vki-amd64-linux.h'
'/usr/local/include/valgrind/vki-amd64-linux.h'
/usr/bin/install -c -m 644 'vki-ppc32-linux.h'
'/usr/local/include/valgrind/vki-ppc32-linux.h'
/usr/bin/install -c -m 644 'vki-x86-linux.h'
'/usr/local/include/valgrind/vki-x86-linux.h'
/usr/bin/install -c -m 644 'vki_posixtypes-amd64-linux.h'
'/usr/local/include/valgrind/vki_posixtypes-amd64-linux.h'
/usr/bin/install -c -m 644 'vki_posixtypes-ppc32-linux.h'
'/usr/local/include/valgrind/vki_posixtypes-ppc32-linux.h'
/usr/bin/install -c -m 644 'vki_posixtypes-x86-linux.h'
'/usr/local/include/valgrind/vki_posixtypes-x86-linux.h'
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0/include'
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0/include'
Making install in coregrind
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0/coregrind'
make install-am
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0/coregrind'
make -C ../VEX pub/libvex_guest_offsets.h
make[4]: Entering directory `/opt/valgrind/valgrind-3.1.0/VEX'
make[4]: `pub/libvex_guest_offsets.h' is up to date.
make[4]: Leaving directory `/opt/valgrind/valgrind-3.1.0/VEX'
for f in vgpreload_core-x86-linux.so ; do \
p=`echo $f | sed -e 's/^[^-]*-//' -e 's/\..*$//'`; \
n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
mkdir -p ../.in_place/$p; \
rm -f ../.in_place/$p/$n; \
ln -f -s ../../coregrind/$f ../.in_place/$p/$n; \
done
make[4]: Entering directory `/opt/valgrind/valgrind-3.1.0/coregrind'
test -z "/usr/local/bin" || mkdir -p -- "/usr/local/bin"
/usr/bin/install -c 'valgrind' '/usr/local/bin/valgrind'
for f in vgpreload_core-x86-linux.so ; do \
p=`echo $f | sed -e 's/^[^-]*-//' -e 's/\..*$//'`; \
n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
/opt/valgrind/valgrind-3.1.0/install-sh -d /usr/local/lib/valgrind/$p; \
/usr/bin/install -c $f /usr/local/lib/valgrind/$p/$n; \
done ; \
for f in libcoregrind_x86_linux.a
libreplacemalloc_toolpreload_x86_linux.a ; do \
if expr match $f libcoregrind_ > /dev/null ; then \
pU=`echo $f | sed -e 's/libcoregrind_//g' -e 's/\.a//g'` ; \
pD=`echo $pU | sed -e 's/_/-/g'` ; \
/usr/bin/install -c -m 644 $f
/usr/local/lib/valgrind/$pD/libcoregrind.a ; \
/usr/bin/install -c -m 644 ../VEX/libvex_$pU.a
/usr/local/lib/valgrind/$pD/libvex.a ; \
fi ; \
done
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory `/opt/valgrind/valgrind-3.1.0/coregrind'
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0/coregrind'
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0/coregrind'
Making install in .
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0'
mkdir -p ./.in_place
rm -f ./.in_place/default.supp ./.in_place/glibc-2.2.supp
./.in_place/glibc-2.3.supp ./.in_place/glibc-2.4.supp
./.in_place/xfree-3.supp ./.in_place/xfree-4.supp
ln -s ../default.supp ./.in_place
ln -s .././glibc-2.2.supp .././glibc-2.3.supp .././glibc-2.4.supp
.././xfree-3.supp .././xfree-4.supp ./.in_place
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0'
make install-exec-hook
make[4]: Entering directory `/opt/valgrind/valgrind-3.1.0'
/opt/valgrind/valgrind-3.1.0/install-sh -d /usr/local/lib/valgrind
make[4]: Leaving directory `/opt/valgrind/valgrind-3.1.0'
test -z "/usr/local/lib/valgrind" || mkdir -p -- "/usr/local/lib/valgrind"
/usr/bin/install -c -m 644 'glibc-2.2.supp'
'/usr/local/lib/valgrind/glibc-2.2.supp'
/usr/bin/install -c -m 644 'glibc-2.3.supp'
'/usr/local/lib/valgrind/glibc-2.3.supp'
/usr/bin/install -c -m 644 'glibc-2.4.supp'
'/usr/local/lib/valgrind/glibc-2.4.supp'
/usr/bin/install -c -m 644 'xfree-3.supp'
'/usr/local/lib/valgrind/xfree-3.supp'
/usr/bin/install -c -m 644 'xfree-4.supp'
'/usr/local/lib/valgrind/xfree-4.supp'
/usr/bin/install -c -m 644 'default.supp'
'/usr/local/lib/valgrind/default.supp'
test -z "/usr/local/include/valgrind" || mkdir -p --
"/usr/local/include/valgrind"
/usr/bin/install -c -m 644 './VEX/pub/libvex_guest_amd64.h'
'/usr/local/include/valgrind/libvex_guest_amd64.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_ir.h'
'/usr/local/include/valgrind/libvex_ir.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_guest_ppc32.h'
'/usr/local/include/valgrind/libvex_guest_ppc32.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_basictypes.h'
'/usr/local/include/valgrind/libvex_basictypes.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_guest_offsets.h'
'/usr/local/include/valgrind/libvex_guest_offsets.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_emwarn.h'
'/usr/local/include/valgrind/libvex_emwarn.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex.h'
'/usr/local/include/valgrind/libvex.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_trc_values.h'
'/usr/local/include/valgrind/libvex_trc_values.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_guest_arm.h'
'/usr/local/include/valgrind/libvex_guest_arm.h'
/usr/bin/install -c -m 644 './VEX/pub/libvex_guest_x86.h'
'/usr/local/include/valgrind/libvex_guest_x86.h'
test -z "/usr/local/lib/pkgconfig" || mkdir -p -- "/usr/local/lib/pkgconfig"
/usr/bin/install -c -m 644 'valgrind.pc'
'/usr/local/lib/pkgconfig/valgrind.pc'
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0'
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0'
Making install in tests
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0/tests'
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0/tests'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0/tests'
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0/tests'
Making install in auxprogs
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0/auxprogs'
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0/auxprogs'
test -z "/usr/local/bin" || mkdir -p -- "/usr/local/bin"
/usr/bin/install -c 'valgrind-listener' '/usr/local/bin/valgrind-listener'
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0/auxprogs'
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0/auxprogs'
Making install in memcheck
make[2]: Entering directory `/opt/valgrind/valgrind-3.1.0/memcheck'
Making install in .
make[3]: Entering directory `/opt/valgrind/valgrind-3.1.0/memcheck'
for f in memcheck-x86-linux vgpreload_memcheck-x86-linux.so ; do \
p=`echo $f | sed -e 's/^[^-]*-//' -e 's/\..*$//'`; \
n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
mkdir -p ../.in_place/$p; \
rm -f ../.in_place/$p/$n; \
ln -f -s ../../memcheck/$f ../.in_place/$p/$n; \
done
make[4]: Entering directory `/opt/valgrind/valgrind-3.1.0/memcheck'
for f in memcheck-x86-linux vgpreload_memcheck-x86-linux.so ; do \
p=`echo $f | sed -e 's/^[^-]*-//' -e 's/\..*$//'`; \
n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`; \
/opt/valgrind/valgrind-3.1.0/install-sh -d /usr/local/lib/valgrind/$p; \
/usr/bin/install -c $f /usr/local/lib/valgrind/$p/$n; \
done ; \
for f in ; do \
if expr match $f libcoregrind_ > /dev/null ; then \
pU=`echo $f | sed -e 's/libcoregrind_//g' -e 's/\.a//g'` ; \
pD=`echo $pU | sed -e 's/_/-/g'` ; \
/usr/bin/install -c -m 644 $f
/usr/local/lib/valgrind/$pD/libcoregrind.a ; \
/usr/bin/install -c -m 644 ../VEX/libvex_$pU.a
/usr/local/lib/valgrind/$pD/libvex.a ; \
fi ; \
done
/bin/sh: -c: line 1: syntax error near unexpected token `;'
/bin/sh: -c: line 1: `for f in memcheck-x86-linux
vgpreload_memcheck-x86-linux.so ; do p=`echo $f | sed -e 's/^[^-]*-//'
-e 's/\..*$//'`; n=`echo $f | sed -e 's/-[^-]\{1,\}-[^-.]\{1,\}//'`;
/opt/valgrind/valgrind-3.1.0/install-sh -d /usr/local/lib/valgrind/$p;
/usr/bin/install -c $f /usr/local/lib/valgrind/$p/$n; done ; for f in
; do if expr match $f libcoregrind_ > /dev/null ; then pU=`echo $f |
sed -e 's/libcoregrind_//g' -e 's/\.a//g'` ; pD=`echo $pU | sed -e
's/_/-/g'` ; /usr/bin/install -c -m 644 $f
/usr/local/lib/valgrind/$pD/libcoregrind.a ; /usr/bin/install -c -m 644
../VEX/libvex_$pU.a /usr/local/lib/valgrind/$pD/libvex.a ; fi ; done'
make[4]: *** [install-exec-local] Error 2
make[4]: Leaving directory `/opt/valgrind/valgrind-3.1.0/memcheck'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/opt/valgrind/valgrind-3.1.0/memcheck'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/opt/valgrind/valgrind-3.1.0/memcheck'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/opt/valgrind/valgrind-3.1.0'
make: *** [install] Error 2
[jboyle@carnival valgrind-3.1.0]$
|
|
From: Yeshurun, M. <mei...@in...> - 2005-12-09 17:21:18
|
Thanks! I'll do what you suggested.
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Julian
Seward
Sent: Friday, December 09, 2005 4:34 PM
To: val...@li...
Subject: Re: FW: [Valgrind-users] Valgrind log file corruption
Meir,
Line 7809 is the first place at which the JIT picks up insn bytes. If
it
segfaults at this point it generally means V's idea of what parts of the
address space are valid have diverged from what the kernel thinks,
because V would not have attempted to translate at this address if
it thought the area did not have x permission.
I suggest you re-run with --sanity-level=3D3. This should pick up any
V/kernel disagreements about page permissions. If you do get a
complaint (I can't remember the exact wording) then run yet again
but also adding --trace-syscalls=3Dyes, so we can see if the =
disagreement
was caused by V mishandling a syscall somewhere.
J
On Friday 09 December 2005 07:02, Yeshurun, Meir wrote:
> Hi,
>
>
>
> Below is the context of line 7809 of toIR.c
>
>
>
> Could it be that I hit something very close to a magic number (my
> application is very large), which caused more expressions inside the
> 'if' condition to be evaluated, until an invalid read occurred?
>
>
>
> Thanks,
>
> Meir
>
>
>
>
>
> /* We may be asked to update the guest RIP before going further. */
>
> if (put_IP)
>
> stmt( IRStmt_Put( OFFB_RIP, mkU64(guest_RIP_curr_instr)) );
>
>
>
> /* Spot the client-request magic sequence. */
>
> {
>
> UChar* code =3D (UChar*)(guest_code + delta);
>
> /* Spot this:
>
> C1C01D roll $29, %eax
>
> C1C003 roll $3, %eax
>
> C1C81B rorl $27, %eax
>
> C1C805 rorl $5, %eax
>
> C1C00D roll $13, %eax
>
> C1C013 roll $19, %eax
>
> */
>
> if (code[ 0] =3D=3D 0xC1 && code[ 1] =3D=3D 0xC0 && code[ 2] =
=3D=3D 0x1D &&
-
> line 7809
>
> code[ 3] =3D=3D 0xC1 && code[ 4] =3D=3D 0xC0 && code[ 5] =
=3D=3D 0x03 &&
>
> code[ 6] =3D=3D 0xC1 && code[ 7] =3D=3D 0xC8 && code[ 8] =
=3D=3D 0x1B &&
>
> code[ 9] =3D=3D 0xC1 && code[10] =3D=3D 0xC8 && code[11] =
=3D=3D 0x05 &&
>
> code[12] =3D=3D 0xC1 && code[13] =3D=3D 0xC0 && code[14] =
=3D=3D 0x0D &&
>
> code[15] =3D=3D 0xC1 && code[16] =3D=3D 0xC0 && code[17] =
=3D=3D 0x13
>
> ) {
>
> DIP("%%edx =3D client_request ( %%eax )\n");
>
> delta +=3D 18;
>
> jmp_lit(Ijk_ClientReq, guest_RIP_bbstart+delta);
>
> dres.whatNext =3D Dis_StopHere;
>
> goto decode_success;
>
> }
>
> }
>
>
>
> /* Eat prefixes, summarising the result in pfx and sz, and
rejecting
>
> as many invalid combinations as possible. */
>
> n_prefixes =3D 0;
>
> while (True) {
>
> if (n_prefixes > 5) goto decode_failure;
>
>
>
> ________________________________
>
> From: val...@li...
> [mailto:val...@li...] On Behalf Of
> Yeshurun, Meir
> Sent: Thursday, December 08, 2005 10:21 PM
> To: val...@li...
> Subject: [Valgrind-users] Valgrind log file corruption
>
>
>
> Hi,
>
>
>
> I ran Valgrind and got this:
>
>
>
> valgrind: the 'impossible' happened:
>
> Killed by fatal signal
>
> =3D=3D4019=3D=3D at 0x8000D55FA: disInstr_AMD64_WRK (toIR.c:7809)
>
> =3D=3D4019=3D=3D by 0x8000E5492: disInstr_AMD64 (toIR.c:13376)
>
> =3D=3D4019=3D=3D by 0x80009ED3E: bb_to_IR (bb_to_IR.c:187)
>
> =3D=3D4019=3D=3D by 0x800074B75: LibVEX_Translate (vex_main.c:408)
>
> =3D=3D4019=3D=3D by 0x80003300A: vgPlain_translate
(libvex_basictypes.h:154)
>
> =3D=3D4019=3D=3D by 0x80004A156: handle_tt_miss (scheduler.c:566)
>
> =3D=3D4019=3D=3D by 0x80004A537: vgPlain_scheduler =
(scheduler.c:680)
>
> =3D=3D4019=3D=3D by 0x80006A863: vgModuleLocal_thread_wrapper
> (syswrap-linux.c:80)
>
> =3D=3D4019=3D=3D by 0x800065753: run_a_thread_NORETURN
> (syswrap-amd64-linux.c:144)
>
>
>
> sched status:
>
> running_tid=3D1
>
>
>
> Thread 1: status =3D VgTs_Runnable
>
>
>
>
>
> Is this an unsupported instruction? Any suggestions would be greatly
> appreciated.
>
>
>
>
>
> Thanks,
>
> Meir
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <js...@ac...> - 2005-12-09 14:37:30
|
Meir,
Line 7809 is the first place at which the JIT picks up insn bytes. If it
segfaults at this point it generally means V's idea of what parts of the
address space are valid have diverged from what the kernel thinks,
because V would not have attempted to translate at this address if
it thought the area did not have x permission.
I suggest you re-run with --sanity-level=3. This should pick up any
V/kernel disagreements about page permissions. If you do get a
complaint (I can't remember the exact wording) then run yet again
but also adding --trace-syscalls=yes, so we can see if the disagreement
was caused by V mishandling a syscall somewhere.
J
On Friday 09 December 2005 07:02, Yeshurun, Meir wrote:
> Hi,
>
>
>
> Below is the context of line 7809 of toIR.c
>
>
>
> Could it be that I hit something very close to a magic number (my
> application is very large), which caused more expressions inside the
> 'if' condition to be evaluated, until an invalid read occurred?
>
>
>
> Thanks,
>
> Meir
>
>
>
>
>
> /* We may be asked to update the guest RIP before going further. */
>
> if (put_IP)
>
> stmt( IRStmt_Put( OFFB_RIP, mkU64(guest_RIP_curr_instr)) );
>
>
>
> /* Spot the client-request magic sequence. */
>
> {
>
> UChar* code = (UChar*)(guest_code + delta);
>
> /* Spot this:
>
> C1C01D roll $29, %eax
>
> C1C003 roll $3, %eax
>
> C1C81B rorl $27, %eax
>
> C1C805 rorl $5, %eax
>
> C1C00D roll $13, %eax
>
> C1C013 roll $19, %eax
>
> */
>
> if (code[ 0] == 0xC1 && code[ 1] == 0xC0 && code[ 2] == 0x1D && -
> line 7809
>
> code[ 3] == 0xC1 && code[ 4] == 0xC0 && code[ 5] == 0x03 &&
>
> code[ 6] == 0xC1 && code[ 7] == 0xC8 && code[ 8] == 0x1B &&
>
> code[ 9] == 0xC1 && code[10] == 0xC8 && code[11] == 0x05 &&
>
> code[12] == 0xC1 && code[13] == 0xC0 && code[14] == 0x0D &&
>
> code[15] == 0xC1 && code[16] == 0xC0 && code[17] == 0x13
>
> ) {
>
> DIP("%%edx = client_request ( %%eax )\n");
>
> delta += 18;
>
> jmp_lit(Ijk_ClientReq, guest_RIP_bbstart+delta);
>
> dres.whatNext = Dis_StopHere;
>
> goto decode_success;
>
> }
>
> }
>
>
>
> /* Eat prefixes, summarising the result in pfx and sz, and rejecting
>
> as many invalid combinations as possible. */
>
> n_prefixes = 0;
>
> while (True) {
>
> if (n_prefixes > 5) goto decode_failure;
>
>
>
> ________________________________
>
> From: val...@li...
> [mailto:val...@li...] On Behalf Of
> Yeshurun, Meir
> Sent: Thursday, December 08, 2005 10:21 PM
> To: val...@li...
> Subject: [Valgrind-users] Valgrind log file corruption
>
>
>
> Hi,
>
>
>
> I ran Valgrind and got this:
>
>
>
> valgrind: the 'impossible' happened:
>
> Killed by fatal signal
>
> ==4019== at 0x8000D55FA: disInstr_AMD64_WRK (toIR.c:7809)
>
> ==4019== by 0x8000E5492: disInstr_AMD64 (toIR.c:13376)
>
> ==4019== by 0x80009ED3E: bb_to_IR (bb_to_IR.c:187)
>
> ==4019== by 0x800074B75: LibVEX_Translate (vex_main.c:408)
>
> ==4019== by 0x80003300A: vgPlain_translate (libvex_basictypes.h:154)
>
> ==4019== by 0x80004A156: handle_tt_miss (scheduler.c:566)
>
> ==4019== by 0x80004A537: vgPlain_scheduler (scheduler.c:680)
>
> ==4019== by 0x80006A863: vgModuleLocal_thread_wrapper
> (syswrap-linux.c:80)
>
> ==4019== by 0x800065753: run_a_thread_NORETURN
> (syswrap-amd64-linux.c:144)
>
>
>
> sched status:
>
> running_tid=1
>
>
>
> Thread 1: status = VgTs_Runnable
>
>
>
>
>
> Is this an unsupported instruction? Any suggestions would be greatly
> appreciated.
>
>
>
>
>
> Thanks,
>
> Meir
|
|
From: Yeshurun, M. <mei...@in...> - 2005-12-09 07:02:16
|
Hi,
=20
Below is the context of line 7809 of toIR.c
=20
Could it be that I hit something very close to a magic number (my
application is very large), which caused more expressions inside the
'if' condition to be evaluated, until an invalid read occurred?
=20
Thanks,
Meir
=20
=20
/* We may be asked to update the guest RIP before going further. */
if (put_IP)
stmt( IRStmt_Put( OFFB_RIP, mkU64(guest_RIP_curr_instr)) );
=20
/* Spot the client-request magic sequence. */
{
UChar* code =3D (UChar*)(guest_code + delta);
/* Spot this:
C1C01D roll $29, %eax
C1C003 roll $3, %eax
C1C81B rorl $27, %eax
C1C805 rorl $5, %eax
C1C00D roll $13, %eax
C1C013 roll $19, %eax =20
*/
if (code[ 0] =3D=3D 0xC1 && code[ 1] =3D=3D 0xC0 && code[ 2] =
=3D=3D 0x1D && -
line 7809
code[ 3] =3D=3D 0xC1 && code[ 4] =3D=3D 0xC0 && code[ 5] =
=3D=3D 0x03 &&
code[ 6] =3D=3D 0xC1 && code[ 7] =3D=3D 0xC8 && code[ 8] =
=3D=3D 0x1B &&
code[ 9] =3D=3D 0xC1 && code[10] =3D=3D 0xC8 && code[11] =
=3D=3D 0x05 &&
code[12] =3D=3D 0xC1 && code[13] =3D=3D 0xC0 && code[14] =
=3D=3D 0x0D &&
code[15] =3D=3D 0xC1 && code[16] =3D=3D 0xC0 && code[17] =
=3D=3D 0x13
) {
DIP("%%edx =3D client_request ( %%eax )\n"); =20
delta +=3D 18;
jmp_lit(Ijk_ClientReq, guest_RIP_bbstart+delta);
dres.whatNext =3D Dis_StopHere;
goto decode_success;
}
}
=20
/* Eat prefixes, summarising the result in pfx and sz, and rejecting
as many invalid combinations as possible. */
n_prefixes =3D 0;
while (True) {
if (n_prefixes > 5) goto decode_failure;
=20
________________________________
From: val...@li...
[mailto:val...@li...] On Behalf Of
Yeshurun, Meir
Sent: Thursday, December 08, 2005 10:21 PM
To: val...@li...
Subject: [Valgrind-users] Valgrind log file corruption
=20
Hi,
=20
I ran Valgrind and got this:
=20
valgrind: the 'impossible' happened:
Killed by fatal signal
=3D=3D4019=3D=3D at 0x8000D55FA: disInstr_AMD64_WRK (toIR.c:7809)
=3D=3D4019=3D=3D by 0x8000E5492: disInstr_AMD64 (toIR.c:13376)
=3D=3D4019=3D=3D by 0x80009ED3E: bb_to_IR (bb_to_IR.c:187)
=3D=3D4019=3D=3D by 0x800074B75: LibVEX_Translate (vex_main.c:408)
=3D=3D4019=3D=3D by 0x80003300A: vgPlain_translate =
(libvex_basictypes.h:154)
=3D=3D4019=3D=3D by 0x80004A156: handle_tt_miss (scheduler.c:566)
=3D=3D4019=3D=3D by 0x80004A537: vgPlain_scheduler (scheduler.c:680)
=3D=3D4019=3D=3D by 0x80006A863: vgModuleLocal_thread_wrapper
(syswrap-linux.c:80)
=3D=3D4019=3D=3D by 0x800065753: run_a_thread_NORETURN
(syswrap-amd64-linux.c:144)
=20
sched status:
running_tid=3D1
=20
Thread 1: status =3D VgTs_Runnable
=20
=20
Is this an unsupported instruction? Any suggestions would be greatly
appreciated.
=20
=20
Thanks,
Meir
|
|
From: Michael E L. <me...@co...> - 2005-12-09 02:24:35
|
Thanks for the help...I was passing it through mkIRExpr_HWord() already,=20
which is why I couldn't understand why things weren't working.
The issue was that fnname is a local automatic var and keeps being=20
overwritten as BB's are instrumented, so I'm guessing the registered
instrumentation kept referring to the wrong stuff... I just made it global=
=20
and it seems to work fine.
Cheers,
Michael
On Fri, 9 Dec 2005, Julian Seward wrote:
>
> The args to mkIRExprVec_N need themselves to be IRExpr*s. So you
> need to promote your pointers to that:
>
> mkIRExprVec_1( IRExpr_Const(IRConst_U32(W))) on a 32-bit machine,or
> mkIRExprVec_1(IRExpr_Const(IRConst_U64(W))) on a 64-bit target. I think
> mkIRExpr_HWord does the word size and IRExpr_Const steps for you, so
> you should be able to do
>
> mkIExprVec_1( mkIRExpr_HWord(W) )
>
> J
>
>
> On Friday 09 December 2005 01:40, Michael E Locasto wrote:
>> I should clarify that lu_instrument() is the instrumentation function
>> (like lk_instrument() for lackey). I'm also working with the current
>> source from svn.
>>
>> On Thu, 8 Dec 2005, Michael E Locasto wrote:
>>> Hi folks,
>>>
>>> I searched the mailing list for "unsafeIRDirty_0_N" and "mkIRExprVec" b=
ut
>>> didn't come up with any hits.
>>>
>>> I'm attempting to call a helper function from within lu_instrument() by
>>> using unsafeIRDirty_0_N(). I'd like to pass a character array to the
>>> helper function. I am converting the character array to an IRExpr** by
>>> invoking mkIRExprVec_1() but when the data gets to the helper function,
>>> it is garbled (looks like random chunks of mem). When I pass in a strin=
g
>>> literal (e.g., "foobar" below), it gets to the helper function just fin=
e.
>>>
>>> I looked at the implementation of mkIRExpr_HWord() and I'm guessing tha=
t
>>> it is expecting some kind of constant for the value of 'hw' ... none of
>>> the other types seems to be relevant.
>>>
>>> I can call my helper function directly, but this obviously doesn't
>>> register it to 'instrument' the code...
>>>
>>> Code below...any advice from those with more experience developing a to=
ol
>>> for VG is much appreciated.
>>>
>>> Cheers,
>>> Michael
>>>
>>> ---
>>>
>>> //fnname is a local automatic Char array of size 100 (as defined in //
>>> lackey's lu_instrument())
>>>
>>> if(VG_(get_fnname_if_entry)(st->Ist.IMark.addr,
>>> fnname, sizeof(fnname)))
>>> {
>>> IRExpr** argv;
>>> argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)fnname));
>>> //argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)"foobar"));
>>> di =3D unsafeIRDirty_0_N( 0, "add_a_function_call",
>>> &add_a_function_call,
>>> argv);
>>> addStmtToIRBB( bb, IRStmt_Dirty(di) );
>>> }
>>>
>>> when this code is invoked, my helper gets garbage for the function name=
s.
>>> For example:
>>>
>>> ...
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [] called 92 times.
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [P=EF=BF=BD=EF=BF=BD@=EF=BF=BD=EF=
=BF=BD=EF=BF=BDlGb=EF=BF=BDlGb=EF=BFtime.
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [H=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BDlGb=EF=BF=BDlGbtime.
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [=EF=BF=BD=EF=BF=BDL=EF=BF=BD=EF=BF=
=BD=EF=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF time.
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [=D8=B6=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtimes.
>>> =3D=3D9048=3D=3D ;LUG_OUT; function [=D4=B8=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtime.
>>> ...
>>>
>>> when i replace fnname with a string literal, the data is fine:
>>>
>>> ...
>>> =3D=3D10328=3D=3D ;LUG_OUT; function [foobar] called 1,416 times.
>>> ...
>>>
>>> but that's not the kind of result I'm aiming for :)
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op?k
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> |
|
From: Julian S. <js...@ac...> - 2005-12-09 01:57:57
|
The args to mkIRExprVec_N need themselves to be IRExpr*s. So you
need to promote your pointers to that:
mkIRExprVec_1( IRExpr_Const(IRConst_U32(W))) on a 32-bit machine,or
mkIRExprVec_1(IRExpr_Const(IRConst_U64(W))) on a 64-bit target. I think
mkIRExpr_HWord does the word size and IRExpr_Const steps for you, so
you should be able to do=20
mkIExprVec_1( mkIRExpr_HWord(W) )
J
On Friday 09 December 2005 01:40, Michael E Locasto wrote:
> I should clarify that lu_instrument() is the instrumentation function
> (like lk_instrument() for lackey). I'm also working with the current
> source from svn.
>
> On Thu, 8 Dec 2005, Michael E Locasto wrote:
> > Hi folks,
> >
> > I searched the mailing list for "unsafeIRDirty_0_N" and "mkIRExprVec" b=
ut
> > didn't come up with any hits.
> >
> > I'm attempting to call a helper function from within lu_instrument() by
> > using unsafeIRDirty_0_N(). I'd like to pass a character array to the
> > helper function. I am converting the character array to an IRExpr** by
> > invoking mkIRExprVec_1() but when the data gets to the helper function,
> > it is garbled (looks like random chunks of mem). When I pass in a string
> > literal (e.g., "foobar" below), it gets to the helper function just fin=
e.
> >
> > I looked at the implementation of mkIRExpr_HWord() and I'm guessing that
> > it is expecting some kind of constant for the value of 'hw' ... none of
> > the other types seems to be relevant.
> >
> > I can call my helper function directly, but this obviously doesn't
> > register it to 'instrument' the code...
> >
> > Code below...any advice from those with more experience developing a to=
ol
> > for VG is much appreciated.
> >
> > Cheers,
> > Michael
> >
> > ---
> >
> > //fnname is a local automatic Char array of size 100 (as defined in //
> > lackey's lu_instrument())
> >
> > if(VG_(get_fnname_if_entry)(st->Ist.IMark.addr,
> > fnname, sizeof(fnname)))
> > {
> > IRExpr** argv;
> > argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)fnname));
> > //argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)"foobar"));
> > di =3D unsafeIRDirty_0_N( 0, "add_a_function_call",
> > &add_a_function_call,
> > argv);
> > addStmtToIRBB( bb, IRStmt_Dirty(di) );
> > }
> >
> > when this code is invoked, my helper gets garbage for the function name=
s.
> > For example:
> >
> > ...
> > =3D=3D9048=3D=3D ;LUG_OUT; function [] called 92 times.
> > =3D=3D9048=3D=3D ;LUG_OUT; function [P=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=
=BD@=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDlGb=C3=AF=C2=BF=
=C2=BDlGb=C3=AF=C2=BFtime.
> > =3D=3D9048=3D=3D ;LUG_OUT; function [H=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=
=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=
lGb=C3=AF=C2=BF=C2=BDlGbtime.
> > =3D=3D9048=3D=3D ;LUG_OUT; function [=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=
=BDL=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDlGb=C3=AF=C2=BF=
=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF time.
> > =3D=3D9048=3D=3D ;LUG_OUT; function [=C3=98=C2=B6=C3=AF=C2=BF=C2=BD=C3=
=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDlGb=C3=AF=C2=BF=C2=BD=C3=
=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDtimes.
> > =3D=3D9048=3D=3D ;LUG_OUT; function [=C3=94=C2=B8=C3=AF=C2=BF=C2=BD=C3=
=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDlGb=C3=AF=C2=BF=C2=BD=C3=
=AF=C2=BF=C2=BD=C3=AF=C2=BF=C2=BDtime.
> > ...
> >
> > when i replace fnname with a string literal, the data is fine:
> >
> > ...
> > =3D=3D10328=3D=3D ;LUG_OUT; function [foobar] called 1,416 times.
> > ...
> >
> > but that's not the kind of result I'm aiming for :)
|
|
From: Michael E L. <me...@co...> - 2005-12-09 01:40:49
|
I should clarify that lu_instrument() is the instrumentation function=20
(like lk_instrument() for lackey). I'm also working with the current=20
source from svn.
On Thu, 8 Dec 2005, Michael E Locasto wrote:
>
> Hi folks,
>
> I searched the mailing list for "unsafeIRDirty_0_N" and "mkIRExprVec" but
> didn't come up with any hits.
>
> I'm attempting to call a helper function from within lu_instrument() by
> using unsafeIRDirty_0_N(). I'd like to pass a character array to the
> helper function. I am converting the character array to an IRExpr** by
> invoking mkIRExprVec_1() but when the data gets to the helper function, i=
t
> is garbled (looks like random chunks of mem). When I pass in a string
> literal (e.g., "foobar" below), it gets to the helper function just fine.
>
> I looked at the implementation of mkIRExpr_HWord() and I'm guessing that
> it is expecting some kind of constant for the value of 'hw' ... none of
> the other types seems to be relevant.
>
> I can call my helper function directly, but this obviously doesn't regist=
er=20
> it to 'instrument' the code...
>
> Code below...any advice from those with more experience developing a tool
> for VG is much appreciated.
>
> Cheers,
> Michael
>
> ---
>
> //fnname is a local automatic Char array of size 100 (as defined in //=20
> lackey's lu_instrument())
>
> if(VG_(get_fnname_if_entry)(st->Ist.IMark.addr,
> fnname, sizeof(fnname)))
> {
> IRExpr** argv;
> argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)fnname));
> //argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)"foobar"));
> di =3D unsafeIRDirty_0_N( 0, "add_a_function_call",
> &add_a_function_call,
> argv);
> addStmtToIRBB( bb, IRStmt_Dirty(di) );
> }
>
> when this code is invoked, my helper gets garbage for the function names.=
For=20
> example:
>
> ...
> =3D=3D9048=3D=3D ;LUG_OUT; function [] called 92 times.
> =3D=3D9048=3D=3D ;LUG_OUT; function [P=EF=BF=BD=EF=BF=BD@=EF=BF=BD=EF=BF=
=BD=EF=BF=BDlGb=EF=BF=BDlGb=EF=BFtime.
> =3D=3D9048=3D=3D ;LUG_OUT; function [H=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=EF=BF=BD=EF=BF=BDlGb=EF=BF=BDlGbtime.
> =3D=3D9048=3D=3D ;LUG_OUT; function [=EF=BF=BD=EF=BF=BDL=EF=BF=BD=EF=BF=
=BD=EF=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF time.
> =3D=3D9048=3D=3D ;LUG_OUT; function [=D8=B6=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtimes.
> =3D=3D9048=3D=3D ;LUG_OUT; function [=D4=B8=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtime.
> ...
>
> when i replace fnname with a string literal, the data is fine:
>
> ...
> =3D=3D10328=3D=3D ;LUG_OUT; function [foobar] called 1,416 times.
> ...
>
> but that's not the kind of result I'm aiming for :) |
|
From: Michael E L. <me...@co...> - 2005-12-09 01:29:50
|
Hi folks,
I searched the mailing list for "unsafeIRDirty_0_N" and "mkIRExprVec" but
didn't come up with any hits.
I'm attempting to call a helper function from within lu_instrument() by
using unsafeIRDirty_0_N(). I'd like to pass a character array to the
helper function. I am converting the character array to an IRExpr** by
invoking mkIRExprVec_1() but when the data gets to the helper function, it
is garbled (looks like random chunks of mem). When I pass in a string
literal (e.g., "foobar" below), it gets to the helper function just fine.
I looked at the implementation of mkIRExpr_HWord() and I'm guessing that
it is expecting some kind of constant for the value of 'hw' ... none of
the other types seems to be relevant.
I can call my helper function directly, but this obviously doesn't=20
register it to 'instrument' the code...
Code below...any advice from those with more experience developing a tool
for VG is much appreciated.
Cheers,
Michael
---
//fnname is a local automatic Char array of size 100 (as defined in=20
// lackey's lu_instrument())
if(VG_(get_fnname_if_entry)(st->Ist.IMark.addr,
fnname, sizeof(fnname)))
{
IRExpr** argv;
argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)fnname));
//argv =3D mkIRExprVec_1(mkIRExpr_HWord((HWord)"foobar"));
di =3D unsafeIRDirty_0_N( 0, "add_a_function_call",
&add_a_function_call,
argv);
addStmtToIRBB( bb, IRStmt_Dirty(di) );
}
when this code is invoked, my helper gets garbage for the function names.=
=20
For example:
=2E..
=3D=3D9048=3D=3D ;LUG_OUT; function [] called 92 times.
=3D=3D9048=3D=3D ;LUG_OUT; function [P=EF=BF=BD=EF=BF=BD@=EF=BF=BD=EF=BF=BD=
=EF=BF=BDlGb=EF=BF=BDlGb=EF=BFtime.
=3D=3D9048=3D=3D ;LUG_OUT; function [H=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=
=EF=BF=BD=EF=BF=BDlGb=EF=BF=BDlGbtime.
=3D=3D9048=3D=3D ;LUG_OUT; function [=EF=BF=BD=EF=BF=BDL=EF=BF=BD=EF=BF=BD=
=EF=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF time.
=3D=3D9048=3D=3D ;LUG_OUT; function [=D8=B6=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtimes.
=3D=3D9048=3D=3D ;LUG_OUT; function [=D4=B8=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=
=BF=BDlGb=EF=BF=BD=EF=BF=BD=EF=BF=BDtime.
=2E..
when i replace fnname with a string literal, the data is fine:
=2E..
=3D=3D10328=3D=3D ;LUG_OUT; function [foobar] called 1,416 times.
=2E..
but that's not the kind of result I'm aiming for :) |
|
From: Yeshurun, M. <mei...@in...> - 2005-12-08 20:28:49
|
You're probably wondering about the title :) =20 The first try was with Valgrind 3.1.0 - the result was a bizarre mixture of Valgrind's and my application's output which I couldn't understand. =20 Then I tried valgrind 3.0.0 and got the message below. After looking at the message below, I was able to see that this was probably the same error message that valgrind 3.1.0 wrote. =20 ________________________________ From: val...@li... [mailto:val...@li...] On Behalf Of Yeshurun, Meir Sent: Thursday, December 08, 2005 10:21 PM To: val...@li... Subject: [Valgrind-users] Valgrind log file corruption =20 Hi, =20 I ran Valgrind and got this: =20 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D4019=3D=3D at 0x8000D55FA: disInstr_AMD64_WRK (toIR.c:7809) =3D=3D4019=3D=3D by 0x8000E5492: disInstr_AMD64 (toIR.c:13376) =3D=3D4019=3D=3D by 0x80009ED3E: bb_to_IR (bb_to_IR.c:187) =3D=3D4019=3D=3D by 0x800074B75: LibVEX_Translate (vex_main.c:408) =3D=3D4019=3D=3D by 0x80003300A: vgPlain_translate = (libvex_basictypes.h:154) =3D=3D4019=3D=3D by 0x80004A156: handle_tt_miss (scheduler.c:566) =3D=3D4019=3D=3D by 0x80004A537: vgPlain_scheduler (scheduler.c:680) =3D=3D4019=3D=3D by 0x80006A863: vgModuleLocal_thread_wrapper (syswrap-linux.c:80) =3D=3D4019=3D=3D by 0x800065753: run_a_thread_NORETURN (syswrap-amd64-linux.c:144) =20 sched status: running_tid=3D1 =20 Thread 1: status =3D VgTs_Runnable =20 =20 Is this an unsupported instruction? Any suggestions would be greatly appreciated. =20 =20 Thanks, Meir |
|
From: Yeshurun, M. <mei...@in...> - 2005-12-08 20:21:58
|
Hi, =20 I ran Valgrind and got this: =20 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D4019=3D=3D at 0x8000D55FA: disInstr_AMD64_WRK (toIR.c:7809) =3D=3D4019=3D=3D by 0x8000E5492: disInstr_AMD64 (toIR.c:13376) =3D=3D4019=3D=3D by 0x80009ED3E: bb_to_IR (bb_to_IR.c:187) =3D=3D4019=3D=3D by 0x800074B75: LibVEX_Translate (vex_main.c:408) =3D=3D4019=3D=3D by 0x80003300A: vgPlain_translate = (libvex_basictypes.h:154) =3D=3D4019=3D=3D by 0x80004A156: handle_tt_miss (scheduler.c:566) =3D=3D4019=3D=3D by 0x80004A537: vgPlain_scheduler (scheduler.c:680) =3D=3D4019=3D=3D by 0x80006A863: vgModuleLocal_thread_wrapper (syswrap-linux.c:80) =3D=3D4019=3D=3D by 0x800065753: run_a_thread_NORETURN (syswrap-amd64-linux.c:144) =20 sched status: running_tid=3D1 =20 Thread 1: status =3D VgTs_Runnable =20 =20 Is this an unsupported instruction? Any suggestions would be greatly appreciated. =20 =20 Thanks, Meir |
|
From: Vikram N. <vik...@ya...> - 2005-12-08 07:31:40
|
Dirk Mueller <dmuell <at> gmx.net> writes: > > On Wednesday 07 December 2005 13:29, Mads Jepsen wrote: > > Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin > > directory. Which is the same relative path as x86-linux. > it should have been installed in ../lib64/... > > Dirk Hi, I am also facing a similar problem. I renamed lib to lib64 but it still does not work. Now, Memcheck is at ../lib64/valgrind/amd64-linux/ relative to bin folder. Could you please let me know it anything else needs to be changed? Thanks, Vikram |
|
From: Dirk M. <dm...@gm...> - 2005-12-07 13:34:14
|
On Wednesday 07 December 2005 13:29, Mads Jepsen wrote: > Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin > directory. Which is the same relative path as x86-linux. it should have been installed in ../lib64/... Dirk |
|
From: Mads J. <mad...@mo...> - 2005-12-07 12:30:24
|
Hi I have tried to install valgrind to a non default path: ./configure --prefix some-path make all make install There is no problem in the x86 instalation, but for the amd64-linux I get the following error message: valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No such file or directory Memcheck is located at ../lib/valgrind/amd64-linux/ relative to the bin directory. Which is the same relative path as x86-linux. Have any of you had simulare problems ? best regards, Mads |
|
From: Peter H. <pe...@se...> - 2005-12-06 22:44:25
|
Thanks for your response, Nick. I found that the functions that set the tags. In irdefs.c, there are IRStmt constructors for each of the IRStmt tag types (Store, Tmp, etc...) that set them. Like Nick said, these constructors get called in toIr.c. A lot. It would be an extraordinary task to go through all of these occurrences, find the ones that match what we want to keep track of, and add our own tags, so I think we'll pursue using one of the other tools Nick mentioned. Peter Quoting Nicholas Nethercote <nj...@cs...>: > On Tue, 6 Dec 2005, Peter Hornyack wrote: > > > I'm working on an academic research project involving profiling, and we're > > > using the lackey tool that comes with valgrind. We'd like to extend the > tool > > to count more specific instructions, like x86 push and pop, for example. > > > > In lackey, lk_instrument() switches on st->tag, where st is the current > > IRStmt in the basic block; if the tag is Ist_Tmp, it also switches on > > expr->tag. > > > > Question 1: from the possible values of the IRStmt and IRExpr tags (those > > currently defined in libvex_ir.h), is it possible to determine whether st > > represents a host push/pop/etc. instruction? I suspect that it's not > > possible, because the information is lost in the VEX translation. > > It's not really possible. Valgrind's IR is deliberately > architecture-neutral so that you can write each tool once and have it work > on all architectures. The downside of this is that you can't really work > with the original instructions. > > You might have more luck with DynamoRIO or Pin, both of which let you > instrument code like Valgrind, but give you access to the original > instruction stream. I think I've seen a Pin tool that counts x86 > instructions. They're also faster if you're doing simple things like > counting instructions. > > > Question 2 (answer me this question and I can probably answer question 1 > > myself): where in the source code are the tags for st set? We've been > trying > > to trace it for a while, but have been unsuccessful so far. If we can find > > > where the tags are set, then we could add any tags we need for the > profiling > > we want to do. > > I think it's VEX/priv/guest-*/toIR.c. > > Nick > |
|
From: Nicholas N. <nj...@cs...> - 2005-12-06 15:48:57
|
On Tue, 6 Dec 2005, Peter Hornyack wrote: > I'm working on an academic research project involving profiling, and we're > using the lackey tool that comes with valgrind. We'd like to extend the tool > to count more specific instructions, like x86 push and pop, for example. > > In lackey, lk_instrument() switches on st->tag, where st is the current > IRStmt in the basic block; if the tag is Ist_Tmp, it also switches on > expr->tag. > > Question 1: from the possible values of the IRStmt and IRExpr tags (those > currently defined in libvex_ir.h), is it possible to determine whether st > represents a host push/pop/etc. instruction? I suspect that it's not > possible, because the information is lost in the VEX translation. It's not really possible. Valgrind's IR is deliberately architecture-neutral so that you can write each tool once and have it work on all architectures. The downside of this is that you can't really work with the original instructions. You might have more luck with DynamoRIO or Pin, both of which let you instrument code like Valgrind, but give you access to the original instruction stream. I think I've seen a Pin tool that counts x86 instructions. They're also faster if you're doing simple things like counting instructions. > Question 2 (answer me this question and I can probably answer question 1 > myself): where in the source code are the tags for st set? We've been trying > to trace it for a while, but have been unsuccessful so far. If we can find > where the tags are set, then we could add any tags we need for the profiling > we want to do. I think it's VEX/priv/guest-*/toIR.c. Nick |
|
From: Peter H. <pe...@se...> - 2005-12-06 07:17:41
|
I'm working on an academic research project involving profiling, and we're using the lackey tool that comes with valgrind. We'd like to extend the tool to count more specific instructions, like x86 push and pop, for example. In lackey, lk_instrument() switches on st->tag, where st is the current IRStmt in the basic block; if the tag is Ist_Tmp, it also switches on expr->tag. Question 1: from the possible values of the IRStmt and IRExpr tags (those currently defined in libvex_ir.h), is it possible to determine whether st represents a host push/pop/etc. instruction? I suspect that it's not possible, because the information is lost in the VEX translation. Question 2 (answer me this question and I can probably answer question 1 myself): where in the source code are the tags for st set? We've been trying to trace it for a while, but have been unsuccessful so far. If we can find where the tags are set, then we could add any tags we need for the profiling we want to do. Maybe the answer to this question isn't as simple as I think it might be; if I'm misunderstanding any of this, please correct me. We're working with the source code for valgrind 3.1.0. Thanks, Peter |