On 3/9/20 9:19 PM, Jan Hubicka wrote:
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška <mli...@suse.cz> wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introducing symbol types, why not support TLS?
About BSS and DATA I agree that it would be handy. I can theoretically
covered with code in get_variable_section/bss_initializer_p. But it's
quite logic and I'm not sure we should simulate it.
I think it should not be that hard to factor out the logic from
get_variable_section to return enum of what we want to do and then
have get_variale_section as a wrapper parsing this enum to actual
section.
So it was easier that I expected and I'm sending updated version
of the patch.
@Honza/Richi: Do you have any opinion about that?
I guess we indeed want to get as close to non-LTO nm behaviour as
possible. So we want to support them and perhaps think of .symtab
section file format that can be made backward compatible (such as having
attribute string for symbols where we can add new info in future in a
way that old plugins will still get info they want).
I like the idea. But it's probably next stage1 material. Or can you prepare
a patch?
Of course IPA optimizations may migrate symbols around (say from data to
bss)/take them away/rename them, but with that we need to live. I would
expect most tools inspecting nm are interested in what will enter
linking not what will be in final output.
Yes, there are mostly used during configure script run where they commonly
do not take final linked executables/shared libs.
Since we discuss plugin extensions (and I do not want this to complicate
finishing Martin's patch).
Please suggest that in another patch.
The current situation with binutils is bad because we can't build distribution
with -fno-common and LTO.
Martin
Are we aware of other plugin limitations?
One thing that I consider unsafe is the way we produce local names when
we need to promote symbol to hidden due to partitining. We add
.lto_priv, but that is not safe if we link with .o file that was
incrementally lto-optimized to target object file (this is reason why I
did not enabled WHOPR path for it).
We may also want to inform lld and llvm's gold plugin maintainers about
intended changes.
Honza
Thanks,
Martin
--
H.J.
>From 4214743fc011fd8900a89166759a5511d8da5da2 Mon Sep 17 00:00:00 2001
From: Martin Liska <mli...@suse.cz>
Date: Fri, 6 Mar 2020 18:09:35 +0100
Subject: [PATCH] API extension for binutils (type of symbols).
gcc/ChangeLog:
2020-03-09 Martin Liska <mli...@suse.cz>
* lto-streamer-out.c (write_symbol): Stream
symbol type.
include/ChangeLog:
2020-03-09 Martin Liska <mli...@suse.cz>
* lto-symtab.h (enum gcc_plugin_symbol_type): New.
* plugin-api.h (struct ld_plugin_symbol): New member
symbols_type.
(enum ld_plugin_symbol_type): New.
(enum ld_plugin_tag): Add new tag LDPT_GET_SYMBOLS_V4.
lto-plugin/ChangeLog:
2020-03-09 Martin Liska <mli...@suse.cz>
* lto-plugin.c (parse_table_entry): Parse symbol type.
---
gcc/lto-streamer-out.c | 14 ++++++++++++++
include/lto-symtab.h | 8 ++++++++
include/plugin-api.h | 14 +++++++++++++-
lto-plugin/lto-plugin.c | 13 +++++++++++++
4 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index cea5e71cffb..ead606eb665 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3. If not see
#include "print-tree.h"
#include "tree-dfa.h"
#include "file-prefix-map.h" /* remap_debug_filename() */
+#include "output.h"
static void lto_write_tree (struct output_block*, tree, bool);
@@ -2773,6 +2774,19 @@ write_symbol (struct streamer_tree_cache_d *cache,
lto_write_data (&c, 1);
c = (unsigned char) visibility;
lto_write_data (&c, 1);
+
+ gcc_plugin_symbol_type st;
+ if (TREE_CODE (t) == VAR_DECL)
+ {
+ section *s = get_variable_section (t, false);
+ st = (s->common.flags & SECTION_BSS
+ ? GCCST_VARIABLE_BSS : GCCST_VARIABLE_DATA);
+ }
+ else
+ st = GCCST_FUNCTION;
+
+ c = (unsigned char) st;
+ lto_write_data (&c, 1);
lto_write_data (&size, 8);
lto_write_data (&slot_num, 4);
}
diff --git a/include/lto-symtab.h b/include/lto-symtab.h
index 0ce0de10121..901bc3585c2 100644
--- a/include/lto-symtab.h
+++ b/include/lto-symtab.h
@@ -38,4 +38,12 @@ enum gcc_plugin_symbol_visibility
GCCPV_HIDDEN
};
+enum gcc_plugin_symbol_type
+{
+ GCCST_UNKNOWN,
+ GCCST_FUNCTION,
+ GCCST_VARIABLE_DATA,
+ GCCST_VARIABLE_BSS
+};
+
#endif /* GCC_LTO_SYMTAB_H */
diff --git a/include/plugin-api.h b/include/plugin-api.h
index 09e1202df07..794a2dcc4ee 100644
--- a/include/plugin-api.h
+++ b/include/plugin-api.h
@@ -92,6 +92,7 @@ struct ld_plugin_symbol
uint64_t size;
char *comdat_key;
int resolution;
+ int symbol_type;
};
/* An object's section. */
@@ -123,6 +124,16 @@ enum ld_plugin_symbol_visibility
LDPV_HIDDEN
};
+/* The type of the symbol. */
+
+enum ld_plugin_symbol_type
+{
+ LDST_UNKNOWN,
+ LDST_FUNCTION,
+ LDST_VARIABLE_DATA,
+ LDST_VARIABLE_BSS
+};
+
/* How a symbol is resolved. */
enum ld_plugin_symbol_resolution
@@ -431,7 +442,8 @@ 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_GET_SYMBOLS_V4 = 33,
};
/* The plugin transfer vector. */
diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
index c307fc871bf..230846c1d65 100644
--- a/lto-plugin/lto-plugin.c
+++ b/lto-plugin/lto-plugin.c
@@ -252,6 +252,14 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry,
LDPV_HIDDEN
};
+ enum ld_plugin_symbol_type symbol_types[] =
+ {
+ LDST_UNKNOWN,
+ LDST_FUNCTION,
+ LDST_VARIABLE_DATA,
+ LDST_VARIABLE_BSS
+ };
+
switch (sym_style)
{
case ss_win32:
@@ -296,6 +304,11 @@ parse_table_entry (char *p, struct ld_plugin_symbol *entry,
entry->visibility = translate_visibility[t];
p++;
+ t = *p;
+ check (t <= 3, LDPL_FATAL, "invalid symbol type found");
+ entry->symbol_type = symbol_types[t];
+ p++;
+
memcpy (&entry->size, p, sizeof (uint64_t));
p += 8;
--
2.25.1
