Date: Fri, 11 Apr 2003 14:10:22 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Gianmarco Giovannelli <gmarco@giovannelli.it> Cc: hackers@freebsd.org Subject: Re: gcc iussue or ... ? Message-ID: <3E972F3E.8E86140E@mindspring.com> References: <5.2.0.9.2.20030411082040.02604e90@194.184.65.4> <5.2.0.9.2.20030411221904.011c5ec8@194.184.65.4>
next in thread | previous in thread | raw e-mail | index | archive | help
Gianmarco Giovannelli wrote: > >The first, and least likely, since the same compiler and linker > >is used on both FreeBSD and Linux, is that the uninitialized BSS > >handling for some large static/global declarations is being handled > >differently between the platforms. > > Ok... I think it could not be related to the problem ... the same gcc on > debian 3.0 and FreeBSD 4.8 (2.95.x) and the same on mingw and FreeBSD 5.0 > (3.2.x) produce differents size code (linux vs 4.8 and mingw vs 5.0). Someone has already pointed out that one of the .o files is, in fact, handling uninitialized data differently on FreeBSD and Linux, so this is the source of your problem. I thought it was the lowest priority possibility, but I guess I was wrong. The best fix for it is to do as he suggested, and to allocate these things with malloc() at startup time, instead of declaring them static. That will also avoid the problem in the future on other platforms. As far as the handling difference, I don't know why it happens, and you are probably not going to find out, unless you objdump both the FreeBSD .o file he pointed out and the comparable Linux .o file, and find out what the differences are. Technically, the compiler should be generating the same code on both platforms, and, apart from header manifest constants and the date stamp, the code that gets generated should be identical. > >The second, which is more likely, is that there are some large > >static/global declaractions that get initialized on FreeBSD, but > >not on Linux. The way to find this is to search for platform > >"#ifdef"'s in the code. > > There are none of them ... I have tried to search but there aren't or afaik > I was not able to find them :-) There are. There is one .o file that, by itself, is over 2M in size in FreeBSD. Examining the source for that file should tell you. It occurs to me that you might be using the "-g" flag in FreeBSD; maybe you put something in make.conf? One potential source of this, which is non-obvious, is the static sonstruction of objects (e.g. define a class, and then globally declare an instance). I don't know why the handling should be different than Linux, but it could be. > freebsd:> ldd lonewolf > libstdc++.so.3 => /usr/lib/libstdc++.so.3 (0x282be000) > libm.so.2 => /usr/lib/libm.so.2 (0x28303000) > libc.so.4 => /usr/lib/libc.so.4 (0x2831e000) > > linux:>ldd lonewolf > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0x40016000) > libm.so.6 => /lib/libm.so.6 (0x4005f000) > libc.so.6 => /lib/libc.so.6 (0x40081000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Uhm... I am not able to interpret this data. Are they ok ? FreeBSD is > missing one lib, the last one... Ignore this; it's unrelated. This is a Linux-ism for ld.so; they do this so they can support dlopen(), etc., in static binaries. > The problem of Makefile is not related IMHO, infact the Makefile.unix is > the same for Linux and FreeBSD ... the most relevant part of it are: See also /etc/make.conf, which can override this or add more options. > So they should act in the same way ... > > The thing is so strange ... It's uninitialized data. You would need to look at the object file that the other person posted about earlier, in detail (as noted above) in order to identify the root cause. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E972F3E.8E86140E>