|
From: Sefer T. <se...@ho...> - 2004-10-14 09:17:19
|
Hi,
There is a certain bug in Valgrind, ranging from Valgrind 2.2.0 and
throughout the HEAD cvs branch.
It's a result of redefinition of certain structures (on certain
architectures, like the newest Mandrake distribution 10.1 and possibly
others).
The file "vg_unsafe.h" includes both <linux/mii.h> and <net/if.h> however,
it appears that mii.h also includes <linux/if.h> (which conflicts with
<net/if.h> because they define the structures but use different preprocessor
defines to exclude their reprocessing - _LINUX_IF_H_ and _LINUX_NET_H_)
There are a few obvious solutions to this, like:
First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
Second, add in "vg_unsafe.h" just before (to make sure that the second if.h
version is included):
#define _LINUX_IF_H_
include <linux/mii.h>
Both seems to work and make valgrind compile and work just fine.
Can you please add one of these solution to the cvs head, so that the
upcoming releases would compile on newer Linux distros?
Thanks,
Sefer.
Here is the error I was getting consistently for the past couple of weeks.
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I../coregrind
-I../coregrind/x86 -I../coregrind/x86-linux -I../include -I../include
-I../include/x86 -DVG_LIBDIR="\"/opt/valgrind/lib/valgrind"\" -I./demangle
-DKICKSTART_BASE=0xb0000000 -DVG_PLATFORM="\"x86-linux"\" -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 `test -f 'vg_syscalls.c' || echo './'`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 /usr/include/linux/msg.h:5,
from vg_unsafe.h:57,
from vg_syscalls.c:35:
/usr/include/linux/list.h:685:2: warning: #warning "don't include kernel
headers in userspace"
In file included from /usr/include/linux/mii.h:12,
from vg_unsafe.h:77,
from vg_syscalls.c:35:
/usr/include/linux/if.h:95: error: redefinition of `struct ifmap'
/usr/include/linux/if.h:131: error: redefinition of `struct ifreq'
/usr/include/linux/if.h:181: error: redefinition of `struct ifconf'
make[4]: *** [vg_syscalls.o] Error 1
make[4]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/sefer/t/valgrind/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sefer/t/valgrind'
make: *** [all] Error 2
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/
|
|
From: Tom H. <th...@cy...> - 2004-10-14 09:54:15
|
In message <BAY...@ho...>
Sefer Tov <se...@ho...> wrote:
> The file "vg_unsafe.h" includes both <linux/mii.h> and <net/if.h>
> however, it appears that mii.h also includes <linux/if.h> (which
> conflicts with <net/if.h> because they define the structures but use
> different preprocessor defines to exclude their reprocessing -
> _LINUX_IF_H_ and _LINUX_NET_H_)
I reordered the includes recently to try and resolve this problem
and I thought somebody had confirmed that CVS was OK now.
> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
> Second, add in "vg_unsafe.h" just before (to make sure that the second
> if.h version is included):
> #define _LINUX_IF_H_
> include <linux/mii.h>
Neither of these is a good idea - the two file do two different things
and there is no guarantee that the structures will be the same. One is
the user visible structure for the glibc interface and one is the kernel
visible structure for the system call interface.
The whole issue of the kernel interface and which headers to use is a
complete swamp that Nick is looking at.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-10-14 10:36:42
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 14 Oct 2004, Tom Hughes wrote:
>
>>> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h>
>>> Second, add in "vg_unsafe.h" just before (to make sure that the second
>>> if.h version is included):
>>> #define _LINUX_IF_H_
>>> include <linux/mii.h>
>>
>> Neither of these is a good idea - the two file do two different things
>> and there is no guarantee that the structures will be the same. One is
>> the user visible structure for the glibc interface and one is the kernel
>> visible structure for the system call interface.
>
> I thought the first option seemed ok... and that the same thing should
> really be done for pretty much every non-kernel header mentioned in
> vg_unsafe.h -- it should be replaced with the equivalent kernel header.
> Tom, can you explain further why the first option is bad?
Actually I think you're right - the first option is the way to go.
I had thought it was the other way around - that we were including
the kernel header and some other header was including the glibc header
but obviously not.
Assuming that we're only using it for the system call interface then
it should be the kernel header that we pull in.
>> The whole issue of the kernel interface and which headers to use is a
>> complete swamp that Nick is looking at.
>
> Yes, I haven't come to grips with it yet. However, it seems like our
> copying of parts of kernel files and prefixing with vki/VKI is
> ultimately not a good idea, because the types/macros can change over
> time. What seems to be the right way to do things is to just use the
> kernel headers installed on the system. But then we have to be very
> careful not to mix up glibc and kernel types/macros; this could be
> done by just never using glibc, althought that will be hard in
> general, as we already rely on it somewhat.
As far as the system call interface goes we should probably use the
kernel headers and just make sure that vg_syscalls.c never includes
any glibc headers.
For other parts of the system we may still have to use vki versions
because so that we can pull in glibc headers as necessary I guess.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dennis L. <pla...@gm...> - 2004-10-18 10:39:40
|
At 12:07 18.10.2004, you wrote: >On Thu, 14 Oct 2004, Tom Hughes wrote: > >>As far as the system call interface goes we should probably use the >>kernel headers and just make sure that vg_syscalls.c never includes >>any glibc headers. >> >>For other parts of the system we may still have to use vki versions >>because so that we can pull in glibc headers as necessary I guess. > >This seems to me the right approach. But I'm worried that kernel headers >are not very reliable, because they seem to often be broken (Sefer Tov in >particular has had numerous problems). Also, sometimes they seem to have >warnings in them saying "don't include in userspace". I don't want to >commit these changes and then cause us lots of future compile problems. Do >people think that the kernel headers are sufficiently reliable that we can >rely on them more heavily than now? From my experiences with kernel headers, theyre reliable enough. Changes are made in the rc kernels first, so there is enough time to adopt valgrind to changes, if any important. They are mostly kept backwards compatible. But thats for vanilla kernels only. I have seen distro kernels where the header structures were completely different... dont know about them, but really, I personally would not worry... greets Dennis Carpe quod tibi datum est |
|
From: Nicholas N. <nj...@ca...> - 2004-10-14 10:32:41
|
On Thu, 14 Oct 2004, Tom Hughes wrote: >> First, change in "vg_unsafe.h" the include from <net/if.h> to <linux/if.h> >> Second, add in "vg_unsafe.h" just before (to make sure that the second >> if.h version is included): >> #define _LINUX_IF_H_ >> include <linux/mii.h> > > Neither of these is a good idea - the two file do two different things > and there is no guarantee that the structures will be the same. One is > the user visible structure for the glibc interface and one is the kernel > visible structure for the system call interface. I thought the first option seemed ok... and that the same thing should really be done for pretty much every non-kernel header mentioned in vg_unsafe.h -- it should be replaced with the equivalent kernel header. Tom, can you explain further why the first option is bad? > The whole issue of the kernel interface and which headers to use is a > complete swamp that Nick is looking at. Yes, I haven't come to grips with it yet. However, it seems like our copying of parts of kernel files and prefixing with vki/VKI is ultimately not a good idea, because the types/macros can change over time. What seems to be the right way to do things is to just use the kernel headers installed on the system. But then we have to be very careful not to mix up glibc and kernel types/macros; this could be done by just never using glibc, althought that will be hard in general, as we already rely on it somewhat. N |
|
From: Nicholas N. <nj...@ca...> - 2004-10-18 10:07:59
|
On Thu, 14 Oct 2004, Tom Hughes wrote: > As far as the system call interface goes we should probably use the > kernel headers and just make sure that vg_syscalls.c never includes > any glibc headers. > > For other parts of the system we may still have to use vki versions > because so that we can pull in glibc headers as necessary I guess. I have been looking into this some more. Julian and I think that having our own vki_/VKI_ copies of kernel header types and constants is just not the right way to do things. First, because it's a pain to write the file containing them for each new platform. And second, because the types do change slowly over time -- I saw this when I tried rewriting vg_kerneliface.h last week. I think using the kernel headers directly is the right solution. We then have to be very careful that no file includes both kernel headers and glibc headers. It's a shame that C's namespace control is so primitive; splitting files is the only way to control this, that I'm aware of. In general, I think the old approach of avoiding glibc wherever possible will make this easiest; we use glibc in quite a few places now, but many of the uses can be removed pretty easily. Some glibc things (esp. dlopen() and friends) will be hard to remove, but code requiring them could be partitioned into separate files as necessary. I've completely rewritten vg_unsafe.h to use entirely kernel headers. This meant that a number of the vki_/VKI_ types and constants in vg_kerneliface.h could be removed. It works well on the machines I've tried. This seems to me the right approach. But I'm worried that kernel headers are not very reliable, because they seem to often be broken (Sefer Tov in particular has had numerous problems). Also, sometimes they seem to have warnings in them saying "don't include in userspace". I don't want to commit these changes and then cause us lots of future compile problems. Do people think that the kernel headers are sufficiently reliable that we can rely on them more heavily than now? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-10-18 11:03:35
|
On Mon, 18 Oct 2004, Dennis Lubert wrote: > From my experiences with kernel headers, theyre reliable enough. Changes are > made in the rc kernels first, so there is enough time to adopt valgrind to > changes, if any important. They are mostly kept backwards compatible. But > thats for vanilla kernels only. I have seen distro kernels where the header > structures were completely different... dont know about them, but really, I > personally would not worry... I just tried my changes -- which were developed on a machine with a 2.4.22 kernel -- on a machine with a 2.6.5 kernel, and am getting a bazillion errors... [sigh] N |
|
From: Dennis L. <pla...@tz...> - 2004-10-18 11:40:46
|
Am Mo, den 18.10.2004 schrieb Nicholas Nethercote um 13:03: > On Mon, 18 Oct 2004, Dennis Lubert wrote: > > > From my experiences with kernel headers, theyre reliable enough. Changes are > > made in the rc kernels first, so there is enough time to adopt valgrind to > > changes, if any important. They are mostly kept backwards compatible. But > > thats for vanilla kernels only. I have seen distro kernels where the header > > structures were completely different... dont know about them, but really, I > > personally would not worry... > > I just tried my changes -- which were developed on a machine with a 2.4.22 > kernel -- on a machine with a 2.6.5 kernel, and am getting a bazillion > errors... [sigh] > Hm, perhaps you can create a CVS Branch with your changes, so some people can look what they would need to do to make it compile (and work). I suspect that for some things we would need a #ifdef check for 2.4/2.6 since in the parts valgrind uses are many many changes between those... for the questions which headers to include for what, there could be a configure test. For the other things, we should look what differences are there out on users systems.... just my thoughts about this... greets Dennis |