On Mon, Mar 23, 2020 at 4:07 PM Martin Liška <mli...@suse.cz> wrote:
>
> Hi.
>
> There's a patch draft that will do the proper versioning of API.
Would sth like this be preferred on the binutils side or would
splitting up the 'def' field via shift&masking better?
@@ -87,25 +87,30 @@ struct ld_plugin_symbol
{
char *name;
char *version;
- /* This is for compatibility with older ABIs. The older ABI defined
- only 'def' field. */
-#ifdef __BIG_ENDIAN__
- char unused;
...
+ int def;
int visibility;
uint64_t size;
char *comdat_key;
int resolution;
};
+/* A symbol belonging to an input file managed by the plugin library
+ (version 2). */
+
+struct ld_plugin_symbol_v2
+{
+ char *name;
+ char *version;
+ int def;
+ int visibility;
+ uint64_t size;
+ char *comdat_key;
+ int resolution;
+ char symbol_type;
+ char section_kind;
+ uint16_t unused;
+};
I think for ease of use you should do
struct ld_plugin_symbol_v2
{
ld_plugin_symbol v1_data;
char symbol_type;
char section_kind;
uint16_t unused;
}
also please avoid 'char', either use uint8_t or
at least unsigned char. I guess since you're extending
the type anyway using two plain 'int' would better follow
the rest of the data structure.
> It's a subject for discussion.
- status = add_symbols_v2 (file->handle, lto_file.symtab.nsyms,
- lto_file.symtab.syms);
+ {
+ /* Merge symtab::syms and symtab::syms_v2 data. */
+ for (unsigned int i = 0; i < lto_file.symtab.nsyms; i++)
+ {
I think lto-plugin should internally always parse into the "full" format,
using defaults for entries not in IL files. Only the interfacing with
the linker should then decide.
>
> Martin
