Re: Final intermodule patch

[Geoff Keating <geoffk at geoffk dot org>]

Mark Mitchell <mark@codesourcery.com> writes:

> On Fri, 2003-07-11 at 15:18, Neil Booth wrote:
> > Geoffrey Keating wrote:-
> > 
> > > 	* cpplib.c (undefine_macros): New.
> > > 	(cpp_undef_all): New.
> > 
> > This is problematic as memory is never freed.
> 
> I think the intermodule patch is somewhat flawed, despite it's very
> laudable goals.

One memory leak does not a flawed patch make.

> The patch I commited to make_decl_rtl will break the new functionality,
> in that static functions and variables will no longer be renamed apart. 
> But, they should not be renamed anyhow.
> 
> Doing so will break debugging ("break foo" will not work)

I was hoping that DWARF-2 could handle this.  If not, I note that you
just have to write 'break foo<tab>' in GDB, and GDB will add the
suffix.  As a bonus, if you have two 'foo's, you can now specify which
one you want to break in.

> and it breaks
> the kinds of assembly tricks that crtstuff.c does -- and on which lots
> of code relies.

We can easily find a solution for crtstuff.c.  My preferred solution
is to add 'asm' names to anything that's explicitly referenced from
assembler.

I do not believe that there is a lot of code doing the kind of tricks
that crtstuff.c uses.  If there was, whoever owns it is very used to
it breaking with every GCC release.

> Unfortunately, if we try to generate a single .s file we have no choice
> but to rename the functions apart.
> 
> The solution is to generate multiple .s files.  If, for example,
> cross-module inlining is going to be performed, fine -- but you still
> get multiple .s files out.  If a static entity in one .o file needs to
> be reached from another .o file, an external-linkage alias for the
> entity should be defined with a funny name.

That only works on systems that can make aliases of symbols.  Darwin
can't, for instance.

> (All of these issues arise in the idea of "template repositories" in
> C++, and Cfront had lots of misadventures in this area, so we have prior
> art to learn from when we add this new functionality.)

Um, this really isn't like template instantiation.  It's more like
namespaces, but even there the parallel isn't exact.

> I think this patch should probably be reverted until these issues get
> sorted out.

It would have been better had this been discussed months ago when I
first proposed this patch!

-- 
- Geoffrey Keating <geoffk@geoffk.org>