|
From: Robert W. <rj...@du...> - 2004-04-21 07:13:14
|
Hi folks,
I've started looking at getting Valgrind running on AMD64 machines,
since my main desktop is now an Athlon64 box. The first thing that
seemed useful was to get Valgrind running with 32-bit executables on
AMD64 machines. I've put a one-line patch on my web site that does
this. I've only tested this under Fedora Core 1 with a 2.6.5 kernel.=20
I'd appreciate if someone could give it a spin with another distribution
and/or a 2.4 kernel. Some notes:
* You need to build on an x86 box with compatible libraries to the
box you plan on testing on - you still can't build on an AMD64
machine.
* It is just a mechanism for Valgrinding 32-bit executables on an
AMD64 machine. 64-bit executables are a LONG way off... :-)
* Some (about 6) of the regression tests fail. I haven't really
investigated these yet. Some appear to be library
incompatibilities, as I was building the tests on a RedHat 9 for
x86 machine and executing them on a Fedora Core 1 for AMD64
machine. Others appear to be a bit more serious.
BTW: this patch doesn't actually break regular Valgrind-on-x86 in any
way, so if it seems OK, I'll commit it in the next few days, after I've
heard back from people.
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: Robert W. <rj...@du...> - 2004-04-21 16:47:59
|
> I've started looking at getting Valgrind running on AMD64 machines, > since my main desktop is now an Athlon64 box. The first thing that > seemed useful was to get Valgrind running with 32-bit executables on > AMD64 machines. I've put a one-line patch on my web site that does > this. It might have helped if I'd included the URL: http://www.durables.org/software/valgrind/ Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2004-04-22 03:50:29
|
On Wed, 2004-04-21 at 17:13, Robert Walsh wrote: > BTW: this patch doesn't actually break regular Valgrind-on-x86 in any > way, so if it seems OK, I'll commit it in the next few days, after I've > heard back from people. Hm, I'm not quite sure about this. I think there's a risk that this will let Valgrind allocate a mapping in the last 64k of the address space, which would be bad. The trouble here is obviously the 4G wrap-around, and that the end address is outside the range. I guess you could put ROUNDUP(argc_addr, 0x10000)-1, but I'm not quite sure what happens if VG_(valgrind_end) isn't page-aligned. J |
|
From: Robert W. <rj...@du...> - 2004-04-22 23:41:25
|
On Wed, 2004-04-21 at 20:46, Jeremy Fitzhardinge wrote: > On Wed, 2004-04-21 at 17:13, Robert Walsh wrote: > > BTW: this patch doesn't actually break regular Valgrind-on-x86 in any > > way, so if it seems OK, I'll commit it in the next few days, after I've > > heard back from people. > > Hm, I'm not quite sure about this. I think there's a risk that this > will let Valgrind allocate a mapping in the last 64k of the address > space, which would be bad. > > The trouble here is obviously the 4G wrap-around, and that the end > address is outside the range. I guess you could put ROUNDUP(argc_addr, > 0x10000)-1, but I'm not quite sure what happens if VG_(valgrind_end) > isn't page-aligned. How about if 0xffffffff-argc_addr < 0x10000, then use 0xffffffff, else use ROUNDUP(argc_addr, 0x10000)? Regards, Robert. |
|
From: Paul M. <pa...@sa...> - 2004-04-23 07:35:05
|
Jeremy Fitzhardinge writes: > On Wed, 2004-04-21 at 17:13, Robert Walsh wrote: > > BTW: this patch doesn't actually break regular Valgrind-on-x86 in any > > way, so if it seems OK, I'll commit it in the next few days, after I've > > heard back from people. > > Hm, I'm not quite sure about this. I think there's a risk that this > will let Valgrind allocate a mapping in the last 64k of the address > space, which would be bad. > > The trouble here is obviously the 4G wrap-around, and that the end > address is outside the range. I guess you could put ROUNDUP(argc_addr, > 0x10000)-1, but I'm not quite sure what happens if VG_(valgrind_end) > isn't page-aligned. I came across this issue in porting Valgrind to PPC. Although I am only dealing with 32-bit code at the moment, I am running on a ppc64 kernel and thus the stack starts at 0xfffffff0 and goes downwards from there (32-bit processes on ppc64 get a full 4GB of address space). This the stack that stage1 uses initially, and which stage2 uses, not the client stack. This causes problems in the code which traverses the mappings in /proc/self/maps and sets up the skiplist of mappings, and gave me assertion failures in the skiplist code with the extremely informative message that the assertion `n == NULL || (l->cmp)(key_of_node(l, n), k) != 0' failed. :) I fixed it by basically making all the calculations that refer to the end of a range use addr + size - 1 rather than addr + size (i.e. an inclusive endpoint rather than an exclusive one) and adjusting the various comparisons etc. that use those values. I could pull out those changes separately from my other changes if there is interest. Paul. |