Hello,
we ported our huge ILS application on Solaris SPARC:
$ uname -a
SunOS srap01dxle 5.10 Generic_150400-35 sun4u sparc SUNW,SPARC-Enterprise
with gcc
$ /usr/local/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --prefix=/usr/local/gcc4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++ --without-gnu-ld
Thread model: posix
gcc version 4.4.2 (GCC)
from 32-bit to 64-bit (using -m64 as flag). We are not surprised about
the fact that the applications are now much bigger in RAM (sometimes factor 2),
esp. when they use large arrays of 'long' or pointers, which are now
8 byte long. We still dig into some source changes to use 'int' and not
'long', but this is another story.
What I can not explain me (and our clients), why shared TXT segments are
growing too, for example in the output of pmap(1):
32-bit:
$ fgrep libdbcall.so pmap.ops44.txt
F8000000 32768K r-x-- /data/sisisroot/lib/syb157/libdbcall.so
FA000000 2464K r-x-- /data/sisisroot/lib/syb157/libdbcall.so
FA276000 56K rwx-- /data/sisisroot/lib/syb157/libdbcall.so
FA284000 2848K rwx-- /data/sisisroot/lib/syb157/libdbcall.so
64-bit:
$ fgrep libdbcall.so pmap.ops45.txt
FFFFFFFF70000000 65536K r-x-- /opt/lib/sisis/lib/syb157/libdbcall.so
FFFFFFFF74000000 1096K r-x-- /opt/lib/sisis/lib/syb157/libdbcall.so
FFFFFFFF74210000 72K rwx-- /opt/lib/sisis/lib/syb157/libdbcall.so
FFFFFFFF74222000 2864K rwx-- /opt/lib/sisis/lib/syb157/libdbcall.so
note the TXT r-x-- segment which was 32768K on 32-bit and is 65536K;
I can even see this with a very simple C-snip:
$ cat code.c
void exit(int);
main()
{
int i;
i = 1;
exit(i);
}
$ gcc -ansi -c code.c
$ ls -l code.o
-rw-r--r-- 1 guru scdev 624 Oct 27 11:17 code.o
$ gcc -m64 -mcmodel=medany -ansi -c code.c
$ ls -l code.o
-rw-r--r-- 1 guru scdev 872 Oct 27 11:17 code.o
Why is the *.o file much bigger for 64-bit?
Thanks
matthias
--
Matthias Apitz, ✉ guru@xxxxxxxxxxx, ⌂ http://www.unixarea.de/ ☎ +49-176-38902045
