This is the mail archive of the
mailing list for the GCC project.
Re: Removing space waste for g++ static inlined objects
- To: David Korn <dkorn at pixelpower dot com>
- Subject: Re: Removing space waste for g++ static inlined objects
- From: "Ronald F. Guilmette" <rfg at monkeys dot com>
- Date: Wed, 14 Feb 2001 10:17:59 -0800
- cc: "'gcc-patches at gcc dot gnu dot org'" <gcc-patches at gcc dot gnu dot org>
In message <718D38CAB6E0D011B2C90060970C28A56426B4@EXCHANGESERVER>, you wrote:
> Hi Ronald,
> I gave your patch a try. The good news is that it caused no regressions
> The not-so-good news is that the overall effects of your patch seem to
>increase the size of compiled objects and mess around in strange and
>unexpected ways with the contents of the object file symbol table.
I now know that there were a number of problems with the patch that I
posted. Some things that I had hoped would work, and that I had hoped
tha the linker would handle properly, do not in fact work as expected,
especially when shared libraries are involved.
A newer and better patch is provided below. This patch is actually simpler
than my original, and seems to produce results that actually work, even
when you are building shared libraries.
In effect, what I am doing here (with this latest patch) is just to get
the compiler to treat static-storage objects whose declaration are nested
within extern-linkage inline functions the same as it was already treating
vtables... i.e. putting each one into its own little .gnu.linkonce section,
giving that section a name that is unlikely to match anything else... other
than the exact same object declaration... across compilation unit boundaries,
and also making these objects as TREE_GLOBAL (which, for an ELF target at
least, causes them to appear in a .weak declaration in the .s file.)
So far, this seems to be working OK.
That's the good news.
The bad news is that I am really very uncomfortable about the fact that
this hack, and also the pre-existing hack to do essentially this same stuff
to the vtables, effectively cause these objects to be given a sort of
``global'' scope, when in fact it is questionable whether they should
have that or not (because name conflicts might occur).
Specifically, let's say that you have a class named `C' in one translation
unit, and you also have a totally different class `C' in a different compi-
lation unit. Now you link those two units together and what do you get?
The linker takes the first vtable for the first class C and makes that be
*the* vtable for *all* class Cs in the whole linked program. This may
perhaps yield results that are not at all what the programmer expected.
On the other hand, maybe the compiler/linker are allowed to do this sort
of stuff on the basis of the C++ ``one definition rule''. I'm not sure
about that. But regardless, I can say ``Woa unto the programmer who
fails to give his file-scope class types distinctive names!'' :-)
Anyway, the patch below attempts to skirt the issue by giving all static-
storage objects declared within extern-linkage inline functions ``distinctive''
ASSEMBLER_NAMEs. (This may, and probably does break some ABI somewhere,
and may also render it difficult or impossible to see these objects in
gdb.) The distinctive ASSEMBLER_NAMEs for these objects are formed by
prefixing the mangled name of the containing function onto the front of
the ASSEMBLER_NAMEs that the compiler would otherwise assigned for these
objects. However even this isn't adequate to insure total global dis-
tinctiveness, in particular in a case like this:
static int object;
static int object;
As long as you don't code like this, you should be OK with the following
patch. :-) (I would try harder to develop a solution that would handle
even twisted/sick/pathological cases like that shown above, but it still
isn't even clear to me that anybody other than me seriously gives a darn
about this space-waste issue.)
P.S. I tuned out the gcc-patches mailing list in order to avoid having
to wade through several dozen Java-related message per day which don't
interest me in the least. So if anyone wants to talk more about this
issue (or patch) please write to me directly at <email@example.com>.
P.P.S. Has anyone ever suggested the idea of breaking up gcc-patches
mailing list into sublists for the various languages? That would sure
improve the S/N ratio, at least for me.
diff -rc2 2.95.2/gcc/cp/decl.c 2.95.2/gcc/cp/decl.c
*** 2.95.2/gcc/cp/decl.c Sun Aug 8 17:28:33 1999
--- 2.95.2/gcc/cp/decl.c Tue Feb 6 11:16:55 2001
*** 8104,8107 ****
--- 8104,8108 ----
&& TREE_PUBLIC (current_function_decl))
+ #if 0
/* Rather than try to get this right with inlining, we suppress
inlining of such functions. */
*** 8138,8141 ****
--- 8139,8145 ----
+ comdat_linkage (decl);
*** 9069,9072 ****
--- 9073,9082 ----
if (declarator && context && current_lang_name != lang_name_c)
DECL_ASSEMBLER_NAME (decl) = build_static_name (context, declarator);
+ else if (declarator
+ && current_function_decl
+ && ! RIDBIT_SETP (RID_EXTERN, specbits)
+ && current_lang_name != lang_name_c)
+ DECL_ASSEMBLER_NAME (decl) =
+ build_static_name (current_function_decl, declarator);