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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(25) |
2
(24) |
3
(6) |
4
(2) |
5
(4) |
|
6
(5) |
7
(19) |
8
(18) |
9
(7) |
10
(13) |
11
(6) |
12
(8) |
|
13
(4) |
14
(5) |
15
(8) |
16
(4) |
17
(2) |
18
(2) |
19
(6) |
|
20
(14) |
21
(6) |
22
(20) |
23
(13) |
24
(3) |
25
(5) |
26
|
|
27
(4) |
28
(7) |
29
(14) |
30
(6) |
|
|
|
|
From: Tom H. <to...@co...> - 2005-11-12 18:44:15
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> On 11/12/05, Tom Hughes <to...@co...> wrote:
>
> > Actually that address does look about right for the stack we
> > allocate - it's slightly higher on my machine but not much.
> >
> > Can you run with --trace-signals=yes and see what it says?
>
> $ /usr/local/valgrind-3.0.svn/bin/valgrind -q --trace-signals=yes ./a.out
> --30170-- Max kernel-supported signal is 64
> --30170-- signal 11 arrived ... si_code=196609, EIP=0x4EACC1EC,
> eip=0x477DC95
> --30170-- SIGSEGV: si_code=196609 faultaddr=0xFEF88EC0 tid=1 ESP=0xFEF88EC0
> seg=0xFE78A000-0xFEF88FFF
The si_code value is bogus (0x30001) so it doesn't realise it
needs to extend the stack. This is the bug we discussed on the
developer list last night but we thought it was a ppc specific
bug. Obviously it affects all 2.4 kernels of a certain vintage.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-11-12 17:57:33
|
On 11/12/05, Tom Hughes <to...@co...> wrote: > > > Actually that address does look about right for the stack we > allocate - it's slightly higher on my machine but not much. > > Can you run with --trace-signals=3Dyes and see what it says? $ /usr/local/valgrind-3.0.svn/bin/valgrind -q --trace-signals=3Dyes ./a.out --30170-- Max kernel-supported signal is 64 --30170-- signal 11 arrived ... si_code=3D196609, EIP=3D0x4EACC1EC, eip=3D0x477DC95 --30170-- SIGSEGV: si_code=3D196609 faultaddr=3D0xFEF88EC0 tid=3D1 ESP=3D0x= FEF88EC0 seg=3D0xFE78A000-0xFEF88FFF --30170-- delivering signal 11 (SIGSEGV):196609 to thread 1 --30170-- delivering 11 (code 196609) to default handler; action: terminate+core =3D=3D30170=3D=3D =3D=3D30170=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D30170=3D=3D at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2= .so>) =3D=3D30170=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D30170=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D30170=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) Segmentation fault > Any idea roughly what sizes of environment cause a problem? $ env | wc -c 2771 $ PATH=3D$PATH:$PATH env | wc -c 3342 $ PATH=3D$PATH:$PATH:$PATH env | wc -c 3913 Cheers, |
|
From: Tom H. <to...@co...> - 2005-11-12 17:49:28
|
In message <7c7...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <2a2...@ma...>
> Paul Pluzhnikov <ppl...@gm...> wrote:
>
> > Hmm; %esp is just below the stack page, and the kernel refuses to grow
> > stack?
>
> That's the original kernel supplied stack though isn't it? and we
> shouldn't be giving that to the client program - we allocate a new
> stack for that.
Actually that address does look about right for the stack we
allocate - it's slightly higher on my machine but not much.
Can you run with --trace-signals=yes and see what it says?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-12 17:41:05
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> ==29870== Process terminating with default action of signal 11 (SIGSEGV)
> ==29870== at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http://2.3.2.so>
> )
> ==29870== by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870==
>
>
> Is that using glibc-2.3.2-95.20.i686.rpm or a later update?
>
>
> $ rpm -qf /lib/ld-2.3.2.so <http://2.3.2.so>
> glibc-2.3.2-95.20
>
> Also, I tried to see if I can debug core. Default "ulimit -c" is zero;
> setting it to unlimited changes the message:
> ==29946== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
>
> but no core* is produced :(
That is a core dump of the client program so will be a vgcore* file.
> Attaching to program: /proc/30077/fd/1014, process 30077
> 0x4eacc1ec in ?? ()
> (gdb) x/i $pc
> 0x4eacc1ec: mov %ecx,(%esp)
> (gdb) x/x $esp
> 0xfef12ec0: Cannot access memory at address 0xfef12ec0
> (gdb) shell cat /proc/30077/maps
> 0000000004000000-000000000435a000 rwxp 0000000000000000 00:00 0
> 000000000435a000-000000000435c000 ---p 000000000035a000 00:00 0
> 000000000435c000-000000000436c000 rwxp 000000000035c000 00:00 0
> 000000000436c000-000000000436e000 ---p 000000000036c000 00:00 0
> 000000000436e000-000000000437e000 rwxp 0000000000000000 00:00 0
> 0000000004577000-0000000005f69000 rwxp 0000000000000000 00:00 0
> 0000000008048000-0000000008049000 r-xp 0000000000000000 03:41 200779
> /tmp/a.out
> 0000000008049000-000000000804a000 rwxp 0000000000000000 03:41 200779
> /tmp/a.out
> 000000000804a000-000000000804b000 rwxp 0000000000000000 00:00 0
> 000000004eacb000-000000004eae0000 r-xp 0000000000000000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 000000004eae0000-000000004eae1000 rwxp 0000000000014000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 0000000070000000-0000000070135000 r-xp 0000000000000000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070135000-0000000070136000 rwxp 0000000000135000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070136000-00000000707c2000 rwxp 0000000000000000 00:00 0
> 00000000fef13000-00000000fef14000 rwxp 0000000000000000 00:00 0
> 00000000fff13000-00000000ffffe000 rw-p fffffffffff16000 00:00 0
> (gdb) quit
> ==30076==
> ==30076== Debugger has detached. Valgrind regains control. We continue.
> ==30076==
> ==30076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==30076== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==30076== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==30076== For counts of detected errors, rerun with: -v
> ==30076== No malloc'd blocks -- no leaks are possible.
> Segmentation fault
>
> Hmm; %esp is just below the stack page, and the kernel refuses to grow
> stack?
That's the original kernel supplied stack though isn't it? and we
shouldn't be giving that to the client program - we allocate a new
stack for that.
> In fact, increasing environment size moves the place where it coredumps,
> and invreasing it sufficiently makes it run:
Interesting. I'll have a play with that. Any idea roughly what
sizes of environment cause a problem?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-11-12 09:53:18
|
On 11/7/05, Tom Hughes <to...@co...> wrote:
>
> The SVN version of valgrind now has support for running 32 bit x86
Just checked out: VG 5092, VEX 1450
Please do try it out if you want and let us know on the mailing lists
> or by filing a bug on the bug tracker if you encounter any problems.
64-bit version appears to work fine, but 32-bit exe crashes right away:
$ echo "int main() { return 0; }" > junk.c
$ gcc -m32 -g junk.c && ./a.out && /usr/local/valgrind-3.0.svn/bin/valgrind
-v ./a.out
=3D=3D26864=3D=3D Memcheck, a memory error detector.
=3D=3D26864=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D26864=3D=3D Using LibVEX rev 1450, a library for dynamic binary trans=
lation.
=3D=3D26864=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
=3D=3D26864=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation
framework.
=3D=3D26864=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D26864=3D=3D
--26864-- Valgrind library directory: /usr/local/valgrind-3.0.svn
/lib/valgrind
--26864-- Command line
--26864-- ./a.out
--26864-- Startup, with flags:
--26864-- -v
--26864-- Contents of /proc/version:
--26864-- Linux version 2.4.21-15.ELsmp (bhc...@th...)
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)) #1 SMP Thu Apr 22
00:09:01 EDT 2004
--26864-- Reading syms from /tmp/a.out (0x8048000)
--26864-- Reading syms from /lib/ld-2.3.2.so <http://2.3.2.so> (0x4EACB000)
--26864-- Reading syms from
/usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
(0x70000000)
--26864-- object doesn't have a dynamic symbol table
--26864-- Reading suppressions file: /usr/local/valgrind-3.0.svn
/lib/valgrind/default.supp
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D Process terminating with default action of signal 11 (SIG=
SEGV)
=3D=3D26864=3D=3D at 0x4EACE253: process_envvars (in /lib/ld-2.3.2.so<http:=
//2.3.2.so>
)
=3D=3D26864=3D=3D by 0x4EACC208: dl_main (in /lib/ld-2.3.2.so <http://2.3.2=
.so>)
=3D=3D26864=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http=
://2.3.2.so>
)
=3D=3D26864=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3=
.2.so>)
=3D=3D26864=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>=
)
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 fr=
om 0)
=3D=3D26864=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D26864=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D No malloc'd blocks -- no leaks are possible.
--26864-- memcheck: sanity checks: 0 cheap, 1 expensive
--26864-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--26864-- memcheck: auxmaps: 0 searches, 0 comparisons
--26864-- memcheck: secondaries: 5 issued (320k, 0M)
--26864-- memcheck: secondaries: 1 accessible and distinguished (64k, 0M)
--26864-- tt/tc: 178 tt lookups requiring 177 probes
--26864-- tt/tc: 178 fast-cache updates, 2 flushes
--26864-- translate: new 89 (1,981 -> 28,781; ratio 145:10) [0 scs]
--26864-- translate: dumped 0 (0 -> ??)
--26864-- translate: discarded 0 (0 -> ??)
--26864-- scheduler: 190 jumps (bb entries).
--26864-- scheduler: 0/92 major/minor sched events.
--26864-- sanity: 1 cheap, 1 expensive checks.
--26864-- exectx: 30,011 lists, 0 contexts (avg 0 per list)
--26864-- exectx: 0 searches, 0 full compares (0 per 1000)
--26864-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll
Segmentation fault
$
This is unmodified
Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
|
|
From: Julian S. <js...@ac...> - 2005-11-11 21:23:32
|
coregrind/m_signals.c line 1566: change
if (info->si_code == 1 /* SEGV_MAPERR */
to
if ((0xFFFF & info->si_code) == 1 /* SEGV_MAPERR */
rebuild and see if it helps.
J
On Friday 11 November 2005 15:42, Lev Iserovich wrote:
> Hi Julian,
>
> I found that place (in dispatch-ppc32.S) which sets the FPU and AltiVec
> to default modes,
> and commented out those instructions.
> Now I get a bit further in the process - but any program I run SEGV's.
> I did a gdb, and got the following disassembly at the SEGV point :
>
> 0x71401bd0: bctrl
> 0x71401bd4: stw r16,0(r17) <--- SEGV here (beginning
> of function?)
> 0x71401bd8: lwz r15,1852(r31)
> 0x71401bdc: lwz r16,900(r31)
> 0x71401be0: stw r15,952(r31)
> 0x71401be4: stw r16,0(r31)
> 0x71401be8: lis r18,4487
> 0x71401bec: ori r18,r18,52804
> 0x71401bf0: stw r18,896(r31)
> 0x71401bf4: addi r18,r17,144
> 0x71401bf8: lwz r21,112(r31)
> 0x71401bfc: mr r3,r18
> 0x71401c00: lwz r22,1064(r31)
> 0x71401c04: mr r4,r22
> 0x71401c08: lis r12,28976
> 0x71401c0c: ori r12,r12,52048
> 0x71401c10: mtctr r12
> 0x71401c14: bctrl
>
> Looks like some generated code, because the address is the same from any
> program I run.
>
> Any suggestions, or does this look to complicated to be easily fixable?
>
> --Lev
>
> Julian Seward wrote:
> >It turns out you are the fourth person we know of to try V on
> >a ppc405 or similar. I believe the root problem is the 405 does
> >not support floating point, and so the system SIGILLs when it
> >attempts to set the FPU control word before running instrumented
> >code.
> >
> >I finally have access to such a system and so will look into
> >whether there is an easy fix, in the next day or so.
> >
> >J
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Julian S. <ju...@va...> - 2005-11-11 18:14:58
|
On Friday 11 November 2005 17:59, Eduardo Munoz wrote: > Can somebody tell me an estimated dates for the following: I need to > make some projects decision based on these dates. > This is for valgrind from the current development line (valgrind -3.1.SVN) > > 1. Support( or fix) for 4XX boards or ppcnf (ppc no floating point) > systems. Currently under investigation. > 2. Support for Helgrind tool. 2-3 months if you are lucky. There are some difficult design problems to overcome first. > 3. Support for addrcheck tool There is no plan to fix addrcheck at the present time; however the breakage is fairly minor, on the order of a week or two weeks work to fix. J |
|
From: Eduardo M. <ea...@us...> - 2005-11-11 17:55:17
|
Can somebody tell me an estimated dates for the following: I need to=20 make some projects decision based on these dates. This is for valgrind from the current development line (valgrind -3.1.SVN) 1. Support( or fix) for 4XX boards or ppcnf (ppc no floating point)=20 systems. 2. Support for Helgrind tool. 3. Support for addrcheck tool Regards, Eduardo A. Mu=F1oz |
|
From: Lev I. <lis...@ci...> - 2005-11-11 15:41:00
|
Hi Julian, I found that place (in dispatch-ppc32.S) which sets the FPU and AltiVec to default modes, and commented out those instructions. Now I get a bit further in the process - but any program I run SEGV's. I did a gdb, and got the following disassembly at the SEGV point : 0x71401bd0: bctrl 0x71401bd4: stw r16,0(r17) <--- SEGV here (beginning of function?) 0x71401bd8: lwz r15,1852(r31) 0x71401bdc: lwz r16,900(r31) 0x71401be0: stw r15,952(r31) 0x71401be4: stw r16,0(r31) 0x71401be8: lis r18,4487 0x71401bec: ori r18,r18,52804 0x71401bf0: stw r18,896(r31) 0x71401bf4: addi r18,r17,144 0x71401bf8: lwz r21,112(r31) 0x71401bfc: mr r3,r18 0x71401c00: lwz r22,1064(r31) 0x71401c04: mr r4,r22 0x71401c08: lis r12,28976 0x71401c0c: ori r12,r12,52048 0x71401c10: mtctr r12 0x71401c14: bctrl Looks like some generated code, because the address is the same from any program I run. Any suggestions, or does this look to complicated to be easily fixable? --Lev Julian Seward wrote: >It turns out you are the fourth person we know of to try V on >a ppc405 or similar. I believe the root problem is the 405 does >not support floating point, and so the system SIGILLs when it >attempts to set the FPU control word before running instrumented >code. > >I finally have access to such a system and so will look into >whether there is an easy fix, in the next day or so. > >J > > > |
|
From: Josef W. <Jos...@gm...> - 2005-11-11 11:27:35
|
On Friday 11 November 2005 05:05, you wrote: > On Wed, 9 Nov 2005, Josef Weidendorfer wrote: > Hi, > > I am running Callgrind with the options -v --log-file=summary --simulate-cache=yes > --simulate-hwpref=yes --cacheuse=yes. The summary log file contains the > lines: > > Prefetch Up: 0 > Prefetch Down: 0 Oh, someone which is using the more advanced (and probably not that much tested), code! Very good. It would be nice if you can tell me if these features are useful for you. You can not use --simulate-hwpref=yes and --cacheuse=yes at once. This is separated simulator code. I will change the code to give out a warning regarding this, thanks. If I do e.g. callgrind -v --simulate-hwpref=yes ls This option also switches on cache simulation. I get --12922-- Prefetch Up: 1507 --12922-- Prefetch Down: 36 so I think this still works fine. > What do these lines mean? From what I understand, --simulate-hwpref=yes > simulates a hardware prefetcher, as is found in the Intel Pentium 4 > processor. Yes. The P4 (and P-M) automatically detects upward and downward streaming, stopping at 4kB boundaries (streams on virtual addresses get a disrupted stream of physical addresses at 4kB boundaries because of VM). A nice thing is that the Pentium-M has hardware performance counters exact for the Prefetch/Up and Prefetch/Down events, i.e. you can observe the hardware prefetcher on the Pentium-M in action by using OProfile/Perfex/PAPI, and compare the results with that from Callgrind. By using --simulate-hwpref=yes I add this heuristic, and presume that every line loaded by the hardware prefetcher will give a hit when accessed later on. Note that this is not always the case: the real access could come that early that you still would get a miss in reality, even if the hardware prefetcher has catched the line. Unfortunately, callgrind has no way to get a simulated wall clock time, which would be needed to detect such cases. So callgrind --simulate-hwpref will give the best case possible for the prefetcher. In reality, it is between the results without and with this option. The usage is to compare results with and without the prefetcher. For functions where you see a big difference, the prefetcher is working quite good, i.e. any microoptimizations to bring down the usual callgrind results (without prefetcher) will not lead to any real improvements. But in the code regions, where the results are not really different, you see that the prefetching heuristic of the P4/PM is not working, and you can try to add software prefetch instructions (or otherwise change the code). A drawback is that callgrind does not take software prefetch instructions into account, as Valgrind does not feed these instructions to the tool, but ignores them. But if there really are users for this simulator enhancement, we can try to include them into VG core (e.g. cachegrind). To make the comparision of the two runs more easy, I should include a compare mode in KCachegrind. > Also, does --cacheuse=yes collect cache line utilization statistics i.e. > what percentage of a line is utilized after being brought into cache and > before being evicted from the cache? Where can this information viewed? Yes. The number of bytes never used in a cache line will be attributed to the instruction which triggered the load. This is event SpLoss1 (for L1) and more important SpLoss2 (for L2). The full amount of bytes loaded by an instruction is given by the number of L1 or L2 misses this instruction gets attributed, multiplied with the cache line size. In KCachegrind, add new derived events with the formula "64 L1m" and "64 L2m" to directly get the numbers to compare. You can view this information with KCachegrind. Unfortunately, there was a a hardcoded maximum of 10 event types in KCachegrind found till KDE 3.4.x. And --cacheuse=yes gives you 12 event types, leading to a load error. This changes in the version in KDE 3.5, or use the newest one from the website (kcachegrind.sf.net). Theoretically, callgrind_annotate should be able to show these results, too. For it to cope with the format, you have to additionally provide --compress-pos=no --compress-strings=no on the callgrind line. Even then, it fails with Line xxxx: summary event and total event mismatch Oh yeah, it is time to provide a better command line tool... Josef > > Thanks, > Aniruddha |
|
From: Aniruddha S. <sh...@cs...> - 2005-11-11 04:05:14
|
On Wed, 9 Nov 2005, Josef Weidendorfer wrote: Hi, I am running Callgrind with the options -v --log-file=summary --simulate-cache=yes --simulate-hwpref=yes --cacheuse=yes. The summary log file contains the lines: Prefetch Up: 0 Prefetch Down: 0 What do these lines mean? From what I understand, --simulate-hwpref=yes simulates a hardware prefetcher, as is found in the Intel Pentium 4 processor. Also, does --cacheuse=yes collect cache line utilization statistics i.e. what percentage of a line is utilized after being brought into cache and before being evicted from the cache? Where can this information viewed? Thanks, Aniruddha > On Wednesday 09 November 2005 04:03, you wrote: > > I want to speedup the simulation by specifying that a certain code segment > > not be profiled while the remainder of the code be profiled. > > Ah, you always should say what you want to achieve when asking a question > on the mailing list. > > A speedup can only be achieved by simplified instrumentation. In > Cachegrind/Callgrind, this would mean that the cache simulator is not > feeded with the memory access stream. And this would make the whole > cache simulation go wrong. > > So you do not want to change instrumentation with Cachegrind/Callgrind, > if you are interested in any cache misses/hits. > > With Callgrind, the default is to not to do cache simulation. But Callgrind > has an additional slowdown because of call graph tracing. So this is not > the way for a speedup. > > But you can temporarily switch of instrumentation for all the code which is > run. Then, if you switch it on later on, you have to prepared that there > will be cache misses which would not happen in reality. But an approximation > of the real cache state usually should be reached a few million memory accesses > later (depending on the application). Thus, depending on cache size, you will > have a fixed number of cache misses more, but this number disappears in > noise level after some time. > > To start without instrumentation (same as valgrind --tool=none...), start > callgrind with "callgrind --instr-atstart=no ...", and run > a "callgrind_control -i on" afterwards, or use CALLGRIND_START_INSTRUMENTATION() > from $prefix/include/valgrind/callgrind.h to switch instrumentation on > programatically. > > Josef > > > > > Will this > > really speedup the simulation? Does the --toggle-collect=<func> option > > ensure that functions called from within <func> are not profiled? > > > > Cheers, > > Aniruddha > > > > ----- Original Message ----- > > From: "Josef Weidendorfer" <Jos...@gm...> > > To: <val...@li...> > > Sent: Saturday, November 05, 2005 5:04 PM > > Subject: [SPAM] Re: [Valgrind-users] Selective profiling with Cachegrind > > > > > > > On Saturday 05 November 2005 21:19, Aniruddha Shet wrote: > > >> Hi, > > >> > > >> Does Cachegrind allow you to specify that certain functions not be > > >> profiled? > > >> In other words, is there a way to turn on and off profiling in certain > > >> code > > >> segments? > > > > > > Cachegrind gives you self cost of functions, so why not simply ignore the > > > functions in the output you do not want to be profiled? > > > > > > Or check out the callgrind tool and the --toggle-collect=<func> option. > > > It will toggle the collection state when entering or leaving a given > > > function. > > > > > > Josef > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App Server. > > > Download > > > it for free - -and be entered to win a 42" plasma tv or your very own > > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Valgrind-users mailing list > > > Val...@li... > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- ----------------------------------------------------------------------------------------- Aniruddha G. Shet | Project webpage: http://forge-fre.ornl.gov/molar/index.html Graduate Research Associate | Project webpage: http://www.cs.unm.edu/~fastos Dept. of Comp. Sci. & Engg | Personal webpage: http://www.cse.ohio-state.edu/~shet The Ohio State University | Office: DL 474 2015 Neil Avenue | Phone: +1 (614) 292 7036 Columbus OH 43210-1277 | Cell: +1 (614) 446 1630 ----------------------------------------------------------------------------------------- |
|
From: Aarne F. <fi...@fh...> - 2005-11-10 22:36:33
|
Hello, Quit ing for ions - visi maExpr op overpay your Meddicat t our Phar ess Sh A V V P X C m A I r a I b L A o n A i I G z a L e U R a x I n M A c S 85,45 69,95 99,95 |
|
From: Dennis L. <pla...@tz...> - 2005-11-10 22:27:37
|
Hi, in the good old days of helgrind, I was able to track down some race conditions in our application. Now that helgrind isnt working anymore, Im facing a big problem of some heisenbugs. Core dumps are corrupted and running within gdb or valgrind solely does not trigger the bug. So, whats the current status of helgrind? What can we (the community) do to speed up getting helgrind to work? As a temporary workaround (i.e. to try to trigger the bug) it would be nice if valgrinds scheduler could have some randomness (of course enabled on user request only) in its execution of different threads, and maybe it can add some "sleeps" to further influence the timing of threads(to trigger the bugs) greets Dennis |
|
From: Julian S. <js...@ac...> - 2005-11-10 22:15:35
|
You need to upgrade your automake to version 1.7 or later, unfortunately. J On Thursday 10 November 2005 21:02, rak wrote: > After downloading the source code from > svn co svn://svn.valgrind.org/valgrind/trunk valgrind > autogen.sh gives error while running > > Am doing something wrong ? Do i need to set some flags. > > Thanks, > Rak > > uname -sa > Linux xeon 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 > x86_64 GNU/Linux > > > ./autogen.sh > running: aclocal > running: autoheader > running: automake -a > Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which > implies condition VG_X86_LINUX_TRUE > > BUILT_SOURCES (User, where = Makefile.am:34) += > { > TRUE => default.supp valgrind.pc > } > Makefile.am:35: CLEANFILES was already defined in condition TRUE, which > implies condition VG_X86_LINUX_TRUE > CLEANFILES (User, where = Makefile.am:35) += > { > TRUE => > } > Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which > implies condition VG_AMD64_LINUX_TRUE > > BUILT_SOURCES (User, where = Makefile.am:34) += > { > TRUE => default.supp valgrind.pc > VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds > } > Makefile.am:35: CLEANFILES was already defined in condition TRUE, which > implies condition VG_AMD64_LINUX_TRUE > CLEANFILES (User, where = Makefile.am:35) += > { > TRUE => > VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds > } > Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which > implies condition VG_PPC32_LINUX_TRUE > > BUILT_SOURCES (User, where = Makefile.am:34) += > { > VG_AMD64_LINUX_TRUE => valt_load_address_amd64_linux.lds > TRUE => default.supp valgrind.pc > VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds > } > . > . > . > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: rak <ra...@ho...> - 2005-11-10 21:06:16
|
After downloading the source code from svn co svn://svn.valgrind.org/valgrind/trunk valgrind autogen.sh gives error while running Am doing something wrong ? Do i need to set some flags. Thanks, Rak uname -sa Linux xeon 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux ./autogen.sh running: aclocal running: autoheader running: automake -a Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which implies condition VG_X86_LINUX_TRUE BUILT_SOURCES (User, where = Makefile.am:34) += { TRUE => default.supp valgrind.pc } Makefile.am:35: CLEANFILES was already defined in condition TRUE, which implies condition VG_X86_LINUX_TRUE CLEANFILES (User, where = Makefile.am:35) += { TRUE => } Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which implies condition VG_AMD64_LINUX_TRUE BUILT_SOURCES (User, where = Makefile.am:34) += { TRUE => default.supp valgrind.pc VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds } Makefile.am:35: CLEANFILES was already defined in condition TRUE, which implies condition VG_AMD64_LINUX_TRUE CLEANFILES (User, where = Makefile.am:35) += { TRUE => VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds } Makefile.am:34: BUILT_SOURCES was already defined in condition TRUE, which implies condition VG_PPC32_LINUX_TRUE BUILT_SOURCES (User, where = Makefile.am:34) += { VG_AMD64_LINUX_TRUE => valt_load_address_amd64_linux.lds TRUE => default.supp valgrind.pc VG_X86_LINUX_TRUE => valt_load_address_x86_linux.lds } . . . |
|
From: Tom H. <to...@co...> - 2005-11-10 18:05:33
|
In message <OF5...@us...>
Eduardo Munoz <ea...@us...> wrote:
> configure:3956: checking for a supported CPU
> configure:3984: result: ok (powerpc)
> configure:4002: checking enable use as an inner Valgrind
> configure:4015: result: no
> configure:4028: checking for a supported OS
> configure:4036: result: ok (linux)
> configure:4041: checking for the kernel version
> configure:4048: result: 2.6 family (2.6.8-2-686-smp)
> configure:4093: checking for a supported CPU/OS combination
> configure:4103: result: ok (powerpc-linux)
>
>
> $ ./configure --build=i686-linux --host=ppc-linux --target=ppc-linux
> --mandir=/usr/share/man --prefix=/u
> sr --libdir=/usr/lib
That looks fine - I was just concerned because I wasn't sure we
had the whole build/host/target thing right in the configure script.
It looks like Julian knows what the problem is anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-10 17:59:09
|
It turns out you are the fourth person we know of to try V on a ppc405 or similar. I believe the root problem is the 405 does not support floating point, and so the system SIGILLs when it=20 attempts to set the FPU control word before running instrumented code. I finally have access to such a system and so will look into whether there is an easy fix, in the next day or so. J On Thursday 10 November 2005 17:11, Eduardo Munoz wrote: > I did a something similar that Lev Iserovich did: > I have cross-compiled valgrind-3.1-SVN (from the current development > trunk), > Also I had to modify VEX/Makefile and configure.in to disable TLS because > it tries to run a complied program during configure. > It built fine. I checked my log and it used the right compiler, building > in a x86 for a ppc host. > > Well, I am getting a similar error when I run valgrind. > > >:~ # valgrind ls -l > > =3D=3D1279=3D=3D Memcheck, a memory error detector. > =3D=3D1279=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward= et al. > =3D=3D1279=3D=3D Using LibVEX rev 1447, a library for dynamic binary tran= slation. > =3D=3D1279=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. > =3D=3D1279=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation > framework. > =3D=3D1279=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward= et al. > =3D=3D1279=3D=3D For more details, rerun with: -v > =3D=3D1279=3D=3D > =3D=3D1279=3D=3D > =3D=3D1279=3D=3D Process terminating with default action of signal 4 (SIG= ILL) > =3D=3D1279=3D=3D Illegal opcode at address 0x700512C4 > =3D=3D1279=3D=3D at 0x40103EC: _start (dl-start.S:33) > =3D=3D1279=3D=3D > =3D=3D1279=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 f= rom 0) > =3D=3D1279=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks. > =3D=3D1279=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated. > =3D=3D1279=3D=3D For counts of detected errors, rerun with: -v > =3D=3D1279=3D=3D No malloc'd blocks -- no leaks are possible. > Illegal instruction > > Any ideas?? > Regards, > Eduardo A. Mu=C3=B1oz |
|
From: Eduardo M. <ea...@us...> - 2005-11-10 17:52:38
|
configure:3956: checking for a supported CPU
configure:3984: result: ok (powerpc)
configure:4002: checking enable use as an inner Valgrind
configure:4015: result: no
configure:4028: checking for a supported OS
configure:4036: result: ok (linux)
configure:4041: checking for the kernel version
configure:4048: result: 2.6 family (2.6.8-2-686-smp)
configure:4093: checking for a supported CPU/OS combination
configure:4103: result: ok (powerpc-linux)
$ ./configure --build=3Di686-linux --host=3Dppc-linux --target=3Dppc-linux=
=20
--mandir=3D/usr/share/man --prefix=3D/u
sr --libdir=3D/usr/lib
Regards,
Eduardo A. Mu=F1oz
Tom Hughes <to...@co...>=20
Sent by: val...@li...
11/10/2005 11:36 AM
To
val...@li...
cc
Subject
Re: [Valgrind-users] illegal instruction in ppc (4xx board)
In message=20
<OF8...@us...>
Eduardo Munoz <ea...@us...> wrote:
> I did a something similar that Lev Iserovich did:
> I have cross-compiled valgrind-3.1-SVN (from the current development=20
> trunk),=20
> Also I had to modify VEX/Makefile and configure.in to disable TLS=20
because=20
> it tries to run a complied program during configure.=20
> It built fine. I checked my log and it used the right compiler,=20
building=20
> in a x86 for a ppc host.
As I said yesterday, what did configure say when it checked for
a supported CPU?
An addition question is what switches did you give to configure?
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.=20
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2005-11-10 17:36:33
|
In message <OF8...@us...>
Eduardo Munoz <ea...@us...> wrote:
> I did a something similar that Lev Iserovich did:
> I have cross-compiled valgrind-3.1-SVN (from the current development
> trunk),
> Also I had to modify VEX/Makefile and configure.in to disable TLS because
> it tries to run a complied program during configure.
> It built fine. I checked my log and it used the right compiler, building
> in a x86 for a ppc host.
As I said yesterday, what did configure say when it checked for
a supported CPU?
An addition question is what switches did you give to configure?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eduardo M. <ea...@us...> - 2005-11-10 17:06:50
|
I did a something similar that Lev Iserovich did: I have cross-compiled valgrind-3.1-SVN (from the current development=20 trunk),=20 Also I had to modify VEX/Makefile and configure.in to disable TLS because=20 it tries to run a complied program during configure.=20 It built fine. I checked my log and it used the right compiler, building=20 in a x86 for a ppc host. Well, I am getting a similar error when I run valgrind. >:~ # valgrind ls -l =3D=3D1279=3D=3D Memcheck, a memory error detector. =3D=3D1279=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward e= t al. =3D=3D1279=3D=3D Using LibVEX rev 1447, a library for dynamic binary transl= ation. =3D=3D1279=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D1279=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation=20 framework. =3D=3D1279=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward e= t al. =3D=3D1279=3D=3D For more details, rerun with: -v =3D=3D1279=3D=3D =3D=3D1279=3D=3D =3D=3D1279=3D=3D Process terminating with default action of signal 4 (SIGIL= L) =3D=3D1279=3D=3D Illegal opcode at address 0x700512C4 =3D=3D1279=3D=3D at 0x40103EC: =5Fstart (dl-start.S:33) =3D=3D1279=3D=3D =3D=3D1279=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 fro= m 0) =3D=3D1279=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks. =3D=3D1279=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated. =3D=3D1279=3D=3D For counts of detected errors, rerun with: -v =3D=3D1279=3D=3D No malloc'd blocks -- no leaks are possible. Illegal instruction Any ideas?? Regards, Eduardo A. Mu=F1oz |
|
From: Martin H. <hi...@gm...> - 2005-11-10 16:01:30
|
I'm trying to run a JIT that uses CLFLUSH after code patching to invalidate the cache line, so the I-cache will reload the new version before it gets executed again. When running on valgrind, I get the error message "vex x86->IR: unhandled instruction bytes: 0xF 0xAE 0xB8 0x0", which is the encoding for CLFLUSH. I found the commented-out code in guest-x86/toIR.c that corresponds to CLFLUSH. Being commented out, I was not surprised that that code is out-of-date. Can someone tell me how to change toIR.c so it just treats CLFLUSH as a NOO= P? Or better yet, how to actually do it right? (I assume I would need to emit a client request for invalidating the code in valgrind's code cache; how would I do this?) Thanks, Martin |
|
From: Cerion Armour-B. <ce...@op...> - 2005-11-10 12:33:25
|
On Thursday 10 November 2005 12:21, Cerion Armour-Brown wrote: > valgrind repo down for a moment for upgrades, > Sorry for any inconvenience. > Cerion > Ok, we're back online. Cerion |
|
From: Cerion Armour-B. <ce...@op...> - 2005-11-10 11:21:53
|
valgrind repo down for a moment for upgrades, Sorry for any inconvenience. Cerion |
|
From: Tom H. <to...@co...> - 2005-11-10 00:12:57
|
In message <437...@ci...>
Lev Iserovich <lis...@ci...> wrote:
> I've cross compiled valgrind-3.0.1 building on a 686-linux on to a PPC
> embedded linux (running the IBM PPC 405 chip)
> The compilation went fine, but I had to disable TLS because it wanted to
> run a compiled program during 'configure',
> and modify the VEX/Makefile to compile the genoffsets program using the
> local compiler.
What processor did it say it was selecting at configure time? I have
a nasty feeling it may have built a valgrind that runs on ppc but
wants to run x86 code...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Lev I. <lis...@ci...> - 2005-11-09 23:49:55
|
Hi all, I've cross compiled valgrind-3.0.1 building on a 686-linux on to a PPC embedded linux (running the IBM PPC 405 chip) The compilation went fine, but I had to disable TLS because it wanted to run a compiled program during 'configure', and modify the VEX/Makefile to compile the genoffsets program using the local compiler. After all this, valgrind runs on the target, but any binary I run, I get : $ ./valgrind ls ==22261== Memcheck, a memory error detector. ==22261== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==22261== Using LibVEX rev 1367, a library for dynamic binary translation. ==22261== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==22261== Using valgrind-3.0.1, a dynamic binary instrumentation framework. ==22261== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==22261== For more details, rerun with: -v ==22261== ==22261== ==22261== Process terminating with default action of signal 4 (SIGILL) ==22261== at 0x1188059C: _start (../sysdeps/powerpc/dl-start.S:33) ==22261== ==22261== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==22261== malloc/free: in use at exit: 0 bytes in 0 blocks. ==22261== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==22261== For counts of detected errors, rerun with: -v ==22261== No malloc'd blocks -- no leaks are possible. Illegal instruction Is the 405 supported? Does anyone know what debugging I can enable to figure out what's going on? Thanks, Lev |