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] | |
There are a lot of checks that could be implemented as plugins to benefit Mozilla and other projects. For future Mozilla development certain features that we are looking at are not feasible in C++ until the compiler can help with enforcing correct API usage. It would be extremely awesome to be able to utilize GCC internals for static analysis and source refactoring. Currently that isn't realistic as these features do not belong in the GCC mainline and distributing a gcc fork would be very burdensome."Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> And then, once the underlying problem is addressed and we Alexandre> have an API that is usable by regular users, maybe we will Alexandre> find out that we don't need plugins, after all.
Plugins are about deployment, not development.
Plugins make it possible to redistribute useful things which are not
in GCC. They don't -- and as you rightly point out, can't -- make it
simpler to actually develop these things.
The canonical example, which has been covered many times, is a pass
that does extra checking for a large program (e.g., Mozilla).
Tom, I don't know much about linkers and LD_PRELOAD. Would making LD_PRELOAD work be easier than making an unstable plugin API?
LD_PRELOAD would work just as well as having gcc directly support
plugins, provided that certain internal things are never made
file-local. Someone could write a helper library to make it
relatively simple to hook in. But... I looked at this recently, and
since gcc is not linked with -rdynamic, it is a non-starter.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |