From: Richard Biener <richard.guenther@gmail.com>
To: "Martin Liška" <mliska@suse.cz>, "H. J. Lu" <hjl.tools@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Check endianess detection.
Date: Mon, 23 Mar 2020 16:39:35 +0100 [thread overview]
Message-ID: <CAFiYyc3yKQpWzh3Yzh7b40adi=gtFmYLeEZex_yCqYGSOdFcEw@mail.gmail.com> (raw)
In-Reply-To: <7369b1aa-be0d-92cc-4f81-1612f101e2e8@suse.cz>
On Mon, Mar 23, 2020 at 4:07 PM Martin Liška <mliska@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
next prev parent reply other threads:[~2020-03-23 15:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 9:25 Martin Liška
2020-03-23 9:43 ` Jakub Jelinek
2020-03-23 10:00 ` Martin Liška
2020-03-23 10:10 ` Jakub Jelinek
2020-03-23 10:28 ` Martin Liška
2020-03-23 10:35 ` Jakub Jelinek
2020-03-23 12:43 ` Martin Liška
2020-03-23 15:06 ` Martin Liška
2020-03-23 15:39 ` Richard Biener [this message]
2020-03-23 16:06 ` H.J. Lu
2020-03-23 17:17 ` Martin Liška
2020-03-23 17:40 ` H.J. Lu
2020-03-24 8:19 ` Martin Liška
2020-03-24 8:31 ` Jakub Jelinek
2020-03-24 8:49 ` Martin Liška
2020-03-24 9:18 ` Jakub Jelinek
2020-03-24 10:32 ` Martin Liška
2020-03-24 10:39 ` Jakub Jelinek
2020-03-31 13:27 ` [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro Maciej W. Rozycki
2020-04-01 5:01 ` Hans-Peter Nilsson
2020-04-01 7:43 ` Martin Liška
2020-04-01 23:57 ` Hans-Peter Nilsson
2020-04-01 7:17 ` Richard Biener
2020-04-01 7:41 ` Martin Liška
2020-04-01 9:55 ` Maciej W. Rozycki
2020-04-01 10:01 ` Martin Liška
2020-04-01 15:59 ` Maciej W. Rozycki
2020-04-01 16:54 ` Martin Liška
2020-04-01 17:28 ` Maciej W. Rozycki
2020-04-01 10:04 ` Maciej W. Rozycki
2020-04-01 10:09 ` Martin Liška
2020-03-23 15:16 ` [PATCH] Check endianess detection Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFiYyc3yKQpWzh3Yzh7b40adi=gtFmYLeEZex_yCqYGSOdFcEw@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=jakub@redhat.com \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).