On Wed, Mar 11, 2020 at 10:19 AM Martin Liška <mli...@suse.cz> wrote:
>
> On 3/10/20 1:07 PM, Martin Liška wrote:
> > On 3/10/20 12:24 PM, Richard Biener wrote:
> >> Not sure how symtab is encoded right now but we also could have
> >
> > Ok, right now I don't see symtab entry much extensible.
> >
> > But what am I suggesting is to parse LTO bytecode version and then
> > process conditional parsing of lto_symtab section.
> >
> > Thoughts?
> > Martin
>
> So as H.J. correctly pointed I can't add new symbol_type into
> ld_plugin_symbol struct.
> It would make ABI change as correctly identified by abidiff:
>
> abidiff /tmp/before.o /tmp/after.o
> Functions changes summary: 0 Removed, 1 Changed, 0 Added function
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> Function symbols changes summary: 0 Removed, 0 Added function symbol not
> referenced by debug info
> Variable symbols changes summary: 0 Removed, 1 Added variable symbol not
> referenced by debug info
>
> 1 function with some indirect sub-type change:
>
> [C]'function ld_plugin_status onload(ld_plugin_tv*)' at
> lto-plugin.c:1275:1 has some indirect sub-type changes:
> parameter 1 of type 'ld_plugin_tv*' has sub-type changes:
> in pointed to type 'struct ld_plugin_tv' at plugin-api.h:451:1:
> type size hasn't changed
> 1 data member changes (1 filtered):
> type of 'union {int tv_val; const char* tv_string;
> ld_plugin_register_claim_file tv_register_claim_file;
> ld_plugin_register_all_symbols_read tv_register_all_symbols_read;
> ld_plugin_register_cleanup tv_register_cleanup; ld_plugin_add_symbols
> tv_add_symbols; ld_plugin_get_symbols tv_get_symbols;
> ld_plugin_add_input_file tv_add_input_file; ld_plugin_message tv_message;
> ld_plugin_get_input_file tv_get_input_file; ld_plugin_get_view tv_get_view;
> ld_plugin_release_input_file tv_release_input_file;
> ld_plugin_add_input_library tv_add_input_library;
> ld_plugin_set_extra_library_path tv_set_extra_library_path;
> ld_plugin_get_input_section_count tv_get_input_section_count;
> ld_plugin_get_input_section_type tv_get_input_section_type;
> ld_plugin_get_input_section_name tv_get_input_section_name;
> ld_plugin_get_input_section_contents tv_get_input_section_contents;
> ld_plugin_update_section_order tv_update_section_order;
> ld_plugin_allow_section_ordering tv_allow_section_ordering;
> ld_plugin_allow_unique_segment_for_sections
> tv_allow_unique_segment_for_sections; ld_plugin_unique_segment_for_sections
> tv_unique_segment_for_sections; ld_plugin_get_input_section_alignment
> tv_get_input_section_alignment; ld_plugin_get_input_section_size
> tv_get_input_section_size; ld_plugin_register_new_input
> tv_register_new_input; ld_plugin_get_wrap_symbols tv_get_wrap_symbols;}
> ld_plugin_tv::tv_u' changed:
> type size hasn't changed
> 1 data member changes (1 filtered):
> type of 'ld_plugin_add_symbols tv_add_symbols' changed:
> underlying type 'enum ld_plugin_status (void*, int, const
> ld_plugin_symbol*)*' changed:
> in pointed to type 'function type enum ld_plugin_status
> (void*, int, const ld_plugin_symbol*)':
> parameter 3 of type 'const ld_plugin_symbol*' has sub-type
> changes:
> in pointed to type 'const ld_plugin_symbol':
> in unqualified underlying type 'struct
> ld_plugin_symbol' at plugin-api.h:86:1:
> type size changed from 256 to 288 (in bits)
> 1 data member insertion:
> 'int ld_plugin_symbol::symbol_type', at offset 256
> (in bits) at plugin-api.h:95:1
>
> So that I need to come up with ld_plugin_symbol_v2. It brings more
> challenges: one has 2 parallel symbol
> tables:
>
> struct plugin_symtab
> {
> ...
> struct ld_plugin_symbol_v2 *syms;
> struct ld_plugin_symbol *syms_v1;
> ...
> };
>
> and the information of these should by aligned.
>
> The patch can survive lto.exp and I would like to ask H.J. to write bintuils
> counterpart that will
> utilize the new LDPT_GET_SYMBOLS_V4, LDPT_ADD_SYMBOLS_V2.
>
> Thoughts?
Can't we simply have _V4/V2 use the upper half of
ld_plugin_symbol::def? If the linker
then requests _V4 but the plugin cannot cope it could still "use" the
data but get
LDST_UNKNOWN (zero) there.
IMHO LDST_VARIABLE_BSS is "misplaced"? "BSS" is the section of the variable.
If we want to encode more of ELF it should be LDST_OBJECT and LDST_FUNC.
Note there's also rodata vs data info that would be missing in case
we'd want tools
like readelf -s dump the symbol table of the IL part of an object. It
looks like
nm can also distinguish rodata from data ("R", "r" vs "d") and "small object"
data sections (not sure what's that about). It seems nm cannot distinguish
symbols in mergeable string sections (it dumps "R" for me there). So intead
of mangling everything into enum ld_plugin_symbol_type should we instead
add a
enum ld_plugin_symbol_special_section
{
LDSSS_DEFAULT,
LDSSS_BSS,
LDSSS_RODATA,
...
}
where LDSSS_DEFAULT means .text for FUNC and .data for OBJECT?
LDSSS_COMDAT might also apply but there's already the comdat_key
member which makes this info implicitely available.
Richard.
> Martin
>
>
