|
From: Tom H. <to...@co...> - 2005-11-07 19:14:46
|
The SVN version of valgrind now has support for running 32 bit x86 binaries on amd64 systems - when valgrind is built on amd64 it will build with support for both x86 and amd64 binaries so that it can run both 32 bit and 64 bit programs. The correct tool should be selected automatically including when a 32 bit program is exec'ed from a 64 bit program or vice versa and the --trace-children=yes flag is used to cause valgrind to trace the new program. 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. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Daniel V. <vei...@re...> - 2005-11-07 22:45:39
|
On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote: > The SVN version of valgrind now has support for running 32 bit x86 > binaries on amd64 systems Cool ! Out of curiosity, do you make use of the extra registers to speed up emulation ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Julian S. <js...@ac...> - 2005-11-07 23:49:36
|
On Monday 07 November 2005 22:45, Daniel Veillard wrote: > On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote: > > The SVN version of valgrind now has support for running 32 bit x86 > > binaries on amd64 systems > > Cool ! Out of curiosity, do you make use of the extra registers to > speed up emulation ? No - we have enough complication as it is without doing cross-arch simulation :-) Besides, one of the things that is apparent from the ppc32 port is that having a lot of registers on the host does not seem to make difference in performance, because the live ranges are not long enough to use them all. It's much more important for the guest architecture to have a lot of registers, because having more registers means fewer spills, and since each spill is a memory transaction that memcheck/cachegrind has to track, spills on the guest are expensive. J |
|
From: Julian S. <js...@ac...> - 2005-11-07 23:51:35
|
> 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. In particular, we would be interested to hear about amd64-linux setups where you only have a 64-bit toolchain and 32-bit is not supported -- does it work in that situation? J |
|
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: Tom H. <to...@co...> - 2005-11-12 17:49:31
|
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 18:44:16
|
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: Tom H. <to...@co...> - 2005-11-12 18:50:51
Attachments:
valgrind-sicode.patch
|
In message <414...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <2a2...@ma...>
> Paul Pluzhnikov <ppl...@gm...> wrote:
>
> > $ /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.
Try this patch - it tweaks our signal handlers to discard anything
in the top half of the si_code value on linux as the kernel is
supposed to have masked that off already.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|