[Bug binutils/30577] No way to prevent BFD plugin auto-loading

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30577

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Nick Clifton from comment #1)
> (In reply to Richard Biener from comment #0)
> Hi Richard,
> 
> > There is no documented way to disable plugin auto-loading from BFD for tools
> > like NM and AR but this also affects LD.
> 
> True...
> 
> > By inspecting the source I can see that for AR at least --plugin="" works
> 
> This should also work for NM, but not for LD.
> 
> > but there is no --no-plugin 
> 
> I am tempted to suggest that we document --plugin="" as doing this,
> and make sure that LD supports it as well.  That would mean the least
> disruption to the sources.  (Except see below for a different approach...)

I guess that's a good idea independently of what we do in addition to that.

> > or any way to for example override the
> > search directory in the environment.
> 
> Again true.  I dislike having a hard-coded directory in the sources,
> so having a way to set it dynamically would be good.  I am very wary 
> of using an environment variable to do this however as it makes
> debugging plugin problems very hard.  Very few bug reports include
> a list of environment variables, and it is easy to imagine that a
> user unfamiliar with the binutils plugin code would not even realise
> that the problem might be due to a plugin being loaded from an 
> unexpected location because of an environment variable.

Yeah - the issue that made me report this is exactly a bugreport about
NM giving odd complaints on a specific archive where the issue was
some unrelated installed (buggy) plugin in the BFD auto-load directory ...

Still having an environment one can set allows central control to
have customer scripts "isolated" from stuff installed in the auto-load
directory.  At the same time it can introduce these issues of course.

> So instead I would suggest adding a --plugin-dir=<DIR> option which 
> could be used to override the builtin default.  It could even support
> --plugin-dir=NUL to stop any auto-loading and --plugin-dir=DEFAULT 
> to reset the search directory back to the builtin default.
> 
> What do you think ?

--plugin-dir sounds useful (as does the environment), since we implement
"first found and matching wins" a --plugin-add-dir is probably less
useful (you'd expect a match in the specified dir).

I think it would be nice to be able to set the default behavior
to --plugin-dir=NUL while still enabling plugin support in general.
(not sure about configuring a different non-NUL default)

Clearly a documented and consistently working --plugin="" is the most
important thing.

> Cheers
>   Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.