From: Alexander Larsson <a...@cendio.se>
Subject: Why is linux binaries 50% larger than win32?
Date: 1999/06/10
Message-ID: <w1ogioo4xr.fsf@tammy.signum.se>#1/1
X-Deja-AN: 487825903
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters
I've been looking a bit at the size of the linux mozilla binaries. It
seems they are about 50% larger than the win32 versions. Does anyone
know why this is?
I've built binutils with support for win32 binaries, and i intend to
check this out a bit. But if anyone knows that cause of this, please
tell me so i don't waste my time.
/ Alex
From: Scott MacGregor <msc...@netscape.com>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/10
Message-ID: <375FFE74.66E21D14@netscape.com>#1/1
X-Deja-AN: 488000203
References: <w1ogioo4xr.fsf@tammy.signum.se>
X-Accept-Language: en
Content-Type: multipart/alternative;
boundary="------------4BA8A6605A049BFFB91B7622"
Organization: mozilla.org
Mime-Version: 1.0
Newsgroups: netscape.public.mozilla.performance.size-matters
--------------4BA8A6605A049BFFB91B7622
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I don't think anyone knows yet. At least in mailnews, we've been
scratching are heads on this one for a while. I believe we have a bug to
tracking the problem for mailnews here:
Bugzilla bug 7623
I'm sure we'd appreciate any insight you might have on the problem..
-Scott
Alexander Larsson wrote:
> I've been looking a bit at the size of the linux mozilla binaries. It
> seems they are about 50% larger than the win32 versions. Does anyone
> know why this is?
>
> I've built binutils with support for win32 binaries, and i intend to
> check this out a bit. But if anyone knows that cause of this, please
> tell me so i don't waste my time.
>
> / Alex
--------------4BA8A6605A049BFFB91B7622
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I don't think anyone knows yet. At least in mailnews, we've been scratching
are heads on this one for a while. I believe we have a bug to tracking
the problem for mailnews here:
<br> <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=7623">Bugzilla
bug 7623</a>
<p>I'm sure we'd appreciate any insight you might have on the problem..
<p>-Scott
<p>Alexander Larsson wrote:
<blockquote TYPE=CITE>I've been looking a bit at the size of the linux
mozilla binaries. It
<br>seems they are about 50% larger than the win32 versions. Does anyone
<br>know why this is?
<p>I've built binutils with support for win32 binaries, and i intend to
<br>check this out a bit. But if anyone knows that cause of this, please
<br>tell me so i don't waste my time.
<p>/ Alex</blockquote>
</html>
--------------4BA8A6605A049BFFB91B7622--
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/11
Message-ID: <w1iu8vjfj6.fsf@tammy.cendio.se>
X-Deja-AN: 488317849
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Scott MacGregor <msc...@netscape.com> writes:
> Alexander Larsson wrote:
>
> > I've been looking a bit at the size of the linux mozilla binaries. It
> > seems they are about 50% larger than the win32 versions. Does anyone
> > know why this is?
>
> I don't think anyone knows yet. At least in mailnews, we've been
> scratching are heads on this one for a while. I believe we have a bug to
> tracking the problem for mailnews here:
> Bugzilla bug 7623
>
> I'm sure we'd appreciate any insight you might have on the problem..
After looking at it for a while i've come to belive that the cause of
the is differences in the ELF format used for linux shared libraries
and the PEI format used for win32 dll's.
There is basically two main causes:
First ELF libraries are compiled with position independent code so
that the code section can be read-only and truly shared between all
processes that links to it. Win32 on the other hand uses a relocation
scheme so that if a process opens a dll that is already open, but it
can't be placed at the exact same address it must be relocated again
causing it to take more memory. The position independent code (PIC)
takes more memory than non-PIC code. So basically linux trades of
discspace for ram given that a library is used by several running
processes. This is very good for things like libc, xlib and gtk, but
might be suboptimal in the case of mozilla.
The other problem is the symbol tables. The ELF shared libraries
contain LARGE symbol tables for all global symbols and referenced
symbols. PE dll's only contains strings for explicitly imported and
exported symbols. This then clashes a bit with C++, in which all
symbols are global (it seems). In C you normally use static functions
to give file-scope to some symbols, but this doesn't seem possible in
C++. I assume all method symbols from a class must be globally visible
to create vtables or something. At least protected symbols need to be
visible so that you can derive from that class in another file. This
leads to a great many global symbols which gives large .hash, .dynsym
and .dynstr sections in the ELF libraries.
Another thing that i find strange is that the linux build uses a lot
more .so files than the windows build uses .dll's. Why is this so? I
think this makes things worse, as all imported symbols is
duplicated. I see no gain in splitting the libraries up either, demand
loading of library code is done on a page basis anyway, and symbol
resolving is normally done lazily (at first symbol reference).
/ Alex
For reference i include a mail about these matters that i got from the
master of ELF and PE formats, Bertho Stultiens (of Wine fame):
---------------------------------------------------------------------
From ber...@panter.soci.aau.dk Fri Jun 11 10:31:43 1999
Date: Thu, 10 Jun 1999 18:33:42 +0200
From: Bertho Stultiens <ber...@panter.soci.aau.dk>
To: Alexander Larsson <a...@signum.se>
Subject: Re: ELF vs. PEI
At 17:54 10-06-99 +0200, Alexander Larsson wrote:
>Hi, I'd like to ask you for some help. I've seen your work for the wine
>project and you are the most knowledgable i know of in this area.
>
>The problem is about the (disk-)size of ELF shared libraries vs PEI dll's.
>I'm working on making the disk footprint of Mozilla smaller, and one thing
>i've noticed is that the linux binaries are about 50% larger than their
>win32 counterparts. I've built a PEI objdump form binutils 2.9.1 and with
>it i have studied some files from the optimized M6 build of mozilla.
>
>I'm not very good at neither ELF nor PEI, but it seems that the size of
>the acutal code and data is about the same. But the dynamic linking
>information or something is much larger in the ELF libraries.
>
>I'm wondering if you could help me a bit with this.
The formats are completely different and indeed ELF contains more
information than PE. Primarily due to extra link and indirection
information.
>Idx Name Size VMA LMA File off Algn
> 0 .hash 00000b88 00000094 00000094 00000094 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
The hash table to lookup strings from .dynstr
> 1 .dynsym 00001d90 00000c1c 00000c1c 00000c1c 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
All dynamic symbols
> 2 .dynstr 00003af2 000029ac 000029ac 000029ac 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
All strings
> 3 .gnu.version 000003b2 0000649e 0000649e 0000649e 2**1
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .gnu.version_d 00000038 00006850 00006850 00006850 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .gnu.version_r 00000040 00006888 00006888 00006888 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
Junk (afaik)
*Note from alex: I belive this is information about versioned
* symbols. They are used in glibc.
> 6 .rel.data 00000770 000068c8 000068c8 000068c8 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 7 .rel.got 00000190 00007038 00007038 00007038 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 8 .rel.ctors 00000018 000071c8 000071c8 000071c8 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 9 .rel.plt 00000668 000071e0 000071e0 000071e0 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
Relocation info
> 10 .init 0000002f 00007848 00007848 00007848 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
Initialization section
> 11 .plt 00000ce0 00007878 00007878 00007878 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
Procedure redirection (procedure linkage table)
> 12 .text 00008463 00008560 00008560 00008560 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
The code
> 13 .fini 0000001a 000109c4 000109c4 000109c4 2**2
> CONTENTS, ALLOC, LOAD, READONLY, CODE
Finilization section (just before the library is unloaded)
> 14 .rodata 00002474 000109e0 000109e0 000109e0 2**5
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 15 .data 00000698 00013e60 00013e60 00012e60 2**5
> CONTENTS, ALLOC, LOAD, DATA
Ehm, data...
> 16 .eh_frame 00000004 000144f8 000144f8 000134f8 2**2
> CONTENTS, ALLOC, LOAD, DATA
Don't know
> 17 .ctors 00000014 000144fc 000144fc 000134fc 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 18 .dtors 00000008 00014510 00014510 00013510 2**2
> CONTENTS, ALLOC, LOAD, DATA
C++ constructors/destructors tables
> 19 .got 00000408 00014518 00014518 00013518 2**2
> CONTENTS, ALLOC, LOAD, DATA
Global Offset Table. This is to keep code pure (and therefore sharable
between processes!)
> 20 .dynamic 000000c0 00014920 00014920 00013920 2**2
> CONTENTS, ALLOC, LOAD, DATA
Dynamic linking (imports)
> 21 .bss 0000011c 000149e0 000149e0 000139e0 2**5
> ALLOC
Uninit data.
> 22 .comment 000005b8 00000000 00000000 000139e0 2**0
> CONTENTS, READONLY
> 23 .note 000001e0 000005b8 000005b8 00013f98 2**0
> CONTENTS, READONLY
Junk.
[snip win32 dump]
>
>I have no idea what all those elf sections are, but some of them seems
>quite large. much larger than the 0x1000 bytes relocation data in the
>dll.
There is more relocation information in ELFs because the code is
position independent (compiled with -fPIC). This means that the code is
larger, but sharable between processes with mmap because code is really
readonly and does does not require relocation, which in turn reduces
the physical memory need (the kernel uses a great caching scheme).
Win32 libraries are reloaded if the previous loaded one is relocated (a
pure waste of memory).
The .plt and .got sections are there to redirect things. The dynamics
of that is that you can do lazy binding with ELF. I.e load the library,
but link it first when a routine needs to be linked into another
library (on a function by function basis).
>Are win32 dll's in some way less flexible than elf-libs?
>Are they more pre-linked?
yes and yes.
>Mozilla is made up of a lot of elf libs, would i gain anything if i tried
>to link some of these (that are much interconnected) together?
You would lose flexibility. You use libraries because they are shared.
Many of them are also demand-loaded.
I saw that the .rodata was aligned on a large number. This causes some
junk-space to be occupied, but I don't think that it will improve much
with lower settings. You can also blame egcs for generating so much
information, but I guess that the code is faster than windows' code.
You can fiddle a bit with the compiler optimization setting.
The stringtable can be reduced if you declare all local functions and
variables as static. This will prevent them from being entered into the
global symbol table. This can reduce the stringtable quite a bit (I
guess you can at least half .dynstr and .dynsym). You can also do this
later in the ld-link-process, but that is a real pain.
Note that PE only keeps strings from *explicitely ex- and im-ported*
functions. ELF keeps 'm all because you said that they were global.
Greetings Bertho
From: Mike Shaver <sha...@mozilla.org>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/11
Message-ID: <3761064B.2522AE40@mozilla.org>#1/1
X-Deja-AN: 488394358
Content-Transfer-Encoding: 7bit
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: mozilla.org diplomatic corps
Mime-Version: 1.0
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Alexander Larsson wrote:
> The other problem is the symbol tables. The ELF shared libraries
> contain LARGE symbol tables for all global symbols and referenced
> symbols. PE dll's only contains strings for explicitly imported and
> exported symbols. This then clashes a bit with C++, in which all
> symbols are global (it seems). In C you normally use static functions
> to give file-scope to some symbols, but this doesn't seem possible in
> C++. I assume all method symbols from a class must be globally visible
> to create vtables or something.
Actually, I think that just the vtable for a class must be visible (in
our case, it will typically be vtable for an interface), but I could be
wrong.
There may be a way to get egcs to use __declspec(dllexport) in such a
way that we can strip the other symbols from the final DSO with linker
tricks. It'll probably require some patches to egcs and ld, but that
might be worthwhile for our build boxes and the like.
Mike
--
110674.48 105816.56
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/11
Message-ID: <w1hfoekeg6.fsf@tammy.cendio.se>#1/1
X-Deja-AN: 488423134
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Mike Shaver <sha...@mozilla.org> writes:
> Alexander Larsson wrote:
> > The other problem is the symbol tables. The ELF shared libraries
> > contain LARGE symbol tables for all global symbols and referenced
> > symbols. PE dll's only contains strings for explicitly imported and
> > exported symbols. This then clashes a bit with C++, in which all
> > symbols are global (it seems). In C you normally use static functions
> > to give file-scope to some symbols, but this doesn't seem possible in
> > C++. I assume all method symbols from a class must be globally visible
> > to create vtables or something.
>
> Actually, I think that just the vtable for a class must be visible (in
> our case, it will typically be vtable for an interface), but I could be
> wrong.
Is there such a thing as a global vtable for a class? Isn't it built
up by each compilation run, as they read the header file? Say the
vtable for nsISupports. The header-file containing the class
definition is included in almost all cpp files, but it doesn't 'live'
in any special object file. Instead I suppose (I'm no C++ expert, or
any good at it at all really) the compiler reads the header file,
constructs a vtable, given that it knows the symbols it should
contain. Then it places the vtable in the object file (or at least
the symbols from the vtable it uses) in a special link section (like
.gnu.linkonce.t.__17nsIWindowListener) that is combined with others
at final link.
This is probably wrong. I want to know. Tell me how it works.
> There may be a way to get egcs to use __declspec(dllexport) in such a
> way that we can strip the other symbols from the final DSO with linker
> tricks. It'll probably require some patches to egcs and ld, but that
> might be worthwhile for our build boxes and the like.
It will most certaintly be worthwhile for embedded system. The
libraptorhtml.so file has 1.5 megs of symbol info.
/ Alex
From: Mike Shaver <sha...@mozilla.org>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/11
Message-ID: <376127BF.B8F37BA4@mozilla.org>#1/1
X-Deja-AN: 488437872
Content-Transfer-Encoding: 7bit
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
Organization: mozilla.org diplomatic corps
Mime-Version: 1.0
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Alexander Larsson wrote:
>
> Mike Shaver <sha...@mozilla.org> writes:
> > Actually, I think that just the vtable for a class must be visible (in
> > our case, it will typically be vtable for an interface), but I could be
> > wrong.
>
> Is there such a thing as a global vtable for a class? Isn't it built
> up by each compilation run, as they read the header file? Say the
> vtable for nsISupports. The header-file containing the class
> definition is included in almost all cpp files, but it doesn't 'live'
> in any special object file. Instead I suppose (I'm no C++ expert, or
> any good at it at all really) the compiler reads the header file,
> constructs a vtable, given that it knows the symbols it should
> contain. Then it places the vtable in the object file (or at least
> the symbols from the vtable it uses) in a special link section (like
> .gnu.linkonce.t.__17nsIWindowListener) that is combined with others
> at final link.
>
> This is probably wrong. I want to know. Tell me how it works.
That sounds more plausible than what I wrote, to be honest.
Static symbols work correctly in C++, as near as I can tell, but rarely
seem to be useful with methods or fields. I don't think we need to
export the symbols for nsFoo, just for nsIFoo, since there shouldn't be
any cross-library linkages relying on non-XPCOM symbols. Of course,
static isn't the right solution there, because these symbols usually
cross file boundaries, etc.
Someone should write a perl script that munges nm output to figure out
which symbols are exported but never imported anywhere else.
In a pure-XPIDL world (har, har), we might be able to generate export
lists with the xpidl tool or something, but that's a lot more work than
using the __declspec(dllexport) hacks for egcs.
Mike
--
118366.29 110310.53
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/16
Message-ID: <w1aeu058a5.fsf@tammy.cendio.se>
X-Deja-AN: 490340104
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Mike Shaver <sha...@mozilla.org> writes:
> Someone should write a perl script that munges nm output to figure out
> which symbols are exported but never imported anywhere else.
Ok, here we go....
I'm close to cracking this one, but i have a problem with references
to inlined (specified in the header file) methods.
Here's how it works:
(Note: This is for egcs + gnu binutils + ELF machines only!)
Symbols that need to be exported (__declspec(export) on win32) is
placed in a special section of the object file (.text.export for
code and .data.export for data). This is done by the gcc attribute
extension like this: __attribute__ ((section (".text.export")))
These are then parsed with a perl script which 'localizes' (ie. makes
symbols file-scoped) symbols that are not in .text.export or
.data.export.
I've almost been able to build xpcom with these changes, but there are
some problems. First of all inlined methods don't seem to get placed
in the right section. Second, the __attribute__ keyword doesn't work
on a class (like class NS_EXPORT foo { ...}). Therefore a lot of
ugly changes needed to be done, as each public symbol in classes
using "class NS_COM nsFoo {...}" needed to have NS_COM prepended.
What do you think about this? Any clues to the inline stuff? Any
comments on the method? Is this worth pursuing?
I did some small testing on gfx/srx/gtk. libgfxgtk.so shrank from 242k
to 220k (stripped, but compiled with debug). That's 10%, and it will
do even better on code that has shorter and more methods.
/ Alex
Here are the core changes:
mozilla/config/mkexports.pl:
#! /usr/bin/perl
#
# The contents of this file are subject to the Mozilla Public License
# Version 1.1 (the "MPL"); you may not use this file except in
# compliance with the MPL. You may obtain a copy of the MPL at
# http://www.mozilla.org/NPL/
#
# Software distributed under the MPL is distributed on an "AS IS" basis,
# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the NPL
# for the specific language governing rights and limitations under the
# MPL.
#
# The Initial Developer of this code under the MPL is Alexander
# Larsson. Portions created by Alexander Larssson are
# Copyright (C) 1998 Alexander Larsson. All Rights Reserved.
#
# Special thanks to Henrik Rindlöw for helping me with Perl
#
# Input: target.o obj1.o obj2.o ... objN.o
#
# Localizes all symbols of type T (text), D (data) and B (bss)
# That is not in the .text.export section.
#print "env LD = $ENV{"LD"}\n";
$dest = shift @ARGV;
$objs = join(" ", @ARGV);
#print "dest = $dest\n";
#print "objs = $objs\n";
$cmd = "ld -r -o $dest $objs \n";
# Link object files to one object file.
system($cmd);
#print "cmd = $cmd";
open(OD,"objdump -t $dest|");
while (<OD>) {
/g\s*\w\s*\.text\.export\s*\w*\s*(\S*)/ && push @EXPORTED, $1;
/g\s*\w\s*\.data\.export\s*\w*\s*(\S*)/ && push @EXPORTED, $1;
}
open(NM,"nm $dest|");
while (<NM>) {
/\w*\s+[TDB]\s+(\S*)/ && do {$SYMS{$1} = 1};
}
#print join(", ",@EXPORTED),"\n";
#print join(", ",@SYMS),"\n";
foreach $S (@EXPORTED) {
delete $SYMS{$S};
}
#print join(", ",keys %SYMS),"\n";
$cmd = "objcopy";
foreach $S (keys %SYMS) {
$cmd .= " -L $S";
if (length($cmd) > 900) {
# print("$cmd $dest\n");
system("$cmd $dest");
$cmd = "objcopy";
}
}
#print("$cmd $dest\n");
system("$cmd $dest");
Index: nscore.h
===================================================================
RCS file: /cvsroot/mozilla/xpcom/base/nscore.h,v
retrieving revision 1.2
diff -u -r1.2 nscore.h
--- nscore.h 1999/06/04 02:00:19 1.2
+++ nscore.h 1999/06/16 17:47:46
@@ -72,6 +72,17 @@
#define NS_EXPORT __declspec(export)
#define NS_EXPORT_(type) __declspec(export) type
+#elif defined(MOZ_STRIP_NOT_EXPORTED)
+
+#define NS_IMPORT
+#define NS_IMPORT_(type) type
+
+#undef NS_EXPORT
+#undef NS_EXPORT_
+#define NS_EXPORT __attribute__ ((section (".text.export")))
+#define NS_EXPORT_DATA __attribute__ ((section (".data.export")))
+#define NS_EXPORT_(type) __attribute__ ((section (".text.export"))) type
+
#else
/* XXX do something useful? */
#define NS_IMPORT
Index: nsCom.h
===================================================================
RCS file: /cvsroot/mozilla/xpcom/base/nsCom.h,v
retrieving revision 1.6
diff -u -r1.6 nsCom.h
--- nsCom.h 1999/04/04 02:22:08 1.6
+++ nsCom.h 1999/06/16 17:47:46
@@ -26,16 +26,24 @@
#ifdef _IMPL_NS_COM
#ifdef XP_PC
#define NS_COM _declspec(dllexport)
+#define NS_COM_CLASS _declspec(dllexport)
#elif defined(XP_MAC)
#define NS_COM __declspec(export)
+#define NS_COM_CLASS __declspec(export)
+#elif defined(MOZ_STRIP_NOT_EXPORTED)
+#define NS_COM __attribute__ ((section (".text.export")))
+#define NS_COM_CLASS
#else /* !XP_PC */
#define NS_COM
+#define NS_COM_CLASS
#endif /* !XP_PC */
#else /* !_IMPL_NS_COM */
#ifdef XP_PC
#define NS_COM _declspec(dllimport)
+#define NS_COM_CLASS _declspec(dllimport)
#else /* !XP_PC */
#define NS_COM
+#define NS_COM_CLASS
#endif /* !XP_PC */
#endif /* !_IMPL_NS_COM */
@@ -77,8 +85,13 @@
#else /* !XP_PC && !XP_MAC */
+#if defined(MOZ_STRIP_NOT_EXPORTED)
+#define NS_EXPORT __attribute__ ((section (".text.export")))
+#define NS_EXPORT_(type) __attribute__ ((section (".text.export"))) type
+#else
#define NS_EXPORT
#define NS_EXPORT_(type) type
+#endif
#define NS_IMETHOD_(type) virtual type
#define NS_IMETHOD virtual nsresult
Index: autoconf.mk.in
===================================================================
RCS file: /cvsroot/mozilla/config/autoconf.mk.in,v
retrieving revision 3.64
diff -u -r3.64 autoconf.mk.in
--- autoconf.mk.in 1999/06/10 16:27:38 3.64
+++ autoconf.mk.in 1999/06/16 17:53:11
@@ -35,12 +35,14 @@
MOZ_MAIL_NEWS = @MOZ_MAIL_NEWS@
MOZ_EDITOR = @MOZ_EDITOR@
MOZ_BRPROF = @MOZ_BRPROF@
UNIX_CRASH_ON_ASSERT = @UNIX_CRASH_ON_ASSERT@
NO_UNIX_ASYNC_DNS = @NO_UNIX_ASYNC_DNS@
NO_SHARED_LIB = @NO_SHARED_LIB@
NO_NETSCAPE_SHARED = @NO_SHARED_LIB@
NO_STATIC_LIB = @NO_STATIC_LIB@
NO_NETSCAPE_STATIC = @NO_STATIC_LIB@
+MOZ_STRIP_NOT_EXPORTED = @MOZ_STRIP_NOT_EXPORTED@
ENABLE_TESTS = @ENABLE_TESTS@
ENABLE_PICS = @ENABLE_PICS@
DOM = @MOZ_DOM@
Index: rules.mk
===================================================================
RCS file: /cvsroot/mozilla/config/rules.mk,v
retrieving revision 3.109
diff -u -r3.109 rules.mk
--- rules.mk 1999/06/10 16:27:39 3.109
+++ rules.mk 1999/06/16 17:53:12
@@ -523,7 +523,12 @@
@rm -f $(SUB_LOBJS)
@for lib in $(SHARED_LIBRARY_LIBS); do $(AR_EXTRACT) $${lib}; $(CLEANUP2); done
endif
+ifdef MOZ_STRIP_NOT_EXPORTED
+ $(PERL) $(topsrcdir)/config/mkexports.pl lib$(LIBRARY_NAME).o $(OBJS)
+ $(AR) lib$(LIBRARY_NAME).o $(LOBJS) $(SUB_LOBJS)
+else
$(AR) $(OBJS) $(LOBJS) $(SUB_LOBJS)
+endif
$(RANLIB) $@
@rm -f foodummyfilefoo $(SUB_LOBJS)
else
@@ -543,7 +548,12 @@
ifneq ($(OS_ARCH),OS2)
$(SHARED_LIBRARY): $(OBJS) $(LOBJS)
rm -f $@
+ifdef MOZ_STRIP_NOT_EXPORTED
+ $(PERL) $(topsrcdir)/config/mkexports.pl lib$(LIBRARY_NAME).o $(OBJS)
+ $(MKSHLIB) -o $@ lib$(LIBRARY_NAME).o $(LOBJS) $(EXTRA_DSO_LDOPTS)
+else
$(MKSHLIB) -o $@ $(OBJS) $(LOBJS) $(EXTRA_DSO_LDOPTS)
+endif
chmod +x $@
$(MOZ_POST_DSO_LIB_COMMAND) $@
else
Index: configure.in
===================================================================
RCS file: /cvsroot/mozilla/configure.in,v
retrieving revision 1.348
diff -u -r1.348 configure.in
--- configure.in 1999/06/11 03:09:15 1.348
+++ configure.in 1999/06/16 17:54:08
@@ -1544,6 +1555,20 @@
dnl ========================================================
dnl =
+dnl = --enable-strip-not-exported
+dnl =
+dnl = Enable stripping of not exported symbols in .so files
+dnl =
+dnl ========================================================
+MOZ_STRIP_NOT_EXPORTED=
+
+MOZ_ARG_ENABLE_BOOL(strip-not-exported,
+[ --enable-strip-not-exported Enable stripping of not exported symbols in .so files ],
+ [MOZ_STRIP_NOT_EXPORTED=1
+ AC_DEFINE(MOZ_STRIP_NOT_EXPORTED) ])
+
+dnl ========================================================
+dnl =
dnl = --with-debug-modules=module1,module1,etc
dnl =
dnl = Enable debug for specific modules only
@@ -1756,12 +1781,14 @@
AC_SUBST(MOZ_INSURE_EXCLUDE_DIRS)
AC_SUBST(MOZ_INSURIFYING)
AC_SUBST(MOZ_MAIL_NEWS)
AC_SUBST(MOZ_BUILD_XPFE)
dnl AC_SUBST(MOZ_LDAP)
AC_SUBST(MOZ_EDITOR)
AC_SUBST(MOZ_BRPROF)
AC_SUBST(UNIX_CRASH_ON_ASSERT)
+AC_SUBST(MOZ_STRIP_NOT_EXPORTED)
AC_SUBST(NO_UNIX_ASYNC_DNS)
AC_SUBST(NO_SHARED_LIB)
AC_SUBST(NO_STATIC_LIB)
From: Mike Shaver <sha...@mozilla.org>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/16
Message-ID: <3767FCF0.C00CC3E4@mozilla.org>
X-Deja-AN: 490379426
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se>
X-Accept-Language: en
Content-Type: multipart/mixed; boundary="------------B6FEF0FCE20AC0F016B10B94"
Organization: mozilla.org diplomatic corps
Mime-Version: 1.0
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
This is a multi-part message in MIME format.
--------------B6FEF0FCE20AC0F016B10B94
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Alexander Larsson wrote:
> Here's how it works:
> (Note: This is for egcs + gnu binutils + ELF machines only!)
>
> Symbols that need to be exported (__declspec(export) on win32) is
> placed in a special section of the object file (.text.export for
> code and .data.export for data). This is done by the gcc attribute
> extension like this: __attribute__ ((section (".text.export")))
Cool!
I got the attached from a cygnus guy yesterday, too. ``recent'' ld
means ``from cygnus CVS'', I think.
Mike
--
565583.05 488728.81
--------------B6FEF0FCE20AC0F016B10B94
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Return-Path: <r...@cygnus.com>
Received: from tintin.mcom.com ([205.217.233.42]) by
obob.netscape.com (Netscape Messaging Server 4.1 Jun 14 1999
03:41:33) with ESMTP id FDEP6100.H0B for
<sha...@obob.netscape.com>; Tue, 15 Jun 1999 23:10:49 -0700
Received: from hemail.mcom.com ([205.217.237.179]) by
tintin.mcom.com (Netscape Messaging Server 4.1 Jun 2 1999
03:33:49) with ESMTP id FDEP8S00.KNP for
<sha...@tintin.mcom.com>; Tue, 15 Jun 1999 23:12:28 -0700
Received: from ywing.netscape.com (ywing.mcom.com [207.200.72.93])
by hemail.mcom.com (8.8.8/8.8.5) with ESMTP id XAA11367
for <sha...@netscape.com>; Tue, 15 Jun 1999 23:12:27 -0700 (PDT)
Received: from gila.mozilla.org (h-207-200-73-41.netscape.com [207.200.73.41])
by ywing.netscape.com (8.8.5/8.8.5) with ESMTP id XAA08635
for <sha...@netscape.com>; Tue, 15 Jun 1999 23:12:22 -0700 (PDT)
Received: from cygnus.com (runyon.cygnus.com [205.180.230.5])
by gila.mozilla.org with ESMTP id XAA20334
for <sha...@mozilla.org>; Tue, 15 Jun 1999 23:12:22 -0700 (PDT)
Received: from dot.cygnus.com (dot.cygnus.com [205.180.230.224])
by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id XAA18553
for <sha...@mozilla.org>; Tue, 15 Jun 1999 23:12:21 -0700 (PDT)
Received: (rth@localhost) by dot.cygnus.com (8.9.3/8.6.4)
id XAA29972 for sha...@mozilla.org; Tue, 15 Jun 1999 23:12:20 -0700
Date: Tue, 15 Jun 1999 23:12:20 -0700
From: Richard Henderson <r...@cygnus.com>
To: sha...@mozilla.org
Subject: dllexport
Message-ID: <19990615231220.A29...@cygnus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5i
Put this in, oh, say, gcc/config/i386/linux.h. Add "extra_objs=winnt.o"
to configure.in for linux. Add --version-exports-section to a recent ld's
command line.
r~
/*
* Support for __declspec(dllimport) & __declspec(dllexport).
*/
/* We don't care about dllimport. */
#define TARGET_NOP_FUN_DLLIMPORT 1
/* A C expression whose value is nonzero if IDENTIFIER with arguments ARGS
is a valid machine specific attribute for DECL.
The attributes in ATTRIBUTES have previously been assigned to DECL. */
#undef VALID_MACHINE_DECL_ATTRIBUTE
#define VALID_MACHINE_DECL_ATTRIBUTE(DECL, ATTRIBUTES, IDENTIFIER, ARGS) \
i386_pe_valid_decl_attribute_p (DECL, ATTRIBUTES, IDENTIFIER, ARGS)
extern int i386_pe_valid_decl_attribute_p ();
/* A C expression whose value is nonzero if IDENTIFIER with arguments ARGS
is a valid machine specific attribute for TYPE.
The attributes in ATTRIBUTES have previously been assigned to TYPE. */
#undef VALID_MACHINE_TYPE_ATTRIBUTE
#define VALID_MACHINE_TYPE_ATTRIBUTE(TYPE, ATTRIBUTES, IDENTIFIER, ARGS) \
i386_pe_valid_type_attribute_p (TYPE, ATTRIBUTES, IDENTIFIER, ARGS)
extern int i386_pe_valid_type_attribute_p ();
#define MERGE_MACHINE_DECL_ATTRIBUTES(OLD, NEW) \
i386_pe_merge_decl_attributes ((OLD), (NEW))
extern union tree_node *i386_pe_merge_decl_attributes ();
/* Used to implement dllexport overriding dllimport semantics. It's also used
to handle vtables - the first pass won't do anything because
DECL_CONTEXT (DECL) will be 0 so i386_pe_dll{ex,im}port_p will return 0.
It's also used to handle dllimport override semantics. */
#if 0
#define REDO_SECTION_INFO_P(DECL) \
((DECL_MACHINE_ATTRIBUTES (DECL) != NULL_TREE) \
|| (TREE_CODE (DECL) == VAR_DECL && DECL_VIRTUAL_P (DECL)))
#else
#define REDO_SECTION_INFO_P(DECL) 1
#endif
/* Used only here locally. If the decl has been exported, emit the
necessary assembly. */
#define ASM_EXPORT_DECL(FILE, NAME, DECL) \
do { \
if ((DECL) && i386_pe_dllexport_p (DECL)) \
{ \
fprintf ((FILE), ".section .exports\n"); \
fprintf ((FILE), "\t%s\t\"", STRING_ASM_OP); \
assemble_name (FILE, NAME); \
fprintf ((FILE), "\"\n.previous\n"); \
} \
} while (0)
/* Write the extra assembler code needed to declare a function properly.
Some svr4 assemblers need to also have something extra said about the
function's return value. We allow for that here. */
#undef ASM_DECLARE_FUNCTION_NAME
#define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
do { \
ASM_EXPORT_DECL(FILE, NAME, DECL); \
fprintf (FILE, "\t%s\t ", TYPE_ASM_OP); \
assemble_name (FILE, NAME); \
putc (',', FILE); \
fprintf (FILE, TYPE_OPERAND_FMT, "function"); \
putc ('\n', FILE); \
ASM_DECLARE_RESULT (FILE, DECL_RESULT (DECL)); \
ASM_OUTPUT_LABEL(FILE, NAME); \
} while (0)
/* Write the extra assembler code needed to declare an object properly. */
#undef ASM_DECLARE_OBJECT_NAME
#define ASM_DECLARE_OBJECT_NAME(FILE, NAME, DECL) \
do { \
ASM_EXPORT_DECL(FILE, NAME, DECL); \
fprintf (FILE, "\t%s\t ", TYPE_ASM_OP); \
assemble_name (FILE, NAME); \
putc (',', FILE); \
fprintf (FILE, TYPE_OPERAND_FMT, "object"); \
putc ('\n', FILE); \
size_directive_output = 0; \
if (!flag_inhibit_size_directive && DECL_SIZE (DECL)) \
{ \
size_directive_output = 1; \
fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \
assemble_name (FILE, NAME); \
putc (',', FILE); \
fprintf (FILE, HOST_WIDE_INT_PRINT_DEC, \
int_size_in_bytes (TREE_TYPE (DECL))); \
fputc ('\n', FILE); \
} \
ASM_OUTPUT_LABEL(FILE, NAME); \
} while (0)
/* Similarly for COMMON symbols. */
#undef ASM_OUTPUT_ALIGNED_COMMON
#undef ASM_OUTPUT_ALIGNED_DECL_COMMON
#define ASM_OUTPUT_ALIGNED_DECL_COMMON(FILE, DECL, NAME, SIZE, ALIGN) \
do { \
ASM_EXPORT_DECL(FILE, NAME, DECL); \
fprintf ((FILE), "\t%s\t", COMMON_ASM_OP); \
assemble_name ((FILE), (NAME)); \
fprintf ((FILE), ",%u,%u\n", (SIZE), (ALIGN) / BITS_PER_UNIT); \
} while (0)
#undef ASM_OUTPUT_ALIGNED_LOCAL
#undef ASM_OUTPUT_ALIGNED_DECL_LOCAL
#define ASM_OUTPUT_ALIGNED_DECL_LOCAL(FILE, DECL, NAME, SIZE, ALIGN) \
do { \
fprintf ((FILE), "\t%s\t", LOCAL_ASM_OP); \
assemble_name ((FILE), (NAME)); \
fprintf ((FILE), "\n"); \
ASM_OUTPUT_ALIGNED_DECL_COMMON((FILE), (DECL), (NAME), (SIZE), (ALIGN)); \
} while (0)
/* This macro gets just the user-specified name out of the string in a
SYMBOL_REF. Discard trailing @[NUM] encoded by ENCODE_SECTION_INFO. */
/* Unused except to let winnt.c compile. */
#undef STRIP_NAME_ENCODING
#define STRIP_NAME_ENCODING(VAR,SYMBOL_NAME) ((VAR) = (SYMBOL_NAME))
--------------B6FEF0FCE20AC0F016B10B94--
From: Alexander Larsson <a...@lysator.liu.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/16
Message-ID: <m3so7rkgz6.fsf@c125.ryd.student.liu.se>#1/1
X-Deja-AN: 490404296
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se> <3767FCF0.C00CC3E4@mozilla.org>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Mike Shaver <sha...@mozilla.org> writes:
> Alexander Larsson wrote:
> > Here's how it works:
> > (Note: This is for egcs + gnu binutils + ELF machines only!)
> >
> > Symbols that need to be exported (__declspec(export) on win32) is
> > placed in a special section of the object file (.text.export for
> > code and .data.export for data). This is done by the gcc attribute
> > extension like this: __attribute__ ((section (".text.export")))
>
> Cool!
>
> I got the attached from a cygnus guy yesterday, too. ``recent'' ld
> means ``from cygnus CVS'', I think.
Seems like a better way. I suppose this is part of the support Corel
paid Cygnus to do for wine.
/ Alex
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/17
Message-ID: <w1909j5kk7.fsf@tammy.cendio.se>#1/1
X-Deja-AN: 490582095
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se> <3767FCF0.C00CC3E4@mozilla.org>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Mike Shaver <sha...@mozilla.org> writes:
> I got the attached from a cygnus guy yesterday, too. ``recent'' ld
> means ``from cygnus CVS'', I think.
This seems to be intel (i386) only. I'll look a bit closer at it.
/ Alex
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/17
Message-ID: <w17lp35ajb.fsf@tammy.cendio.se>#1/1
X-Deja-AN: 490631340
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se> <3767FCF0.C00CC3E4@mozilla.org>
<w1909j5kk7.fsf@tammy.cendio.se>
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Alexander Larsson <a...@cendio.se> writes:
> Mike Shaver <sha...@mozilla.org> writes:
> > I got the attached from a cygnus guy yesterday, too. ``recent'' ld
> > means ``from cygnus CVS'', I think.
>
> This seems to be intel (i386) only. I'll look a bit closer at it.
Maybe not. There are a lot of functioncalls i386_xxx_xx(), but there
seems to be little work porting this to another arch.
I've build ld (binutils 2.9.4.0.5 works, or any cvs checked out later
than 1999-04-11) and egcs with these changes.
I'll revert my earlier changes and redo them using these tools
instead.
/ Alex
From: Alexander Larsson <a...@cendio.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/18
Message-ID: <w1674l637u.fsf@tammy.cendio.se>#1/1
X-Deja-AN: 491056526
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se> <3767FCF0.C00CC3E4@mozilla.org>
To: Richard Henderson <r...@cygnus.com>, sha...@mozilla.org
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Mike Shaver <sha...@mozilla.org> writes:
> Alexander Larsson wrote:
> > Here's how it works:
> > (Note: This is for egcs + gnu binutils + ELF machines only!)
> >
> > Symbols that need to be exported (__declspec(export) on win32) is
> > placed in a special section of the object file (.text.export for
> > code and .data.export for data). This is done by the gcc attribute
> > extension like this: __attribute__ ((section (".text.export")))
>
> Cool!
>
> I got the attached from a cygnus guy yesterday, too. ``recent'' ld
> means ``from cygnus CVS'', I think.
>
> Mike
I've been working on this a bit now, and I almost got it working.
I've got some problems with const methods. They don't inherit their
dllexport attribute from their class.
I've traced it to the function associated_type() in winnt.c.
It returns different associated types for const and non-const
methods. This seems ok, because according to a comment the this
pointer is returned, and const methods get a different this pointer
(const Class *const instead of const Class *), but the const
type hasn't got the dllexport attribute set, which makes gcc not
export the symbol for the method.
Anyone have a clue? I'm not very knowledgable about gcc internals.
Here is an example file that shows the behaviour.
The TestPublic method is not put in the .exports section.
extern "C" __attribute__((dllexport)) void * NSGetFactory_E(void) ;
extern "C" void * NSGetFactory_I(void);
class __attribute__((dllexport)) Test {
public:
void *TestPublic(char *c) const;
void *TestPublicInline(char *c) {
return c;
}
protected:
void *TestProtected(char *c);
private:
void *TestPrivate(char *c);
};
void *Test::TestPublic(char *c) const
{
return c;
}
void *Test::TestPrivate(char *c)
{
return c;
}
void *Test::TestProtected(char *c)
{
return TestPublicInline(c);
}
int x = 0;
class Test *test;
void * NSGetFactory_E(void)
{
return 0;
}
void * NSGetFactory_I(void)
{
return 0;
}
int
main()
{
return 0;
}
/ Alex
From: Alexander Larsson <a...@lysator.liu.se>
Subject: Re: Why is linux binaries 50% larger than win32?
Date: 1999/06/22
Message-ID: <m3g13k5hbg.fsf@c125.ryd.student.liu.se>#1/1
X-Deja-AN: 492568070
References: <w1ogioo4xr.fsf@tammy.signum.se> <375FFE74.66E21D14@netscape.com>
<w1iu8vjfj6.fsf@tammy.cendio.se> <3761064B.2522AE40@mozilla.org>
<w1hfoekeg6.fsf@tammy.cendio.se> <376127BF.B8F37BA4@mozilla.org>
<w1aeu058a5.fsf@tammy.cendio.se> <3767FCF0.C00CC3E4@mozilla.org>
To: sha...@mozilla.org
Organization: Another Netscape Collabra Server User
Newsgroups: netscape.public.mozilla.performance.size-matters,
netscape.public.mozilla.unix
Ok, i've got this stuff partially working now.
Viewer runs, with some runtime warnings.
I've got a tree that is about a week old. I've compiled it with
./configure --with-pthreads --disable-editor --disable-mailnews
--disable-tests --disable-printing --disable-debug --enable-optimize
--enable-strip-not-exported
components/libraptorhtml.so is 3078704 bytes. I've got no old binary
left to compare with, but latest reports in size-matters say it's 3.5 Meg.
That's about 15% or so. Haven't done any more comparisons.
I'll try to update to the newest tree tomorrow, but if someone is interested
i placed some stuff at ftp://ftp.cendio.se/pub/alex/moz/
egcs-dllexport.diff is the changes i did to egcs. cc1.dllexport and
cc1plus.dllexport are precompiled binaries for RH 6.0.
ld.dllexport is a precompiled ld from binutils 2.9.4.0.5.
dllexport-990622.diff contains the changes i made to the mozilla tree.
/ Alex