[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-06-08 23:21 --- Subject: Bug 44459 Author: amylaar Date: Tue Jun 8 23:21:48 2010 New Revision: 160448 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160448 Log: PR plugins/44459: * gcc-plugin.h: Encapsulate all declarations in extern "C". Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-plugin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-06-08 20:34 --- (In reply to comment #5) > There is no specifications for plugins really. And really this is on purpose > as we don't want to freeze down the rest of the compiler just for plugins. There is a difference between freezing the rest of the compiler and making reasonable adaptations to avoid unnecessary interface churn / cross-language linking issues. I intend to apply the approved patch to gcc-plugin.h on Wednesday (we are supposedly still in a trunk freeze right now, even though I have seen a few non-merge patches going in). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-08 19:55 --- There is no specifications for plugins really. And really this is on purpose as we don't want to freeze down the rest of the compiler just for plugins. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-08 12:40 --- This is the patch set for the fix: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00741.html http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00740.html -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-08 09:56 --- (In reply to comment #2) > "By switching the GCC build language to C++, we introduce name mangling, > which means that we loose plugin dynamic link compatibility to previous > versions of gcc. Also, the interface becomes subject to change when mangling > changes, and will not be compatible if the build compiler uses a different > mangling scheme. Moreover, it forces to compile plugins with C++." > > > Exactly as designed. I don't recall any specification for our plugins that says we can use any implementation language, as long it is C++. > We do not have a plugin interface (our interface > is called dlopen). Plugins have to deal with that. As per plugins.texi, the documented way to pass the GPL license test only works when the plugin is compiled as C code. "int plugin_is_GPL_compatible;" will give a different mangled symbol name when compiled as C++. The comment at the start of gcc-plugin.h states: "Public header file for plugins to include", hence this is part of the plugin interface. The way this header file is now, it will not work when the compiler is built with a C++ compiler, but the plugin is build with a C compiler. Hence, plugins will not work as documented when the compiler is build with a C++ compiler, no matter what compiler you use for the plugins. A small change to the header files will go a long way to allow simple plugins to continue to work as advertised, and preserve interoperability with more languages and compilers, including possible future variants of g++ with mangling differences. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 08:51 --- "By switching the GCC build language to C++, we introduce name mangling, which means that we loose plugin dynamic link compatibility to previous versions of gcc. Also, the interface becomes subject to change when mangling changes, and will not be compatible if the build compiler uses a different mangling scheme. Moreover, it forces to compile plugins with C++." Exactly as designed. We do not have a plugin interface (our interface is called dlopen). Plugins have to deal with that. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-08 00:17 --- Using C linkage for all of gcc-plugin.h is straightforward, and we it also makes sense to put some popular other symbols there, e.g. warning. However, there is a limit what we can reasonably put into C linkage without restricting the C++ features that we can use overall (i.e. overload is impossible if everything has C linkage). E.g. the ICI plugin uses: [amyl...@laria ici]$ nm ici.so|grep '\'|grep -v @@GLIBC_2 U aggregate_value_p U all_lowering_passes U all_lto_gen_passes U all_passes U all_regular_ipa_passes U all_small_ipa_passes U build3_stat U build_fn_decl U build_function_call_expr U build_function_type U build_int_cst U build_optimization_node U cfun U cgraph_create_edge U cgraph_create_virtual_clone U cgraph_function_body_availability U cgraph_mark_needed_node U cgraph_node U cgraph_nodes U cl_optimization_restore U cl_optimization_save U cl_options U cl_options_count U compiler_params U create_artificial_label U create_basic_block U create_tmp_var U current_function_decl U current_function_name U current_pass U decode_options U dlerror U dlopen U dlsym U do_per_function_toporder U execute_ipa_pass_list U execute_ipa_summary_passes U execute_one_pass U execute_pass_list U expand_location U fancy_abort U find_opt U flag_asynchronous_unwind_tables U flag_omit_frame_pointer U flag_pcc_struct_return U flag_strict_aliasing U flags_from_decl_or_type U gen_rtx_fmt_s00_stat U get_event_last U get_identifier U get_named_event_id U get_num_compiler_params U get_option_state U gimple_build_call_from_tree U gimple_build_label U gimple_build_return U gimple_build_switch_vec U gimple_check_failed U gimple_ops_offset_ U gimple_set_modified U gimplify_stmt U global_trees U gsi_insert_after U gsi_insert_before U gsi_insert_seq_after U gsi_insert_seq_before U gss_for_code_ U htab_create_alloc U htab_elements U htab_find U htab_find_slot U htab_hash_string U htab_remove_elt U htab_traverse_noresize U integer_types U internal_error U invoke_plugin_callbacks U is_gimple_operand U is_gimple_reg_type U main_input_filename U make_decl_rtl U make_edge U nreverse U pass_early_local_passes U pass_fini_dump_file U pass_init_dump_file U passes_by_id U passes_by_id_size U plugin_event_name U quiet_flag U register_callback U remove_edge U replace_equiv_address_nv U set_cfun U set_decl_rtl U sort_case_labels U split_block U tree_check_failed U tree_class_check_failed U tree_code_length U tree_code_type U tree_cons_stat U tree_contains_struct U tree_contains_struct_check_failed U tree_operand_check_failed U unregister_callback U update_stmt_operands U vec_assert_fail U vec_heap_p_reserve U vec_heap_p_reserve_exact U xcalloc U xmalloc Thus, for plugins that use some internal symbols with (potential?) C++ name-mangling, we want a way to use a compiler that produces DSOs that are compatible with the gcc compiler binary, inasmuch as that is feasible. Likewise, PR 42843 still remains relevant because some of the tests use somewhat uncommon symbols, e.g. cgraph_build_static_cdtor in finish_unit_plugin.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
