|
From: Victor S. <vse...@pa...> - 2005-08-18 19:08:10
|
I have built Valgrind 3 on an Opteron machine with RHEL 3.3 and glibc-2.3.2-95.27, using gcc 3.4.4. It grinds programs built with gcc or c++ , which means 64-bit programs. However, if I try to grind a 32-bit program made with gcc296, it refuses saying: === valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit) === valgrind: do_exec(linux/SeisX) failed: Exec format error Is there a command line flag for 32/64 ? =or= Can I build and install two valgrinds on the same machine? A valgrind built with gcc on a 32 bit AMD machine runs on that same machine, but when I tried to install it under a different prefix on the Opteron box it produced segfaults. Is there a way? Please advise, and thank you very much, Victor Secarin |
|
From: Christian P. <tr...@ge...> - 2005-08-19 03:13:22
|
On Thursday 18 August 2005 00:15, Victor Secarin wrote: [...] > =3D=3D=3D valgrind: wrong ELF executable class (eg. 32-bit instead of 64-= bit) > =3D=3D=3D valgrind: do_exec(linux/SeisX) failed: Exec format error > > Is there a command line flag for 32/64 ? > =3Dor=3D > Can I build and install two valgrinds on the same machine? What I did on my Opteron (in 64bit mode) bevore 3.0 became stable, was, to= =20 setup a 32bit chroot environment in /mnt/linux32, installing a linux in=20 there, and then invoking `linux32 /mnt/linux32/bin/sh` I don't know wether this is easily achievable by RHEL/FC too. But this way = I=20 tested my apps being 32bit compiled (on a 64bit host) Regards, Christian Parpart. =2D-=20 05:08:45 up 148 days, 18:16, 1 user, load average: 1.04, 1.15, 1.03 |
|
From: Dirk M. <dm...@gm...> - 2005-08-19 11:54:41
|
On Friday 19 August 2005 05:53, Christian Parpart wrote: > I don't know wether this is easily achievable by RHEL/FC too. But this way > I tested my apps being 32bit compiled (on a 64bit host) Most serious Linux distributions allow usage of 32bit applications in the same system like 64bit applications, but for this valgrind needs to be compiled with 32 and 64 bit mode enabled. Thats currently impossible. Dirk |
|
From: Tom H. <to...@co...> - 2005-08-19 12:47:43
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 05:53, Christian Parpart wrote:
>
>> I don't know wether this is easily achievable by RHEL/FC too. But this way
>> I tested my apps being 32bit compiled (on a 64bit host)
>
> Most serious Linux distributions allow usage of 32bit applications in the same
> system like 64bit applications, but for this valgrind needs to be compiled
> with 32 and 64 bit mode enabled. Thats currently impossible.
It's not impossible, just a little tricky ;-)
If you have a 32 bit machine available you can build on that which
gives you a 32 bit valgrind (in /usr/lib) then build on a 64 bit
machine which gives you a 64 bit valgrind (in /usr/lib64) then install
them both on a 64 bit machine, rename /usr/bin/valgrind from each to
something else and write a shell script to decide which one to start.
That's what I did for our local RPMs anyway. It isn't ideal though and
has certain problems so we do need a better solution.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-08-19 13:48:24
|
On Friday 19 August 2005 14:46, Tom Hughes wrote: > them both on a 64 bit machine, rename /usr/bin/valgrind from each to > something else and write a shell script to decide which one to start. Yeah, once again we're back to a valgrind shell wrapper ;) so the valgrind binary itself should move to libdir as well. I don't see any other solution right now. Dirk |
|
From: Tom H. <to...@co...> - 2005-08-19 14:19:14
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 14:46, Tom Hughes wrote:
>
>> them both on a 64 bit machine, rename /usr/bin/valgrind from each to
>> something else and write a shell script to decide which one to start.
>
> Yeah, once again we're back to a valgrind shell wrapper ;)
It's not a proper solution though, as you can't exec 32 bit
from 64 bit and vice versa to start with.
> so the valgrind binary itself should move to libdir as well. I don't see any
> other solution right now.
I actually moved it to $libdir/stage1 ;-)
I think we can do better in the long term base don the work Julian has
been doing on the address space branch and having a simple binary
loader that decides which combined stage2/tool binary to load.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-08-19 17:27:43
|
On Friday 19 August 2005 16:19, Tom Hughes wrote: > It's not a proper solution though, as you can't exec 32 bit > from 64 bit and vice versa to start with. What do you mean by that? Dirk |
|
From: Christian P. <tr...@ge...> - 2005-08-19 23:10:46
|
On Friday 19 August 2005 15:47, Dirk Mueller wrote: > On Friday 19 August 2005 14:46, Tom Hughes wrote: > > them both on a 64 bit machine, rename /usr/bin/valgrind from each to > > something else and write a shell script to decide which one to start. > > Yeah, once again we're back to a valgrind shell wrapper ;) > > so the valgrind binary itself should move to libdir as well. I don't see > any other solution right now. *might* be - for now. But I really wish - as it is possible for other=20 tools/libs too - to see multi-ABI support in valgrind. Well, I didn't say to expect it in 3.1, but anyway ;) Regards, Christian Parpart. =2D-=20 01:08:44 up 149 days, 14:16, 5 users, load average: 0.46, 0.26, 0.26 |
|
From: Tom H. <to...@co...> - 2005-08-19 18:41:26
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Friday 19 August 2005 16:19, Tom Hughes wrote:
>
> > It's not a proper solution though, as you can't exec 32 bit
> > from 64 bit and vice versa to start with.
>
> What do you mean by that?
A 64 bit process can't execve() a 32 bit process or vice versa.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bryan O'S. <bo...@se...> - 2005-08-19 19:24:12
|
On Fri, 2005-08-19 at 19:41 +0100, Tom Hughes wrote: > A 64 bit process can't execve() a 32 bit process or vice versa. What? bos$ uname -i x86_64 bos$ file ./ash ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped bos$ ./ash $ file $0 ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped $ /bin/ls ash |
|
From: Dirk M. <dm...@gm...> - 2005-08-19 20:07:32
|
On Friday 19 August 2005 21:23, Bryan O'Sullivan wrote: > > A 64 bit process can't execve() a 32 bit process or vice versa. > What? [...] I believe he meant when running under valgrind. once started under valgrind, all forked/exec'ed executables are hardcoded to one architecture. Dirk |
|
From: Julian S. <js...@ac...> - 2005-08-19 20:13:47
|
I suspect what Tom means is, a process running on 64-bit valgrind can't execve() a 32-bit process, or vice versa. J On Friday 19 August 2005 20:23, Bryan O'Sullivan wrote: > On Fri, 2005-08-19 at 19:41 +0100, Tom Hughes wrote: > > A 64 bit process can't execve() a 32 bit process or vice versa. > > What? > > bos$ uname -i > x86_64 > bos$ file ./ash > ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped bos$ ./ash > $ file $0 > ./ash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped $ file > /bin/ls > /bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for > GNU/Linux 2.4.0, dynamically linked (uses shared libs), stripped $ /bin/ls > ash > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |