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]
Other format: [Raw text]

Re: -fdump-translation-unit considered harmful


Richard,

One of the objections to exporting tree internals in an open-format
was that it would make life easier for people that what want to write software that circumvents GPL by reusing internals of the GCC.


Of course, defining the API would require such software to link to the GCC, which is "extension" of its functionality and implying that it must be covered by the GPL. By happy circumstance, this also means a speed boost for such software;-)

However, "extending" GCC in this way would needlessly complicate (an already quite complicated) software stack - we may expect tons of plugins appearing...

One possible remedy is to allow "direct" function calls across address spaces. In this situation the GCC's cc1(plus) would be started in one process, with a source-analyzing application(s) in another process(es). These processes would communicate using pipes and /readonly pairwise shared/ memory (each one can read, but not write data of its peer).

Hence my question: would GPL cover an executable that runs in a separate address space, albeit having some sections /readonly pairwise shared/ with GCC's cc1(plus)?

BTW, the GCC's backend(s) need not undergo dramatic patching, since all they need to do is to pause when the tree has been built and wait until the source-analyzing code has done its job (which can be done with simple pipes). This, and a tweak of the backend's allocation routines to allocate from a shared memory (rather than an anonymously mapped) segment should be sufficient...

The http://www.gnu.org/licenses/gpl-faq.html gives a definite answer only when static or dynamic linking is used, or when an RPC-like mechanism is used. Here is a dual borderline case to the one that is explained in the FAQ: insead of dynamically linking and executing just main(), one can start a separate process and have fine-grained interactions (as opposed to RPC) initiated from it. Would the situation I described above be still acceptable, given the GCC's definition of the "arms length" communication?


Richard Stallman wrote:
I think it would be a ok to define an interface for GCC to
link with source-analyzing code.  At least, I don't see any
particular problem in it.  It would be like adding such code
to GCC, more or less.



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