From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id 36C4C385B831 for ; Mon, 23 Mar 2020 15:39:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 36C4C385B831 Received: by mail-lf1-x144.google.com with SMTP id c20so10623726lfb.0 for ; Mon, 23 Mar 2020 08:39:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hxGo+Q6svfbL7bcBeX34PFqJeXgPEshKlFy7O9ofCi4=; b=X0YiAXgMfxv5GPN2SkqGpFhLg/PgmleDGrotopE88g3uIjlS7SnsnQxEFh8C4iTmxT CvHGc0W/c4bg326KeVPRwCvUjJW7SwcSIOsYeIPZLVd5zxQqoBAaGadV6ONwJ/BdOfYD zjuWsN3NqdydmIVZqiiPCzAmt34pfXLjW1UBg9zbQzcFnuywlh8B7TDmGh8/6sGG6JEF 9Tozc5ChX0Ycyjda8OAT/Rq8s/c8YHkumlZ7RahCFEjcq0OUsLAh2PboKWC2F53P4Xsi JGL6gG79l6w8i9C5YWcIy0UDE9XHyO5ja/hPie3QiePgpSMHiOardZvnT/ucOpp4JazC Ykeg== X-Gm-Message-State: ANhLgQ3itMpMlGy0mAkpDS/LZYEK5GzLYYEtn6+TuPtRqbtkiGbzzY0l Io7stcj9ySXAYgqH0t9RNenmWeQMIVgJQ+aRzno= X-Google-Smtp-Source: ADFU+vu2S6laduCMORPEb+PvlFNB9+4phMyZ9KGeF+WiAhhtlknwJ8tINLzI2WQM/NmE6unOf8I9GjG7p5NKeKQuy54= X-Received: by 2002:ac2:5203:: with SMTP id a3mr13643473lfl.152.1584977986871; Mon, 23 Mar 2020 08:39:46 -0700 (PDT) MIME-Version: 1.0 References: <82f5cda2-97f4-039e-5094-c528b220eb78@suse.cz> <20200323094308.GD2156@tucnak> <20200323101025.GE2156@tucnak> <7a5da5ef-1f97-c273-ca22-7621c419f1c3@suse.cz> <20200323103505.GF2156@tucnak> <6313e487-6dbb-ac17-4160-4ac600af40be@suse.cz> <7369b1aa-be0d-92cc-4f81-1612f101e2e8@suse.cz> In-Reply-To: <7369b1aa-be0d-92cc-4f81-1612f101e2e8@suse.cz> From: Richard Biener Date: Mon, 23 Mar 2020 16:39:35 +0100 Message-ID: Subject: Re: [PATCH] Check endianess detection. To: =?UTF-8?Q?Martin_Li=C5=A1ka?= , "H. J. Lu" Cc: Jakub Jelinek , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 15:39:49 -0000 On Mon, Mar 23, 2020 at 4:07 PM Martin Li=C5=A1ka 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 =3D 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 =3D 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