This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Idea for export Implemnation


> From: Kühl, Dietmar [mailto:Dietmar.Kuehl@IZB-SOFT.de]
...
> I think a "smallest impact" implementation would in fact use some
> sort of database (this can be a very simple one) where exported
> templates are collected in some preprocessed from. Then, when an
> instantiation is needed, the definition is looked up in this database
> together with the currently available instantiations. If necessary, it
> is instantiated. The definition can than go either into the 
> current object
> file or some other special object file or library.

I'd have to say that the ptrepository systems I used in practice have
NOT worked will, particularly with libraries.  It is much cleaner
to store the things you would put in the db, in the .o files
(whether in an archive or not).  Then, they'll be searched in the
same order too.

If its too hard to add another named segment that isn't loaded
(or, in this case, caused to link) thn maybe it would be possible
to stash it into debugging information?

I think it would be much, much easier to use if the templates are
in the objects.

It might not even be necessary to use the debug info.  Suppose the
target system linker can handle extra segments.  In this case we
can link normally with the first pass and get unresolved template
requirements, then build a referencing file requesting the templates
and do a second link to an extract file which still has symbol
tables - then that extract file could be used to generate code.
In this way, the target linker uses its own rules to find all you
need using its normal config and rules.

> 
> To support exported templates in libraries, there would be a database
> for each of the libraries. Potentially, this can be a member of the
> library itself.

This is almost certainly 'too hard' since its going to screw up
everyone's makefiles to make the libraries.  Well, maybe.  Do you
intend that the compiler driver be used to build the library rather
than 'raw# ar?  (Like, say, SunPro CC does - which performs the
expansions it needs from the existing naff repository.  Never saw a
version that works, and it doesn't handle 'export'.)

James


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]