|
From: Andreas L. <al...@in...> - 2005-10-28 13:56:47
|
Hi all, Today I tried to use valgrind on my Debian Sarge system which has a custom linux 2.6.13.2 kernel running. That kernel is patched with Con Kolivas' 1g_lowmem patch available at http://ck.kolivas.org/patches/2.6/2.6.13/2.6.13-ck8/ \ patches/1g_lowmem1_i386.diff . The 1g lowmem option is turned on and the computer has 1GB RAM (indeed :-). Valgrind does not run with this configuration (not even "valgrind --help" ;-). Instead I see a message saying something like "memory not in the expected range" or so. To me this strongly seems to indicate there is something wrong with the 1g_lowmem's fiddling with the kernel/user level address space split. Although this is a relatively minor problem -- temporarily using a different kernel helps -- it is still not pretty. My question is: Is it feasible to make valgrind work with that 1g_lowmem option? Thanks, Andreas Leuner p.s. Please CC me in replies since I'm not subscribed to this list. |
|
From: Julian S. <js...@ac...> - 2005-10-28 14:05:23
|
> My question is: Is it feasible to make valgrind work with that 1g_lowmem > option? Ha. The new address space manager _should_ be able to deal with this. Try this: svn co svn://svn.valgrind.org/valgrind/trunk cd trunk ./autogen.sh configure and build as usual Whether it works or not, I would be interested to see the output of 'valgrind -d -d --tool=none date'. J |
|
From: Andreas L. <al...@in...> - 2005-10-30 15:39:58
|
> Try this: > > svn co svn://svn.valgrind.org/valgrind/trunk > cd trunk > ./autogen.sh > configure and build as usual > > Whether it works or not, I would be interested to see the output of > 'valgrind -d -d --tool=none date'. > I tried. Output consists of the following: ---------------------------------------------------------------------- $ valgrind -d -d --tool=none date --8734:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --8734:1:launcher tool 'none' requested --8734:1:launcher launching /usr/local/lib/valgrind/none Killed ---------------------------------------------------------------------- This doesn't seem to be of much use. Andreas Leuner |
|
From: Tom H. <to...@co...> - 2005-10-28 14:08:16
|
In message <342...@ma...>
Andreas Leuner <al...@in...> wrote:
> Today I tried to use valgrind on my Debian Sarge system which has a custom
> linux 2.6.13.2 kernel running. That kernel is patched with Con Kolivas'
> 1g_lowmem patch available at
> http://ck.kolivas.org/patches/2.6/2.6.13/2.6.13-ck8/ \
> patches/1g_lowmem1_i386.diff .
>
> The 1g lowmem option is turned on and the computer has 1GB RAM (indeed :-).
>
> Valgrind does not run with this configuration (not even "valgrind --help"
> ;-). Instead I see a message saying something like "memory not in the
> expected range" or so. To me this strongly seems to indicate there is
> something wrong with the 1g_lowmem's fiddling with the kernel/user level
> address space split.
Assuming that the patch in question restricts the user address space
to 1Gb (and I haven't looked at it) then released versions of valgrind
will not run in such a configuration as they try and load valgrind at
an address that is above 1Gb.
The latest SVN code may help as it allows for a much more flexible
arrangement of the address space but I suspect you will still have
problems as the default load address is probably too high - you can
tweak the KICKSTART_BASE value when you build valgrind to fix that
though and then it might work.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Andreas L. <al...@in...> - 2005-10-30 15:44:57
|
> Assuming that the patch in question restricts the user address space > to 1Gb (and I haven't looked at it) then released versions of valgrind > will not run in such a configuration as they try and load valgrind at > an address that is above 1Gb. AFAIK that patch does not restrict user address space but enlarges it from ( 1GB -128MB= ) 896MB and decreases the size of the kernel address space. Andreas Leuner |
|
From: Tom H. <to...@co...> - 2005-10-30 16:07:47
|
In message <489...@ma...>
"Andreas Leuner" <al...@in...> wrote:
> > Assuming that the patch in question restricts the user address space
> > to 1Gb (and I haven't looked at it) then released versions of valgrind
> > will not run in such a configuration as they try and load valgrind at
> > an address that is above 1Gb.
>
> AFAIK that patch does not restrict user address space but enlarges it from
> ( 1GB -128MB= ) 896MB and decreases the size of the kernel address space.
I did look at it later and all it said it did was allow 1 full 1Gb of
memory to be used with going into highmem mode. It didn't mention changing
the user/kernel address split at all, and the patch itself looked very
simple.
How much physical RAM you have, and how it is mapped, is of very little
importance to valgrind - the only thing it cares about is what virtual
addresses are available to user programs. Traditional x86 kernels usually
give either 2 or 3Gb to user programs and the reset to the kernel although
it is quite common now for all 4Gb to be given to the user - certainly
all recent RedHat/Fedora kernels seem ot be like that.
The basic problem is that valgrind has to load out of the way of where
normal programs load so that it can then load the main program in the
same process. Hence it is linked with a high load address to keep it out
of the way of normal programs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-10-28 14:14:21
|
> The latest SVN code may help as it allows for a much more flexible
> arrangement of the address space but I suspect you will still have
> problems as the default load address is probably too high - you can
> tweak the KICKSTART_BASE value when you build valgrind to fix that
> though and then it might work.
Ah yes, good point. So you can get a suitable load address by
messing with configure.in, and changing
valt_load_address_normal="0xb0000000"
to
valt_load_address_normal="0x30000000"
(then rerun ./autogen.sh and reconfigure and build).
J
|
|
From: Julian S. <js...@ac...> - 2005-10-28 15:10:59
|
How about if we change the default load address on x86, at least, to 0x3800'0000 (1G - 128M). That would make it work out of the box on all 1G/2G/3G/4G layouts. The downside is it would limit the size of the largest executable (not .so) we could load to 805M (0x38000000 - 0x8048000), but that's not a big deal, is it? J On Friday 28 October 2005 15:20, Julian Seward wrote: > > The latest SVN code may help as it allows for a much more flexible > > arrangement of the address space but I suspect you will still have > > problems as the default load address is probably too high - you can > > tweak the KICKSTART_BASE value when you build valgrind to fix that > > though and then it might work. > > Ah yes, good point. So you can get a suitable load address by > messing with configure.in, and changing > > valt_load_address_normal="0xb0000000" > > to > > valt_load_address_normal="0x30000000" > > (then rerun ./autogen.sh and reconfigure and build). > > J > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Andreas L. <al...@in...> - 2005-10-30 15:49:19
|
> >> The latest SVN code may help as it allows for a much more flexible >> arrangement of the address space but I suspect you will still have >> problems as the default load address is probably too high - you can >> tweak the KICKSTART_BASE value when you build valgrind to fix that >> though and then it might work. > > Ah yes, good point. So you can get a suitable load address by > messing with configure.in, and changing > > valt_load_address_normal="0xb0000000" > > to > > valt_load_address_normal="0x30000000" This seemed to work with my "1GB enabled" now 2.6.14 kernel. While current SVN HEAD didn't work as is, with the change of valt_load_address_normal it did. Thank you very much Andreas Leuner |
|
From: Julian S. <js...@ac...> - 2005-10-30 16:59:47
|
> This seemed to work with my "1GB enabled" now 2.6.14 kernel. While current > SVN HEAD didn't work as is, with the change of valt_load_address_normal it > did. Good. Just as a sanity check, please send the output of valgrind --tool=none -d -d date Thanks J |
|
From: Andreas L. <al...@in...> - 2005-10-31 15:24:57
Attachments:
vg.log
|
> Just as a sanity check, please send the output of > > valgrind --tool=none -d -d date > Here it is attached. Andreas Leuner |