* Re: [PATCH][RFC] API extension for binutils (type of symbols). [not found] ` <6b621ea7-64a7-4792-022f-0449ab6da4a4@suse.cz> @ 2020-03-19 15:46 ` Richard Biener 2020-03-19 15:50 ` H.J. Lu 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2020-03-19 15:46 UTC (permalink / raw) To: Martin Liška, Binutils; +Cc: Jan Hubicka, GCC Patches, H. J. Lu On Thu, Mar 19, 2020 at 4:00 PM Martin Liška <mliska@suse.cz> wrote: > > On 3/19/20 10:12 AM, Richard Biener wrote: > > On Wed, Mar 18, 2020 at 9:52 AM Martin Liška <mliska@suse.cz> wrote: > >> > >> On 3/18/20 12:27 AM, Jan Hubicka wrote: > >>>> Hi. > >>>> > >>>> There's updated version of the patch. > >>>> Changes from the previous version: > >>>> - comment added to ld_plugin_symbol > >>>> - new section renamed to ext_symtab > >>>> - assert added for loop iterations in produce_symtab and produce_symtab_extension > >>> Hi, > >>> I hope this is last version of the patch. > >> > >> Hello. > >> > >> Yes. > >> > >>>> > >>>> 2020-03-12 Martin Liska <mliska@suse.cz> > >>>> > >>>> * lto-section-in.c: Add extension_symtab. > >>> ext_symtab :) > >> > >> Fixed. > >> > >>>> diff --git a/gcc/lto-section-in.c b/gcc/lto-section-in.c > >>>> index c17dd69dbdd..78b015be696 100644 > >>>> --- a/gcc/lto-section-in.c > >>>> +++ b/gcc/lto-section-in.c > >>>> @@ -54,7 +54,8 @@ const char *lto_section_name[LTO_N_SECTION_TYPES] = > >>>> "mode_table", > >>>> "hsa", > >>>> "lto", > >>>> - "ipa_sra" > >>>> + "ipa_sra", > >>>> + "ext_symtab" > >>> I would move ext_symtab next to symtab so the sections remains at least > >>> bit reasonably ordered. > >> > >> Ok, I'll adjust it and I will send a separate patch where we bump LTO_major_version. > >> > >>>> > >>>> +/* Write extension information for symbols (symbol type, section flags). */ > >>>> + > >>>> +static void > >>>> +write_symbol_extension_info (tree t) > >>>> +{ > >>>> + unsigned char c; > >>> Do we still use vertical whitespace after decls per GNU coding style? > >> > >> Dunno. This seems to me like a nit. > >> > >>>> diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h > >>>> index 25bf6c468f7..4f82b439360 100644 > >>>> --- a/gcc/lto-streamer.h > >>>> +++ b/gcc/lto-streamer.h > >>>> @@ -236,6 +236,7 @@ enum lto_section_type > >>>> LTO_section_ipa_hsa, > >>>> LTO_section_lto, > >>>> LTO_section_ipa_sra, > >>>> + LTO_section_symtab_extension, > >>> I guess symtab_ext to match the actual section name? > >> > >> No. See e.g. LTO_section_jump_functions - "jmpfuncs". We want to have more descriptive > >> enum names. > >> > >>>> LTO_N_SECTION_TYPES /* Must be last. */ > >>>> }; > >>>> > >>>> diff --git a/include/lto-symtab.h b/include/lto-symtab.h > >>>> index 0ce0de10121..47f0ff27df8 100644 > >>>> --- a/include/lto-symtab.h > >>>> +++ b/include/lto-symtab.h > >>>> @@ -38,4 +38,16 @@ enum gcc_plugin_symbol_visibility > >>>> GCCPV_HIDDEN > >>>> }; > >>>> > >>>> +enum gcc_plugin_symbol_type > >>>> +{ > >>>> + GCCST_UNKNOWN, > >>>> + GCCST_FUNCTION, > >>>> + GCCST_VARIABLE, > >>>> +}; > >>>> + > >>>> +enum gcc_plugin_symbol_section_flags > >>>> +{ > >>>> + GCCSSS_BSS = 1 > >>>> +}; > >>> > >>> Probably comments here? > >> > >> No. There are just shadow copy of enum types from plugin-api.h which > >> are documented. > >> > >>>> + > >>>> #endif /* GCC_LTO_SYMTAB_H */ > >>>> +/* Parse an entry of the IL symbol table. The data to be parsed is pointed > >>>> + by P and the result is written in ENTRY. The slot number is stored in SLOT. > >>>> + Returns the address of the next entry. */ > >>>> + > >>>> +static char * > >>>> +parse_table_entry_extension (char *p, struct ld_plugin_symbol *entry) > >>>> +{ > >>>> + unsigned char t; > >>>> + enum ld_plugin_symbol_type symbol_types[] = > >>>> + { > >>>> + LDST_UNKNOWN, > >>>> + LDST_FUNCTION, > >>>> + LDST_VARIABLE, > >>>> + }; > >>>> + > >>>> + t = *p; > >>>> + check (t <= 3, LDPL_FATAL, "invalid symbol type found"); > >>>> + entry->symbol_type = symbol_types[t]; > >>>> + p++; > >>>> + entry->section_flags = *p; > >>>> + p++; > >>>> + > >>>> + return p; > >>>> +} > >>> > >>> I think we have chance to make some plan for future extensions without > >>> introducing too many additional sections. > >>> > >>> Currently there are 2 bytes per entry, while only 3 bits are actively > >>> used of them. If we invent next flag to pass we can use unused bits > >>> however we need a way to indicate to plugin that the bit is defined. > >>> This could be done by a simple version byte at the beggining of > >>> ext_symtab section which will be 0 now and once we define extra bits we > >>> bump it up to 1. > >> > >> I like the suggested change, it can help us in the future. > >> > >>> > >>> It is not that important given that even empty file results in 2k LTO > >>> object file, but I think it would be nicer in longer run. > >>>> + /* This is for compatibility with older ABIs. */ > >>> Perhaps say here that this ABI defined only "int def;" > >> > >> Good point. > >> > >>> > >>> The patch look good to me. Thanks for the work! > >> > >> Thanks. I'm sending updated patch that I've just tested on lto.exp and > >> both binutils master and HJ's branch that utilizes the new API. > > > > @@ -495,10 +560,16 @@ write_resolution (void) > > > > /* Version 2 of API supports IRONLY_EXP resolution that is > > accepted by GCC-4.7 and newer. */ > > - if (get_symbols_v2) > > - get_symbols_v2 (info->handle, symtab->nsyms, syms); > > + if (get_symbols_v4) > > + get_symbols_v4 (info->handle, symtab->nsyms, syms); > > else > > - get_symbols (info->handle, symtab->nsyms, syms); > > + { > > + clear_new_symtab_flags (symtab); > > > > can you instead just avoid parsing the ext symtab? > > Yes, I simplified the changes and I bet we'll only need one new hook get_symbols_v2. > Then we can base parsing of the external symtab on that. > > > > > + if (get_symbols_v2) > > + get_symbols_v2 (info->handle, symtab->nsyms, syms); > > + else > > + get_symbols (info->handle, symtab->nsyms, syms); > > + } > > > > I guess this also points to the fact that LDs symbol resolution > > can't tell GCC it chose "BSS" (from a non-IL object) or that > > it chose a variable or function. > > > > @@ -296,6 +300,8 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry, > > entry->visibility = translate_visibility[t]; > > p++; > > > > + entry->unused = 0; > > + > > memcpy (&entry->size, p, sizeof (uint64_t)); > > p += 8; > > > > isn't that either not enough or too much clearing? > > I'd have expected > > > > entry->unused = entry->section_flags = entry->symbol_type = 0; > > > > _before_ > > > > t = *p; > > check (t <= 4, LDPL_FATAL, "invalid symbol kind found"); > > entry->def = translate_kind[t]; > > p++; > > > > ? > > Yes, that's better. > > > > > +enum ld_plugin_symbol_section_flags > > +{ > > + LDSSS_BSS = 1 > > +}; > > + > > > > please add a symbolic name for the value zero, > > may I suggest LDSSS_DEFAULT? I see you've > > settled on symbol_section_flags rather than > > section_kind (BSS is not really a flag...). > > I renamed that to ld_plugin_symbol_section_kind. > > May I install the 2 patches now? It's again tested on lto.exp > and both old binutils and new HJ's binutils patch and it works as expected. OK if HJ is happy, lto-symtab.h is owned by binutils I think and existing users might need to be adjusted to clear the unused fields now that the width of 'def' changed. Richard. > Martin > > > > > Otherwise looks OK to me. > > > > Thanks, > > Richard. > > > >> Martin > >> > >>> Honza > >>>> +#ifdef __BIG_ENDIAN__ > >>>> + char unused; > >>>> + char section_flags; > >>>> + char symbol_type; > >>>> + char def; > >>>> +#else > >>>> + char def; > >>>> + char symbol_type; > >>>> + char section_flags; > >>>> + char unused; > >>>> +#endif > >>>> int visibility; > >>>> uint64_t size; > >>>> char *comdat_key; > >>>> @@ -123,6 +134,20 @@ enum ld_plugin_symbol_visibility > >>>> LDPV_HIDDEN > >>>> }; > >>>> > >>>> +/* The type of the symbol. */ > >>>> + > >>>> +enum ld_plugin_symbol_type > >>>> +{ > >>>> + LDST_UNKNOWN, > >>>> + LDST_FUNCTION, > >>>> + LDST_VARIABLE, > >>>> +}; > >>>> + > >>>> +enum ld_plugin_symbol_section_flags > >>>> +{ > >>>> + LDSSS_BSS = 1 > >>>> +}; > >>>> + > >>>> /* How a symbol is resolved. */ > >>>> > >>>> enum ld_plugin_symbol_resolution > >>>> @@ -431,7 +456,9 @@ enum ld_plugin_tag > >>>> LDPT_GET_INPUT_SECTION_ALIGNMENT = 29, > >>>> LDPT_GET_INPUT_SECTION_SIZE = 30, > >>>> LDPT_REGISTER_NEW_INPUT_HOOK = 31, > >>>> - LDPT_GET_WRAP_SYMBOLS = 32 > >>>> + LDPT_GET_WRAP_SYMBOLS = 32, > >>>> + LDPT_ADD_SYMBOLS_V2 = 33, > >>>> + LDPT_GET_SYMBOLS_V4 = 34, > >>>> }; > >>>> > >>>> /* The plugin transfer vector. */ > >>>> -- > >>>> 2.25.1 > >>>> > >>> > >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] API extension for binutils (type of symbols). 2020-03-19 15:46 ` [PATCH][RFC] API extension for binutils (type of symbols) Richard Biener @ 2020-03-19 15:50 ` H.J. Lu 2020-03-19 16:00 ` Martin Liška 0 siblings, 1 reply; 6+ messages in thread From: H.J. Lu @ 2020-03-19 15:50 UTC (permalink / raw) To: Richard Biener; +Cc: Martin Liška, Binutils, Jan Hubicka, GCC Patches On Thu, Mar 19, 2020 at 8:46 AM Richard Biener <richard.guenther@gmail.com> wrote: > > On Thu, Mar 19, 2020 at 4:00 PM Martin Liška <mliska@suse.cz> wrote: > > > > On 3/19/20 10:12 AM, Richard Biener wrote: > > > On Wed, Mar 18, 2020 at 9:52 AM Martin Liška <mliska@suse.cz> wrote: > > >> > > >> On 3/18/20 12:27 AM, Jan Hubicka wrote: > > >>>> Hi. > > >>>> > > >>>> There's updated version of the patch. > > >>>> Changes from the previous version: > > >>>> - comment added to ld_plugin_symbol > > >>>> - new section renamed to ext_symtab > > >>>> - assert added for loop iterations in produce_symtab and produce_symtab_extension > > >>> Hi, > > >>> I hope this is last version of the patch. > > >> > > >> Hello. > > >> > > >> Yes. > > >> > > >>>> > > >>>> 2020-03-12 Martin Liska <mliska@suse.cz> > > >>>> > > >>>> * lto-section-in.c: Add extension_symtab. > > >>> ext_symtab :) > > >> > > >> Fixed. > > >> > > >>>> diff --git a/gcc/lto-section-in.c b/gcc/lto-section-in.c > > >>>> index c17dd69dbdd..78b015be696 100644 > > >>>> --- a/gcc/lto-section-in.c > > >>>> +++ b/gcc/lto-section-in.c > > >>>> @@ -54,7 +54,8 @@ const char *lto_section_name[LTO_N_SECTION_TYPES] = > > >>>> "mode_table", > > >>>> "hsa", > > >>>> "lto", > > >>>> - "ipa_sra" > > >>>> + "ipa_sra", > > >>>> + "ext_symtab" > > >>> I would move ext_symtab next to symtab so the sections remains at least > > >>> bit reasonably ordered. > > >> > > >> Ok, I'll adjust it and I will send a separate patch where we bump LTO_major_version. > > >> > > >>>> > > >>>> +/* Write extension information for symbols (symbol type, section flags). */ > > >>>> + > > >>>> +static void > > >>>> +write_symbol_extension_info (tree t) > > >>>> +{ > > >>>> + unsigned char c; > > >>> Do we still use vertical whitespace after decls per GNU coding style? > > >> > > >> Dunno. This seems to me like a nit. > > >> > > >>>> diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h > > >>>> index 25bf6c468f7..4f82b439360 100644 > > >>>> --- a/gcc/lto-streamer.h > > >>>> +++ b/gcc/lto-streamer.h > > >>>> @@ -236,6 +236,7 @@ enum lto_section_type > > >>>> LTO_section_ipa_hsa, > > >>>> LTO_section_lto, > > >>>> LTO_section_ipa_sra, > > >>>> + LTO_section_symtab_extension, > > >>> I guess symtab_ext to match the actual section name? > > >> > > >> No. See e.g. LTO_section_jump_functions - "jmpfuncs". We want to have more descriptive > > >> enum names. > > >> > > >>>> LTO_N_SECTION_TYPES /* Must be last. */ > > >>>> }; > > >>>> > > >>>> diff --git a/include/lto-symtab.h b/include/lto-symtab.h > > >>>> index 0ce0de10121..47f0ff27df8 100644 > > >>>> --- a/include/lto-symtab.h > > >>>> +++ b/include/lto-symtab.h > > >>>> @@ -38,4 +38,16 @@ enum gcc_plugin_symbol_visibility > > >>>> GCCPV_HIDDEN > > >>>> }; > > >>>> > > >>>> +enum gcc_plugin_symbol_type > > >>>> +{ > > >>>> + GCCST_UNKNOWN, > > >>>> + GCCST_FUNCTION, > > >>>> + GCCST_VARIABLE, > > >>>> +}; > > >>>> + > > >>>> +enum gcc_plugin_symbol_section_flags > > >>>> +{ > > >>>> + GCCSSS_BSS = 1 > > >>>> +}; > > >>> > > >>> Probably comments here? > > >> > > >> No. There are just shadow copy of enum types from plugin-api.h which > > >> are documented. > > >> > > >>>> + > > >>>> #endif /* GCC_LTO_SYMTAB_H */ > > >>>> +/* Parse an entry of the IL symbol table. The data to be parsed is pointed > > >>>> + by P and the result is written in ENTRY. The slot number is stored in SLOT. > > >>>> + Returns the address of the next entry. */ > > >>>> + > > >>>> +static char * > > >>>> +parse_table_entry_extension (char *p, struct ld_plugin_symbol *entry) > > >>>> +{ > > >>>> + unsigned char t; > > >>>> + enum ld_plugin_symbol_type symbol_types[] = > > >>>> + { > > >>>> + LDST_UNKNOWN, > > >>>> + LDST_FUNCTION, > > >>>> + LDST_VARIABLE, > > >>>> + }; > > >>>> + > > >>>> + t = *p; > > >>>> + check (t <= 3, LDPL_FATAL, "invalid symbol type found"); > > >>>> + entry->symbol_type = symbol_types[t]; > > >>>> + p++; > > >>>> + entry->section_flags = *p; > > >>>> + p++; > > >>>> + > > >>>> + return p; > > >>>> +} > > >>> > > >>> I think we have chance to make some plan for future extensions without > > >>> introducing too many additional sections. > > >>> > > >>> Currently there are 2 bytes per entry, while only 3 bits are actively > > >>> used of them. If we invent next flag to pass we can use unused bits > > >>> however we need a way to indicate to plugin that the bit is defined. > > >>> This could be done by a simple version byte at the beggining of > > >>> ext_symtab section which will be 0 now and once we define extra bits we > > >>> bump it up to 1. > > >> > > >> I like the suggested change, it can help us in the future. > > >> > > >>> > > >>> It is not that important given that even empty file results in 2k LTO > > >>> object file, but I think it would be nicer in longer run. > > >>>> + /* This is for compatibility with older ABIs. */ > > >>> Perhaps say here that this ABI defined only "int def;" > > >> > > >> Good point. > > >> > > >>> > > >>> The patch look good to me. Thanks for the work! > > >> > > >> Thanks. I'm sending updated patch that I've just tested on lto.exp and > > >> both binutils master and HJ's branch that utilizes the new API. > > > > > > @@ -495,10 +560,16 @@ write_resolution (void) > > > > > > /* Version 2 of API supports IRONLY_EXP resolution that is > > > accepted by GCC-4.7 and newer. */ > > > - if (get_symbols_v2) > > > - get_symbols_v2 (info->handle, symtab->nsyms, syms); > > > + if (get_symbols_v4) > > > + get_symbols_v4 (info->handle, symtab->nsyms, syms); > > > else > > > - get_symbols (info->handle, symtab->nsyms, syms); > > > + { > > > + clear_new_symtab_flags (symtab); > > > > > > can you instead just avoid parsing the ext symtab? > > > > Yes, I simplified the changes and I bet we'll only need one new hook get_symbols_v2. > > Then we can base parsing of the external symtab on that. > > > > > > > > + if (get_symbols_v2) > > > + get_symbols_v2 (info->handle, symtab->nsyms, syms); > > > + else > > > + get_symbols (info->handle, symtab->nsyms, syms); > > > + } > > > > > > I guess this also points to the fact that LDs symbol resolution > > > can't tell GCC it chose "BSS" (from a non-IL object) or that > > > it chose a variable or function. > > > > > > @@ -296,6 +300,8 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry, > > > entry->visibility = translate_visibility[t]; > > > p++; > > > > > > + entry->unused = 0; > > > + > > > memcpy (&entry->size, p, sizeof (uint64_t)); > > > p += 8; > > > > > > isn't that either not enough or too much clearing? > > > I'd have expected > > > > > > entry->unused = entry->section_flags = entry->symbol_type = 0; > > > > > > _before_ > > > > > > t = *p; > > > check (t <= 4, LDPL_FATAL, "invalid symbol kind found"); > > > entry->def = translate_kind[t]; > > > p++; > > > > > > ? > > > > Yes, that's better. > > > > > > > > +enum ld_plugin_symbol_section_flags > > > +{ > > > + LDSSS_BSS = 1 > > > +}; > > > + > > > > > > please add a symbolic name for the value zero, > > > may I suggest LDSSS_DEFAULT? I see you've > > > settled on symbol_section_flags rather than > > > section_kind (BSS is not really a flag...). > > > > I renamed that to ld_plugin_symbol_section_kind. > > > > May I install the 2 patches now? It's again tested on lto.exp > > and both old binutils and new HJ's binutils patch and it works as expected. > > OK if HJ is happy, lto-symtab.h is owned by binutils I think and existing > users might need to be adjusted to clear the unused fields now that the > width of 'def' changed. > > Richard. I like it and I will take case of binutils side. Thanks. -- H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] API extension for binutils (type of symbols). 2020-03-19 15:50 ` H.J. Lu @ 2020-03-19 16:00 ` Martin Liška 2020-03-19 16:51 ` H.J. Lu 0 siblings, 1 reply; 6+ messages in thread From: Martin Liška @ 2020-03-19 16:00 UTC (permalink / raw) To: H.J. Lu, Richard Biener; +Cc: Binutils, Jan Hubicka, GCC Patches On 3/19/20 4:50 PM, H.J. Lu wrote: > I like it and I will take case of binutils side. > > Thanks. Great. I've just installed the 2 patches to master. Martin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] API extension for binutils (type of symbols). 2020-03-19 16:00 ` Martin Liška @ 2020-03-19 16:51 ` H.J. Lu 2020-03-19 19:56 ` Richard Biener 0 siblings, 1 reply; 6+ messages in thread From: H.J. Lu @ 2020-03-19 16:51 UTC (permalink / raw) To: Martin Liška; +Cc: Richard Biener, Binutils, Jan Hubicka, GCC Patches On Thu, Mar 19, 2020 at 9:00 AM Martin Liška <mliska@suse.cz> wrote: > > On 3/19/20 4:50 PM, H.J. Lu wrote: > > I like it and I will take case of binutils side. > > > > Thanks. > > Great. I've just installed the 2 patches to master. > Here is the binutils patch: https://sourceware.org/pipermail/binutils/2020-March/110295.html -- H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] API extension for binutils (type of symbols). 2020-03-19 16:51 ` H.J. Lu @ 2020-03-19 19:56 ` Richard Biener 2020-03-19 20:07 ` H.J. Lu 0 siblings, 1 reply; 6+ messages in thread From: Richard Biener @ 2020-03-19 19:56 UTC (permalink / raw) To: H.J. Lu, Martin Liška; +Cc: Binutils, Jan Hubicka, GCC Patches On March 19, 2020 5:51:14 PM GMT+01:00, "H.J. Lu" <hjl.tools@gmail.com> wrote: >On Thu, Mar 19, 2020 at 9:00 AM Martin Liška <mliska@suse.cz> wrote: >> >> On 3/19/20 4:50 PM, H.J. Lu wrote: >> > I like it and I will take case of binutils side. >> > >> > Thanks. >> >> Great. I've just installed the 2 patches to master. >> > >Here is the binutils patch: > >https://sourceware.org/pipermail/binutils/2020-March/110295.html If the plugin advertises v2 support but the LTO IL files lack symtab_ext data what happens? Richard. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] API extension for binutils (type of symbols). 2020-03-19 19:56 ` Richard Biener @ 2020-03-19 20:07 ` H.J. Lu 0 siblings, 0 replies; 6+ messages in thread From: H.J. Lu @ 2020-03-19 20:07 UTC (permalink / raw) To: Richard Biener; +Cc: Martin Liška, Binutils, Jan Hubicka, GCC Patches On Thu, Mar 19, 2020 at 12:56 PM Richard Biener <richard.guenther@gmail.com> wrote: > > On March 19, 2020 5:51:14 PM GMT+01:00, "H.J. Lu" <hjl.tools@gmail.com> wrote: > >On Thu, Mar 19, 2020 at 9:00 AM Martin Liška <mliska@suse.cz> wrote: > >> > >> On 3/19/20 4:50 PM, H.J. Lu wrote: > >> > I like it and I will take case of binutils side. > >> > > >> > Thanks. > >> > >> Great. I've just installed the 2 patches to master. > >> > > > >Here is the binutils patch: > > > >https://sourceware.org/pipermail/binutils/2020-March/110295.html > > If the plugin advertises v2 support but the LTO IL files lack symtab_ext data what happens? Did you mean symbol_type == LDST_UNKNOWN? In that case, you get the text symbol for everything. -- H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-19 20:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200310110929.GA48643@kam.mff.cuni.cz>
[not found] ` <CAFiYyc1-1Q=g8zj+_YB=O5Mrda8feyQ_UZD5tCK7G_5hkVKR_w@mail.gmail.com>
[not found] ` <36d32a03-a4b5-1318-38b6-ece55fe7ed70@suse.cz>
[not found] ` <a835ab4d-9660-3bf2-90b1-8fa7aaf94d1f@suse.cz>
[not found] ` <CAFiYyc0+Ev3_qgjj1P8XORzX=s31WAsy1ccZ3_fj+ibMs5X9JQ@mail.gmail.com>
[not found] ` <78b445d1-ab4f-ad21-e3a1-aa791a15361c@suse.cz>
[not found] ` <CAFiYyc1R2Pej6Sjv1HGhgjz7CwpaLL2avC0Req2W9=tkKyMM0A@mail.gmail.com>
[not found] ` <15eb771d-6d3a-b9e3-3349-cabfb123cdc6@suse.cz>
[not found] ` <46cd4dbe-40ce-46c3-33fd-7d10f362262f@suse.cz>
[not found] ` <436149e2-6df2-6a5a-7612-e85661ed9bc3@suse.cz>
[not found] ` <20200317232705.GP66618@kam.mff.cuni.cz>
[not found] ` <ae89f626-41ee-f20c-eb2c-e72eb9198270@suse.cz>
[not found] ` <CAFiYyc1Fsh2nt4Rr96ZydciL-fGO5DnEHVwA5jJFJa3OCtTPGg@mail.gmail.com>
[not found] ` <6b621ea7-64a7-4792-022f-0449ab6da4a4@suse.cz>
2020-03-19 15:46 ` [PATCH][RFC] API extension for binutils (type of symbols) Richard Biener
2020-03-19 15:50 ` H.J. Lu
2020-03-19 16:00 ` Martin Liška
2020-03-19 16:51 ` H.J. Lu
2020-03-19 19:56 ` Richard Biener
2020-03-19 20:07 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).