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: Aniruddha S. <sh...@cs...> - 2005-11-05 20:19:46
|
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? Thanks, Aniruddha |
|
From: Julian S. <js...@ac...> - 2005-11-05 15:14:51
|
Ashley, thanks. Committed (modified) in r5023. If you have a
spare minute sometime, can you confirm that a vanilla checkout
works for you now?
J
On Tuesday 01 November 2005 16:11, you wrote:
> On Tue, 2005-11-01 at 15:29 +0000, Julian Seward wrote:
> > Hi Ashley
> >
> > So if you hack syswrap-x86-linux.c to allow the relevant flags
> > through, does everything still work? If yes, pls send a diff.
>
> This works fine.
>
> Ashley,
>
> stratum15:valgrind> svn diff
> Index: coregrind/m_syswrap/syswrap-x86-linux.c
> ===================================================================
> --- coregrind/m_syswrap/syswrap-x86-linux.c (revision 4976)
> +++ coregrind/m_syswrap/syswrap-x86-linux.c (working copy)
> @@ -1067,6 +1067,7 @@
> - ??? specifies clone flags of 0x1200011.
> - NPTL specifies clone flags of 0x7D0F00.
> - The Quadrics Elan3 driver specifies clone flags of 0xF00.
> + - Newer Quadrics Elan3 drivers with NTPL support specify
> 0x410F00.
> Everything else is rejected.
> */
> if (
> @@ -1074,6 +1075,7 @@
>
> || cloneflags == 0x7D0F00
> || cloneflags == 0x790F00
> || cloneflags == 0x3D0F00
>
> + || cloneflags == 0x410F00
>
> || cloneflags == 0xF00
> || cloneflags == 0xF21)) {
>
> /* OK */
|
|
From: Tom H. <to...@co...> - 2005-11-04 11:27:56
|
In message <200...@we...>
Swapnil Kumar Raktale <swa...@re...> wrote:
> Can someone help me resolve this error ....
>
> Making all in m_aspacemgr
> make[4]: Entering directory `/user/demxc8w3/learn/valgrind-3.0.1/coregrind/m_aspacemgr'
> source='read_procselfmaps.c' object='read_procselfmaps.o' libtool=no \
> DEPDIR=.deps depmode=gcc /bin/sh ../../depcomp \
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux -I../../include -I/user/demxc8w3/learn/valgrind-3.0.1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c read_procselfmaps.c
> source='aspacemgr.c' object='aspacemgr.o' libtool=no \
> DEPDIR=.deps depmode=gcc /bin/sh ../../depcomp \
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux -I../../include -I/user/demxc8w3/learn/valgrind-3.0.1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c aspacemgr.c
> aspacemgr.c: In function `vgPlain_setup_pointercheck':
> aspacemgr.c:1284: parse error before `ldt'
> aspacemgr.c:1296: `ret' undeclared (first use in this function)
> aspacemgr.c:1296: (Each undeclared identifier is reported only once
> aspacemgr.c:1296: for each function it appears in.)
Either use a newer C compiler (gcc 3 or 4) or use the SVN code where
this has been resolved.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Swapnil K. R. <swa...@re...> - 2005-11-04 11:21:58
|
=A0=0AHello,=0A=0AI am trying to install Valgrind [valgrind-3.0.1] on =0A= =0A[uname -a]=0ALinux decy766c 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT= 2003 i686 i686 i386 GNU/Linux=0A=0ACan someone help me resolve this error = ....=0A=0AMaking all in m_aspacemgr=0Amake[4]: Entering directory `/user/de= mxc8w3/learn/valgrind-3.0.1/coregrind/m_aspacemgr'=0Asource=3D'read_procsel= fmaps.c' object=3D'read_procselfmaps.o' libtool=3Dno \=0ADEPDIR=3D.deps dep= mode=3Dgcc /bin/sh ../../depcomp \=0Agcc -DHAVE_CONFIG_H -I. -I. -I../.. -= I../../coregrind -I../.. -I../../coregrind/x86 -I../../coregrind/linux -I..= /../coregrind/x86-linux -I../../include -I/user/demxc8w3/learn/valgrind-3.0= .1/VEX/pub -DVGA_x86=3D1 -DVGO_linux=3D1 -DVGP_x86_linux=3D1 -mpreferred= -stack-boundary=3D2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno= -long-long -c read_procselfmaps.c=0Asource=3D'aspacemgr.c' object=3D'aspace= mgr.o' libtool=3Dno \=0ADEPDIR=3D.deps depmode=3Dgcc /bin/sh ../../depcomp = \=0Agcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../= coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux -I../../i= nclude -I/user/demxc8w3/learn/valgrind-3.0.1/VEX/pub -DVGA_x86=3D1 -DVGO_li= nux=3D1 -DVGP_x86_linux=3D1 -mpreferred-stack-boundary=3D2 -Wmissing-pro= totypes -Winline -Wall -Wshadow -O -g -Wno-long-long -c aspacemgr.c=0Aaspac= emgr.c: In function `vgPlain_setup_pointercheck':=0Aaspacemgr.c:1284: parse= error before `ldt'=0Aaspacemgr.c:1296: `ret' undeclared (first use in this= function)=0Aaspacemgr.c:1296: (Each undeclared identifier is reported only= once=0Aaspacemgr.c:1296: for each function it appears in.)=0Amake[4]: *** = [aspacemgr.o] Error 1=0Amake[4]: Leaving directory `/user/demxc8w3/learn/va= lgrind-3.0.1/coregrind/m_aspacemgr'=0Amake[3]: *** [all-recursive] Error 1= =0Amake[3]: Leaving directory `/user/demxc8w3/learn/valgrind-3.0.1/coregrin= d'=0Amake[2]: *** [all] Error 2=0Amake[2]: Leaving directory `/user/demxc8w= 3/learn/valgrind-3.0.1/coregrind'=0Amake[1]: *** [all-recursive] Error 1=0A= make[1]: Leaving directory `/user/demxc8w3/learn/valgrind-3.0.1'=0Amake: **= * [all] Error 2=0A=0A=0A=0ABest Regards=0ASwapnil K. Raktale=0A=0AWe aspire= for perfection --=0AWe'll settle for excellence=0A |
|
From: Igmar P. <mai...@jd...> - 2005-11-03 20:44:30
|
> > ==31863== Bad permissions for mapped region at address 0xFFFFD400
> > ==31863== at 0xFFFFD400: ???
> > ==31863== by 0x4371C0A: (within /lib/tls/libpthread-0.34.so)
> > ==31863== by 0x437190A: (within /lib/tls/libpthread-0.34.so)
> > ==31863== by 0x410CC21: _dl_init (in /lib/ld-2.3.2.so)
> > ==31863== by 0x4100C5C: (within /lib/ld-2.3.2.so)
>
> The question is why is libpthread calling that strange address - that
> is a very odd address to have code at.
sysenter / sysexit system calls is the only range that comes somewhat
close :
[igmar@jdi ~]$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
Regards,
Igmar
|
|
From: Julian S. <js...@ac...> - 2005-11-03 14:13:39
|
On Tuesday 01 November 2005 22:01, Yin, Hui wrote: > This is seen from valgrind-3.0.1 output. The process received SIGKILL > afterwards. Is this a known issue? Fixed. Try this: svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh configure and build as usual. J |
|
From: Alex B. <ker...@be...> - 2005-11-03 13:54:28
|
On Thu, 2005-11-03 at 13:18 +0000, Julian Seward wrote: > On Thursday 03 November 2005 12:14, Alex Bennee wrote: > > Hi, > > > > Continuing in the valgrind runs today running on a slightly more heavy > > weight test Valgrind spat the following out: > > > > Memcheck: the 'impossible' happened: > > memcheck:expr2vbits_Binop > > This is definitely a bug, however you zapped the crucial piece of > information, re which Binop it doesn't like. That would have > been on the previous line of text. Oops. Sorry about that. I've included the full line in the bug report: http://bugs.kde.org/show_bug.cgi?id=115612 > J -- Alex, homepage: http://www.bennee.com/~alex/ I went to the race track once and bet on a horse that was so good that it took seven others to beat him! |
|
From: Julian S. <js...@ac...> - 2005-11-03 13:13:44
|
On Thursday 03 November 2005 12:14, Alex Bennee wrote: > Hi, > > Continuing in the valgrind runs today running on a slightly more heavy > weight test Valgrind spat the following out: > > Memcheck: the 'impossible' happened: > memcheck:expr2vbits_Binop This is definitely a bug, however you zapped the crucial piece of information, re which Binop it doesn't like. That would have been on the previous line of text. J |
|
From: Tom H. <to...@co...> - 2005-11-03 13:00:57
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> Continuing in the valgrind runs today running on a slightly more heavy
> weight test Valgrind spat the following out:
>
> Memcheck: the 'impossible' happened:
> memcheck:expr2vbits_Binop
> ==7065== at 0xB000E17A: vgPlain_core_panic_at (m_libcassert.c:181)
> ==7065== by 0xB000E179: panic (m_libcassert.c:177)
> ==7065== by 0xB000E1CC: vgPlain_tool_panic (m_libcassert.c:192)
> ==7065== by 0xB00097E2: expr2vbits_Binop (mc_translate.c:2000)
> ==7065== by 0xB00092EC: expr2vbits (mc_translate.c:2285)
> ==7065== by 0xB000B175: vgMemCheck_instrument (mc_translate.c:2914)
> ==7065== by 0xB0056C29: LibVEX_Translate (vex_main.c:472)
> ==7065== by 0xB001C76F: vgPlain_translate (libvex_basictypes.h:162)
> ==7065== by 0xB002AFBD: handle_tt_miss (scheduler.c:591)
> ==7065== by 0xB002B356: vgPlain_scheduler (scheduler.c:712)
> ==7065== by 0xB0047F08: vgModuleLocal_thread_wrapper (syswrap-linux.c:82)
> ==7065== by 0xB0038F75: run_a_thread_NORETURN (syswrap-x86-linux.c:127)
>
> This is with the current subversion tree. Is there any more information
> that would be useful?
Probably not, but please raise a bug for this on the tracker.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-03 12:14:50
|
Hi, Continuing in the valgrind runs today running on a slightly more heavy weight test Valgrind spat the following out: Memcheck: the 'impossible' happened: memcheck:expr2vbits_Binop ==7065== at 0xB000E17A: vgPlain_core_panic_at (m_libcassert.c:181) ==7065== by 0xB000E179: panic (m_libcassert.c:177) ==7065== by 0xB000E1CC: vgPlain_tool_panic (m_libcassert.c:192) ==7065== by 0xB00097E2: expr2vbits_Binop (mc_translate.c:2000) ==7065== by 0xB00092EC: expr2vbits (mc_translate.c:2285) ==7065== by 0xB000B175: vgMemCheck_instrument (mc_translate.c:2914) ==7065== by 0xB0056C29: LibVEX_Translate (vex_main.c:472) ==7065== by 0xB001C76F: vgPlain_translate (libvex_basictypes.h:162) ==7065== by 0xB002AFBD: handle_tt_miss (scheduler.c:591) ==7065== by 0xB002B356: vgPlain_scheduler (scheduler.c:712) ==7065== by 0xB0047F08: vgModuleLocal_thread_wrapper (syswrap-linux.c:82) ==7065== by 0xB0038F75: run_a_thread_NORETURN (syswrap-x86-linux.c:127) This is with the current subversion tree. Is there any more information that would be useful? -- Alex, homepage: http://www.bennee.com/~alex/ Fifty flippant frogs Walked by on flippered feet And with their slime they made the time Unnaturally fleet. |
|
From: Julian S. <js...@ac...> - 2005-11-02 22:32:26
|
On Wednesday 02 November 2005 20:23, Nicholas Nethercote wrote:
> On Wed, 2 Nov 2005, Dirk Mueller wrote:
> > is there already tool for valgrind that can detect unaligned accesses?
>
> I don't know of one. It would be very easy to write, though. Lackey (the
> version in Subversion, not that in 3.0.1) would be a good place to start.
Hi Dirk
Presumably the %eflags.ac=1 trick doesn't work for you?
Anyway, I agree, a lackey derivative would be a possibility,
but the 5-minute solution is to look at mc_{STOREVn,LOADVn}_slow
in mc_main.c, which is where all misaligned accesses will end
up.
So if you add something like
if ((a % szB) != 0)
MAC_(record_address_error)( VG_(get_running_tid)(), a, szB, False );
then you might get what you want.
It doesn't matter that the % is slow since these functions are the
slow, general-case handlers which very rarely get used.
J
|
|
From: Dennis L. <pla...@tz...> - 2005-11-02 21:54:11
|
Am Mittwoch, den 02.11.2005, 12:54 -0800 schrieb John Reiser: > > is there already tool for valgrind that can detect unaligned accesses? > > Beware that some parts of glibc used to make unaligned accesses, > and they might not all be eradicated yet. Here the valgrind suppression mechanism would be very handy, so a tool would be nice. |
|
From: John R.
|
> is there already tool for valgrind that can detect unaligned accesses? On i586 hardware and later, setting bit 18 (Alignment Check) in the processor flags will do this at full hardware speed. It traps on non- aligned access from ring 3 (user mode), and linux gives you SIGBUS. In assembly language: pushf movl $(1<<18),%eax orl %eax,(%esp) popf or, because you probably want to catch the SIGBUS in a debugger anyway: (gdb) set $ps |= (1<<18) Continuing through the SIGBUS is somewhat awkward: (gdb) set $ps &= ~(1<<18) # clear AC bit (gdb) x/2i $pc # see where you are (gdb) tbreak *$_ # temporary breakpoint beyond trapping instruction (gdb) signal 0 # continue with no signal to temp breakpoint; delete bkpt (gdb) set $ps |= (1<<18) # re-enable Alignment Check Beware that some parts of glibc used to make unaligned accesses, and they might not all be eradicated yet. -- |
|
From: Nicholas N. <nj...@cs...> - 2005-11-02 20:23:35
|
On Wed, 2 Nov 2005, Dirk Mueller wrote: > is there already tool for valgrind that can detect unaligned accesses? I don't know of one. It would be very easy to write, though. Lackey (the version in Subversion, not that in 3.0.1) would be a good place to start. Nick |
|
From: Dirk M. <dm...@gm...> - 2005-11-02 19:42:11
|
Hi, is there already tool for valgrind that can detect unaligned accesses? Dirk |
|
From: Tom H. <to...@co...> - 2005-11-02 15:49:14
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> So the question now is whether we should increase the LDT size
>> limit in VEX which is one for Julian I guess.
>>
>> Was there any particular reason for the 64 entry limit Julian?
>
> Euh .. can't really remember. I _think_ it might be that each thread
> has to have its own LDT (is that right?) and so allocating a whole one
> was a bit wasteful.
It does, yes. The kernel (and valgrind 2.4) uses a lazy copying scheme
so that the LDT is shared until a thread actually changed it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-02 15:42:16
|
> So the question now is whether we should increase the LDT size > limit in VEX which is one for Julian I guess. > > Was there any particular reason for the 64 entry limit Julian? Euh .. can't really remember. I _think_ it might be that each thread has to have its own LDT (is that right?) and so allocating a whole one was a bit wasteful. I'll change it to full-size. J |
|
From: Tom H. <to...@co...> - 2005-11-02 15:37:06
|
In message <113...@ok...>
Alex Bennee <ker...@be...> wrote:
> Still all good now. The program gets a lot further in before valgrind
> detects the application loading a non-x86 ELF (which obviously confuses
> ld.so.1). Still its pointed to enough to be going on with.
So the question now is whether we should increase the LDT size
limit in VEX which is one for Julian I guess.
Was there any particular reason for the 64 entry limit Julian?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 15:15:05
|
On Wed, 2005-11-02 at 12:40 +0000, Tom Hughes wrote: > In message <yek...@de...> > Tom Hughes <to...@co...> wrote: > > > > > You could try setting verboze to True in x86g_use_seg_selector > > in VEX/priv/guest-x86/ghelpers.c and see what it says - that should > > report the segment translations that it does. I did that and it got further. I suspect it was because I did: > One other thing that just occurred to me - make sure you have > done a make in the VEX directory as doing a make at the top level > doesn't always manage to rebuild VEX correctly. I've been installing this on my system using checkinstall for the "make install" stage and I have noticed that seems to cause a bunch of stuff to get compiled. I guess there must be a subtle bug in the Makefile's somewhere that cause incorrect builds occasionally. Still all good now. The program gets a lot further in before valgrind detects the application loading a non-x86 ELF (which obviously confuses ld.so.1). Still its pointed to enough to be going on with. Thanks for you help today. -- Alex, homepage: http://www.bennee.com/~alex/ Darth Vader sleeps with a Teddywookie. |
|
From: Ashley P. <as...@qu...> - 2005-11-02 15:05:55
|
On Tue, 2005-11-01 at 19:03 +0000, Julian Seward wrote: > Ok, svn up (make sure you get vex r1427) and try again. I was too > lazy to spark up my amd64 box so the fix is as-yet untested :-) That fixes it for me. I can now run fairly large applications on these nodes without errors. Ashley, |
|
From: Tom H. <to...@co...> - 2005-11-02 14:47:49
|
In message <yek...@de...>
Tom Hughes <to...@co...> wrote:
> In message <200...@ac...>
> Julian Seward <js...@ac...> wrote:
>
>>> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
>>> > 0x118f749644: addr32 mov (%eax),%ecx
>>>
>>> That's an address size override prefix which doesn't seem to be
>>> supported at the moment - can you raise a bug for this please.
>>
>> I've never seen such a request from any code generated by the GNU tools.
>>
>> What should the override do? Does it just mean the effective address
>> should be anded with 2^32-1 once computed, or something more involved?
>
> It means only 32 bits are loaded from the computed address not 64. At
> least that was my reading of the AMD doco.
I've reread it now and I think you're right - it is the operand size
prefix that changes the size of the load. I'm not quite sure why you
would ever want to truncate addresses like that though - it seems a
rather odd thing to do.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Alex B. <ker...@be...> - 2005-11-02 14:38:45
|
On Wed, 2005-11-02 at 13:28 +0000, Julian Seward wrote: > > > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B > > > 0x118f749644: addr32 mov (%eax),%ecx > > > > That's an address size override prefix which doesn't seem to be > > supported at the moment - can you raise a bug for this please. > > I've never seen such a request from any code generated by the GNU tools. In this case its handwritten inline assembly. Although I have seen instructions generated like this by some JIT's. > What should the override do? Does it just mean the effective address > should be anded with 2^32-1 once computed, or something more involved? Pretty much. It just ignores the top 32 bits of the 64 bit result. Do you still want me to raise a bug for this one? > 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 -- Alex, homepage: http://www.bennee.com/~alex/ You need no longer worry about the future. This time tomorrow you'll be dead. |
|
From: Tom H. <to...@co...> - 2005-11-02 13:52:43
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B
>> > 0x118f749644: addr32 mov (%eax),%ecx
>>
>> That's an address size override prefix which doesn't seem to be
>> supported at the moment - can you raise a bug for this please.
>
> I've never seen such a request from any code generated by the GNU tools.
>
> What should the override do? Does it just mean the effective address
> should be anded with 2^32-1 once computed, or something more involved?
It means only 32 bits are loaded from the computed address not 64. At
least that was my reading of the AMD doco.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-02 13:26:18
|
> > vex amd64->IR: 0x4 unhandled instruction bytes: 0x67 0x8B 0x8 0x8B > > 0x118f749644: addr32 mov (%eax),%ecx > > That's an address size override prefix which doesn't seem to be > supported at the moment - can you raise a bug for this please. I've never seen such a request from any code generated by the GNU tools. What should the override do? Does it just mean the effective address should be anded with 2^32-1 once computed, or something more involved? J |
|
From: Julian S. <js...@ac...> - 2005-11-02 13:18:37
|
> > Thanks. That worked and it moved forward. Unfortunately we set up the fs > > segment selector to point at the entry. This doesn't seem to be > > correctly setup under valgrind: > > > > setFS(0x3ef) > > What instruction(s) is this routine using to set %fs? > > It should work - although I think the x86 glibc uses %gs so that > is probably more thoroughly tested. I agree, it should work. Moves to/from segment registers are supported, as are the use of %ds, %es, %fs and %gs in segment override prefixes. J |