|
From: pkr <pan...@ya...> - 2004-08-03 07:01:00
|
Hi,
Can somebody tell what could be the problem ?
I have a target host scenario. Valgrind is compiled on the host
and taken to the target.
Any workarounds ?
Thanks,
Pankaj
Linux(debug)# valgrind --version
valgrind-2.0.0
Linux(debug)# valgrind -v --logfile=/var/dpvm_mem_log /isan/bin/dpvm
<tons of symobls output...>
and finally
7113: symbol=__libc_waitpid; lookup in file=/lib/libc.so.6
7113: /usr/lib/valgrind/valgrind.so: error: relocation error:
symbol __libc_waitpid, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference (fatal)
/isan/bin/dpvm: relocation error: /usr/lib/valgrind/valgrind.so: symbol
__libc_waitpid, version GLIBC_PRIVATE not defined in file libc.so.6 with
link time reference
|
|
From: Tom H. <th...@cy...> - 2004-08-03 07:16:16
|
In message <cenct6$oua$1...@se...>
pan...@ya... wrote:
> Can somebody tell what could be the problem ?
> I have a target host scenario. Valgrind is compiled on the host
> and taken to the target.
> Any workarounds ?
Yes. Use a more recent version of valgrind that fixes this problem.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: pkr <pan...@ya...> - 2004-08-03 10:47:23
|
Unfortunately I cant do this as I dont have gcc 3.4 to compile the latest one. So I am wondering if there is a binary version of valigrind 2.1.2 available for download ? Is there a particular reason that binary versions are not made available for download ? Thanks, Pankaj Tom Hughes wrote: > In message <cenct6$oua$1...@se...> > pan...@ya... wrote: > > >>Can somebody tell what could be the problem ? >>I have a target host scenario. Valgrind is compiled on the host >>and taken to the target. >>Any workarounds ? > > > Yes. Use a more recent version of valgrind that fixes this problem. > > Tom > |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 11:01:18
|
On Tue, 3 Aug 2004, pkr wrote: > Unfortunately I cant do this as I dont have gcc 3.4 to compile > the latest one. Why do you need gcc 3.4? I use gcc 3.2.2 without any problems, and earlier ones should work too, AFAIK. > So I am wondering if there is a binary version of valigrind 2.1.2 available > for download ? Not from valgrind.kde.org. > Is there a particular reason that binary versions are not made available > for download ? Not really, but it's extra work for developers and nobody's ever complained about it before. N |
|
From: Pankaj R. <pan...@ya...> - 2004-08-03 11:21:06
|
--- Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 3 Aug 2004, pkr wrote:
>
> > Unfortunately I cant do this as I dont have gcc
> 3.4 to compile
> > the latest one.
>
> Why do you need gcc 3.4? I use gcc 3.2.2 without
> any problems, and
> earlier ones should work too, AFAIK.
>
<from valgrind homepage START>
Relative to 2.1.1, a large number of minor problems
have been fixed, and so if you use 2.1.1 you should
try 2.1.2. Users of the last stable release, 2.0.0,
might also want to try this release. For one thing,
2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't.
<from valgrind homepage END>
I did see a compile issue with gcc 3.3.2. (attached
below). I can tell u for sure that /usr/include/ files
were never touched.
Thanks
Pankaj
==============================================
gmake[4]: Entering directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle
-I../include -I../include -I./x86
-DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -Winline
-Wall -Wshadow -O -fno-omit-frame-pointer
-mpreferred-stack-boundary=2 -g -DELFSZ=32 -MT
vg_syscalls.o -MD -MP -MF ".deps/vg_syscalls.Tpo" -c
-o vg_syscalls.o vg_syscalls.c; \
then mv -f ".deps/vg_syscalls.Tpo"
".deps/vg_syscalls.Po"; else rm -f
".deps/vg_syscalls.Tpo"; exit 1; fi
In file included from vg_unsafe.h:65,
from vg_syscalls.c:35:
/usr/include/linux/timex.h:56: error: syntax error
before "and"
In file included from /usr/include/linux/timex.h:126,
from vg_unsafe.h:65,
from vg_syscalls.c:35:
/usr/include/asm/timex.h:33: error: syntax error
before "cacheflush_time"
/usr/include/asm/timex.h:35: error: syntax error
before "get_cycles"
gmake[4]: *** [vg_syscalls.o] Error 1
gmake[4]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2/coregrind'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/disk1/pankajkr/valgrind-2.1.2'
gmake: *** [all] Error 2
[root@andlx-pankajkr valgrind-2.1.2]# gcc --version
gcc (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE.
2
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 11:33:38
|
On Tue, 3 Aug 2004, Pankaj Rathore wrote: > <from valgrind homepage START> > Relative to 2.1.1, a large number of minor problems > have been fixed, and so if you use 2.1.1 you should > try 2.1.2. Users of the last stable release, 2.0.0, > might also want to try this release. For one thing, > 2.1.2 compiles with gcc-3.4.X, whereas 2.0.0 doesn't. > <from valgrind homepage END> I've reworded it: "For one thing, 2.1.2 can be compiled with gcc-3.4.X, whereas 2.0.0 cannot." Is that clearer? > I did see a compile issue with gcc 3.3.2. (attached > below). I can tell u for sure that /usr/include/ files > were never touched. That looks like a header bug, which you're likely to get no matter which gcc version you use. I'm no expert on header bugs, unfortunately. N |
|
From: James B. <ja...@ha...> - 2004-08-03 12:00:40
|
On Tue, 2004-08-03 at 11:33, Nicholas Nethercote wrote: > > I did see a compile issue with gcc 3.3.2. (attached > > below). I can tell u for sure that /usr/include/ files > > were never touched. > > That looks like a header bug, which you're likely to get no matter which > gcc version you use. I'm no expert on header bugs, unfortunately. Its a fedora core 1 bug, thats been discussed on this list before: http://article.gmane.org/gmane.comp.debugging.valgrind/1583 Cheers, James. -- James Begley |
|
From: pkr <pan...@ya...> - 2004-08-03 12:15:06
|
Nicholas Nethercote wrote: > On Tue, 3 Aug 2004, Pankaj Rathore wrote: > > I've reworded it: "For one thing, 2.1.2 can be compiled with gcc-3.4.X, > whereas 2.0.0 cannot." Is that clearer? > Gotcha, I was staring a bit too hard I guess. > > That looks like a header bug, which you're likely to get no matter which > gcc version you use. I'm no expert on header bugs, unfortunately. The same gcc compiles 2.0.0 which is what I was trying to use in the first place and landed into reloc error. Pankaj |
|
From: Nicholas N. <nj...@ca...> - 2004-08-03 12:56:21
|
On Tue, 3 Aug 2004, pkr wrote: >> That looks like a header bug, which you're likely to get no matter which >> gcc version you use. I'm no expert on header bugs, unfortunately. > > The same gcc compiles 2.0.0 which is what I was trying to use in the > first place and landed into reloc error. That's because 2.1.2 uses the header which is broken on FC1, whereas 2.0.0 doesn't. The gcc version is irrelevant. To summarise: - it shouldn't matter which gcc you use - using 2.1.2 should fix the bug you encountered with 2.0.0 - but you'll have to fix your broken header as Tom suggested to compile 2.1.2 HTH N |
|
From: pkr <pan...@ya...> - 2004-08-05 09:55:31
|
Hi,
I was able to compile 2.1.2 successfully.
However I now get different problem (attached below)
Any idea what could be causing this ?
TIA,
Pankaj
Linux(debug)# /usr/local/bin/valgrind -v --logfile=/var/dpvm_mem
/isan/bin/dpvm
Executable is mapped outside of range 0x80cd000-0x7ffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
Linux(debug)# strace -o /var/vg.strace /usr/local/bin/valgrind -v
--logfile=/var/dpvm_mem /isan/bin/dpvm
Executable is mapped outside of range 0x80cd000-0x7ffff000
failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
Linux(debug)# cat /var/vg.strace
execve("/usr/local/bin/valgrind", ["/usr/local/bin/valgrind", "-v",
"--logfile=/var/dpvm_mem", "/isan/bin/dpvm"], [/* 23 vars */]) = 0
uname({sys="Linux", node="rbadri-vegas13", ...}) = 0
brk(0) = 0x80cc5f8
brk(0x80ed5f8) = 0x80ed5f8
brk(0x80ee000) = 0x80ee000
getrlimit(0x9, 0x7ffff794) = 0
setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
open("/usr/local/lib/valgrind/stage2", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1674776, ...}) = 0
geteuid32() = 0
getegid32() = 0
getgroups32(0x20, 0x80c7f44) = 1
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0008\310"...,
4096, 0) = 4096
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0008\310"...,
52, 0) = 52
pread(3, "\6\0\0\0004\0\0\0004\0\0\2604\0\0\260\0\1\0\0\0\1\0\0\5"...,
256, 52) = 256
pread(3, "/lib/ld-linux.so.2\0", 19, 308) = 19
open("/lib/ld-linux.so.2", O_RDONLY|O_LARGEFILE) = 4
pread(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\n\0"...,
52, 0) = 52
pread(4, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\217C\1\0\217C\1\0\5\0"...,
96, 52) = 96
write(2, "Executable is mapped outside of "..., 59) = 59
close(3) = 0
write(2, "failed to load /usr/local/lib/va"..., 70) = 70
semget(1, 0, 0) = -1 ENOSYS (Function not
implemented)
_exit(1) = ?
Linux(debug)# ulimit -a
core file size (blocks, -c) 48828
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 32000
cpu time (seconds, -t) unlimited
max user processes (-u) 8151
virtual memory (kbytes, -v) unlimited
Nicholas Nethercote wrote:
> On Tue, 3 Aug 2004, pkr wrote:
> To summarise:
> - it shouldn't matter which gcc you use
> - using 2.1.2 should fix the bug you encountered with 2.0.0
> - but you'll have to fix your broken header as Tom suggested to compile
> 2.1.2
>
> HTH
>
> N
|
|
From: Tom H. <th...@cy...> - 2004-08-05 10:10:32
|
In message <411...@ya...>
pan...@ya... wrote:
> Linux(debug)# /usr/local/bin/valgrind -v --logfile=/var/dpvm_mem
> /isan/bin/dpvm
> Executable is mapped outside of range 0x80cd000-0x7ffff000
> failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory
Have you linked your program with an unusual load address?
Unfortunately in order to use valgrind your program will need to have
a load address in the range that valgrind reported. Normally linked
programs should fit that criteria though.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 10:31:35
|
On Thu, 5 Aug 2004, Tom Hughes wrote: >> Linux(debug)# /usr/local/bin/valgrind -v --logfile=/var/dpvm_mem >> /isan/bin/dpvm >> Executable is mapped outside of range 0x80cd000-0x7ffff000 >> failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory > > Have you linked your program with an unusual load address? > > Unfortunately in order to use valgrind your program will need to have > a load address in the range that valgrind reported. Normally linked > programs should fit that criteria though. I don't think that's the problem. The problem is that the stack ends at 0x7fffffff, instead of the normal place 0xbfffffff. So Valgrind thinks that everything above 0x7fffffff is untouchable. Thus, it refuses to load stage2 at 0xb0000000, where it wants to. So the question is: why is the stack at 0x7fffffff? And can Valgrind safely use the memory above there or not? Pankaj, do you know why this would be? Is your system setup so user programs get 2GB of address space, and the kernel gets 2GB? (The most common setup is 3GB user, 1GB kernel.) I'm sorry that you're having so many difficulties, I hope we can work out the problem. N |
|
From: pkr <pan...@ya...> - 2004-08-05 10:54:16
|
Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Tom Hughes wrote: > > Pankaj, do you know why this would be? Is your system setup so user > programs get 2GB of address space, and the kernel gets 2GB? (The most > common setup is 3GB user, 1GB kernel.) My system only has 1 GB. But something similar to what you suggest is not ruled out. (As we have a memory mapped IPC system (proprietory) which reserves some huge amout of memory during kernel init) > > I'm sorry that you're having so many difficulties, It is ok. Not a problem. I hope we can work out the problem. > Let me know what info should I provide to go ahead. Thanks, Pankaj |
|
From: Tom H. <th...@cy...> - 2004-08-05 11:03:20
|
In message <411...@ya...>
pan...@ya... wrote:
> Nicholas Nethercote wrote:
>
> > Pankaj, do you know why this would be? Is your system setup so user
> > programs get 2GB of address space, and the kernel gets 2GB? (The
> > most common setup is 3GB user, 1GB kernel.)
>
> My system only has 1 GB. But something similar to what you suggest is
> not ruled out. (As we have a memory mapped IPC system (proprietory)
> which reserves some huge amout of memory during kernel init)
It isn't a question of how much physical memory you have, it's how the
address space is split between the user space and the kernel space.
The normal split is 3Gb to user space and 1Gb to kernel although some
systems now give the whole 4Gb to user space. You can also build the
kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each
which is what it looks like your system is doing.
Like you say, this is probably related to your IPC system needing
extra kernel address space.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 11:17:37
|
On Thu, 5 Aug 2004, Tom Hughes wrote: >> My system only has 1 GB. But something similar to what you suggest is >> not ruled out. (As we have a memory mapped IPC system (proprietory) >> which reserves some huge amout of memory during kernel init) > > It isn't a question of how much physical memory you have, it's how the > address space is split between the user space and the kernel space. > > The normal split is 3Gb to user space and 1Gb to kernel although some > systems now give the whole 4Gb to user space. You can also build the > kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each > which is what it looks like your system is doing. > > Like you say, this is probably related to your IPC system needing > extra kernel address space. Yes, sounds like it. I'd be interested to see what /proc/self/maps looks like for a typical process. Pankaj, can you run "vim /proc/self/maps" or something similar, and post the results? Thanks. ---- Ultimately, I think the full virtualisation of the address space introduced in 2.1.1 has enough problems in tricky cases like this that we should be prepared to consider a fall-back scheme that operates more like 2.0.0, whereby valgrind's memory and the client's memory are mixed up much more. Eg. if you specified --pointer-check=no. This does have disadvantages -- eg. a buggy client can trash Valgrind's memory -- but it seems like there's a small fraction of programs for which the current approach is just too rigid. This could be difficult, though. (Nb: "full virtualisation" is not an accurate name, we haven't virtualised the address space, just partioned it.) N |
|
From: pkr <pan...@ya...> - 2004-08-05 12:10:45
|
Ok, 2 pieces of info. 1. As Nick guessed earlier, the kernel is configured for 4GB and 2GBuser/2GB kernel . from make menuconfig of our kernel. ======================================== <*> /dev/cpu/*/cpuid - CPU information support (4GB) High Memory Support [ ] HIGHMEM I/O support (NEW) (2GB) User address space size [ ] Math emulation [*] MTRR (Memory Type Range Register) support ======================================= 2. output of cat /proc/self/maps Linux(debug)# cat /proc/self/ cmdline environ fd mem root statcpu statpages cwd exe maps mounts stat statm status Linux(debug)# cat /proc/self/maps 08048000-0804b000 r-xp 00000000 00:000007 30 /bin/cat 0804b000-0804c000 rw-p 00002000 00:000007 30 /bin/cat 0804c000-0804d000 rwxp 00000000 00:000000 0 2aaab000-2aac0000 r-xp 00000000 00:000007 828 /lib/ld-2.3.2.so 2aac0000-2aac1000 rw-p 00014000 00:000007 828 /lib/ld-2.3.2.so 2aac1000-2aac2000 rw-p 00000000 00:000000 0 2aac4000-2abfb000 r-xp 00000000 00:000007 835 /lib/libc-2.3.2.so 2abfb000-2abff000 rw-p 00136000 00:000007 835 /lib/libc-2.3.2.so 2abff000-2ac02000 rw-p 00000000 00:000000 0 7fffe000-80000000 rwxp fffff000 00:000000 0 Let me know if there could be a fix from valgrind. Thanks, Pankaj Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Tom Hughes wrote: > >>> My system only has 1 GB. But something similar to what you suggest is >>> not ruled out. (As we have a memory mapped IPC system (proprietory) >>> which reserves some huge amout of memory during kernel init) >> >> >> It isn't a question of how much physical memory you have, it's how the >> address space is split between the user space and the kernel space. >> >> The normal split is 3Gb to user space and 1Gb to kernel although some >> systems now give the whole 4Gb to user space. You can also build the >> kernel to give 1Gb to the user and 3Gb to the kernel or 2Gb to each >> which is what it looks like your system is doing. >> >> Like you say, this is probably related to your IPC system needing >> extra kernel address space. > > > Yes, sounds like it. > > I'd be interested to see what /proc/self/maps looks like for a typical > process. Pankaj, can you run "vim /proc/self/maps" or something > similar, and post the results? Thanks. > > ---- > > Ultimately, I think the full virtualisation of the address space > introduced in 2.1.1 has enough problems in tricky cases like this that > we should be prepared to consider a fall-back scheme that operates more > like 2.0.0, whereby valgrind's memory and the client's memory are mixed > up much more. Eg. if you specified --pointer-check=no. This does have > disadvantages -- eg. a buggy client can trash Valgrind's memory -- but > it seems like there's a small fraction of programs for which the current > approach is just too rigid. This could be difficult, though. > > (Nb: "full virtualisation" is not an accurate name, we haven't > virtualised the address space, just partioned it.) > > N > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 12:26:43
|
On Thu, 5 Aug 2004, pkr wrote: > 2 pieces of info. > 1. As Nick guessed earlier, the kernel is configured for 4GB and 2GBuser/2GB > kernel . > > Let me know if there could be a fix from valgrind. Try this: - in coregrind/stage1.c, change "info.mapbase" on line 181 from 0xb1000000 to 0x71000000. - in coregrind/Makefile, change "kickstart_base" from 0xb0000000 to 0x70000000. - re-make Valgrind I found that Memcheck and Helgrind do not work under this setup, because they cannot load libraries at 0x40000000 as they want to -- the tools reserve too much of the 2GB address space for themselves. However, Addrcheck, Cachegrind and Massif do work, as they need less space for themselves, which is a start. Note that if you try running big programs under Valgrind, you might run out of memory, as the system doesn't have that much to play with. It really would be nice to improve on this situation. N |
|
From: Oswald B. <os...@kd...> - 2004-08-05 12:40:40
|
On Thu, Aug 05, 2004 at 01:26:37PM +0100, Nicholas Nethercote wrote: > Try this: > > - in coregrind/stage1.c, change "info.mapbase" on line 181 from 0xb1000000 > to 0x71000000. > > - in coregrind/Makefile, change "kickstart_base" from 0xb0000000 to > 0x70000000. > > - re-make Valgrind > i did this a few days ago (with 0xa0000000) to accomodate the PAGE_OFFSET change i did to be able to use the whole 1 gig of ram without compiling linux for highmem. memcheck works like a charm. i was pondering with the idea of submitting a configure patch, for either manually specifying the load address or auto-detecting it, but now that you plan to take care of this yourself ... ;) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 12:56:24
|
On Thu, 5 Aug 2004, Oswald Buddenhagen wrote:
> i did this a few days ago (with 0xa0000000) to accomodate the
> PAGE_OFFSET change i did to be able to use the whole 1 gig of ram
> without compiling linux for highmem. memcheck works like a charm.
I don't know what the PAGE_OFFSET change is (is it relevant to Valgrind?)
but thanks for the data point, it's useful to know of another possible
memory layout.
> i was pondering with the idea of submitting a configure patch, for
> either manually specifying the load address or auto-detecting it, but
> now that you plan to take care of this yourself ... ;)
Hmm, yes, I'm thinking about ways to improve this. I guess the ideal
thing is to auto-detect the highest addresses available, and put valgrind
there -- be it at:
0xb0000000--0xbfffffff on typical 3G/1G systems
0x70000000--0x7fffffff on 2G/2G systems
0xf0000000--0xffffffff on 4G systems
0xa0000000--0xafffffff for your PAGE_OFFSET thingy
or somewhere else.
I think this highest address can always be determined by looking at where
the stack is... so stage1 should find this place, and then load stage2 in
the found place (ignoring where the elf info says it should go), and tell
stage2 where it is loaded by via the auxv...
N
|
|
From: Oswald B. <os...@kd...> - 2004-08-05 13:04:48
|
On Thu, Aug 05, 2004 at 01:56:20PM +0100, Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: > >i did this a few days ago (with 0xa0000000) to accomodate the > >PAGE_OFFSET change i did to be able to use the whole 1 gig of ram > >without compiling linux for highmem. memcheck works like a charm. > > I don't know what the PAGE_OFFSET change is (is it relevant to Valgrind?) > PAGE_OFFSET is the kernel #define for the kernel/user space split. theoretically it can be set to about anything (except if you want hugetlb support, in which case it must be 1gb-aligned) ... > I think this highest address can always be determined by looking at where > the stack is... > not sure. some redhat kernel patches change the stack location. a binary search with fixed-address-mmaps could work. > so stage1 should find this place, and then load stage2 in the found > place (ignoring where the elf info says it should go), and tell stage2 > where it is loaded by via the auxv... > yup, but then stage2 has to be compiled with -fPIC. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 13:33:31
|
On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: >> so stage1 should find this place, and then load stage2 in the found >> place (ignoring where the elf info says it should go), and tell stage2 >> where it is loaded by via the auxv... >> > yup, but then stage2 has to be compiled with -fPIC. Urgh, that's not so good. Or maybe it's not a problem -- what's the slow-down for PIC usually like? Does anyone know if it would it affect any other part of Valgrind's workings, eg. symbol redirections? I guess I can try and see what happens. We use PIC for libpthread.so and a few other Valgrind files already. Another possibility is to build multiple versions of Valgrind, and choose the most appropriate one. That's less flexible though. Or Valgrind could do a configure-time test to find out what the configuration is, and hope that never changes... N |
|
From: Oswald B. <os...@kd...> - 2004-08-05 14:12:04
|
On Thu, Aug 05, 2004 at 02:33:22PM +0100, Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: > > >>so stage1 should find this place, and then load stage2 in the found > >>place (ignoring where the elf info says it should go), and tell stage2 > >>where it is loaded by via the auxv... > >> > >yup, but then stage2 has to be compiled with -fPIC. > > Urgh, that's not so good. Or maybe it's not a problem -- > what's the slow-down for PIC usually like? > supposedly about 1-2%. it depends on how many global symbols you reference. it could well be, that export scope specifiers for functions would make the overhead for internal function calls zero (relative jumps are a cool thing, huh? :). > Does anyone know if it would it affect any other part of Valgrind's > workings, eg. symbol redirections? > dunno. prolly not much. some asm code would need to be made relocatable by hand, probably. > Another possibility is to build multiple versions of Valgrind, and > choose the most appropriate one. That's less flexible though. > and ugly by design ... > Or Valgrind could do a configure-time test to find out what the > configuration is, and hope that never changes... > well, that was my original idea. not so good for distributors, though. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-05 14:34:24
|
On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: >> Or Valgrind could do a configure-time test to find out what the >> configuration is, and hope that never changes... >> > well, that was my original idea. not so good for distributors, though. Why is it bad for distributors? N |
|
From: Oswald B. <os...@kd...> - 2004-08-05 14:50:28
|
On Thu, Aug 05, 2004 at 03:34:12PM +0100, Nicholas Nethercote wrote: > On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: > > >>Or Valgrind could do a configure-time test to find out what the > >>configuration is, and hope that never changes... > >> > >well, that was my original idea. not so good for distributors, though. > > Why is it bad for distributors? > multiple kernels (with different PAGE_OFFSETs), one valgrind (configured for a specific PAGE_OFFSET). hmmm ... sure, it's not different from the current situation, so i don't expect the stream of puzzled failure reports to widen ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@ca...> - 2004-08-09 13:28:49
|
On Thu, 5 Aug 2004, Oswald Buddenhagen wrote: >> Why is it bad for distributors? >> > multiple kernels (with different PAGE_OFFSETs), one valgrind (configured > for a specific PAGE_OFFSET). hmmm ... > sure, it's not different from the current situation, so i don't expect > the stream of puzzled failure reports to widen ... I'm not sure I understand. If it's set up at configure-time, why is it a problem for distributors? The only problem I can see with a configure-time setup is if a person has more than one kernel on the same system, or changes their kernel's memory layout. But Valgrind could check at startup that the memory layout matches what it saw at configure-time, and abort/warn if it doesn't. Or is there a problem here that I'm not seeing? N |