If what Antoine's saying is true, it has to do with ELF symbol visibility and the dubious concept of symbol "preemption". The NPAPI interface should actually only require a small number of symbols be "visible" from the plugin, and none (the best I know) from the browser. There's an interface description exchange at the start of the NPAPI module that handles the rest.
There are potential performance penalties on some architectures to permit symbol preemption, and it certainly inhibits cross-module optimization (whenever we would get to that in our builds). It would be best if we could use -fvisibility=hidden for all Linux binaries -- the browser, plugins, whatever. It would have been better still if the Linux community had made this crufty feature available on request rather than by default. David On Mon, Oct 26, 2009 at 10:10 AM, Evan Martin <[email protected]> wrote: > > On Mon, Oct 26, 2009 at 9:31 AM, Antoine Labour <[email protected]> wrote: > > On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe <[email protected]> > wrote: > >> The problem is that the chrome > >> executable (in particular statically linked in > >> libnpGoogleNaClPluginChrome.a) exports 'char > >> *NPP_GetMIMEDescription(void)' as a C symbol, which my plugin code > >> also implements and calls when NP_GetMIMEDescription() is called by > >> the browser. So chrome's Native Client Plugin's > >> NPP_GetMIMEDescription() takes preference and is called by my plugin > >> code instead of its own build-in NPP_GetMIMEDescription() > >> implementation. > >> > >> [snip] > >> > >> However, I'm not sure if chrome resp. libnpGoogleNaClPluginChrome.a > >> does it right with exporting these symbols as plain C symbols because > >> this might conflict with other existing plugins as well in the same > >> way. > > > > http://gcc.gnu.org/wiki/Visibility > > Make your plugin compile with -fvisibility=hidden, and only explicitly > > export the plugin functions by adding > __attribute__((visibility("default"))) > > That should fix this, and similar problems. > > Though agreed, Chrome should aim to do the same... > > I recall looking into this before, but I didn't fully understand what > I was doing. > > I think what you're saying is that Chrome by default exports all its > symbols to plugins embedded within it, even if those symbols may > conflict with the plugin's symbols. Doesn't NPAPI specify the limited > set of symbols (the NPN_*) we should provide, or is there more (like > malloc) that are implicitly shared? > > Since I don't know what I'm talking about, can you file a bug with a > recommendation as to what we should be doing? > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
