From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6E30BA0613 for ; Thu, 26 Sep 2019 17:32:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 570F81E25; Thu, 26 Sep 2019 17:32:17 +0200 (CEST) Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) by dpdk.org (Postfix) with ESMTP id 3FA5D1DBE for ; Thu, 26 Sep 2019 17:32:15 +0200 (CEST) Received: by mail-lf1-f67.google.com with SMTP id r2so2041654lfn.8 for ; Thu, 26 Sep 2019 08:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bFK7v8PCavHd5P6AKw/90FrR49ReqRGsxGx0Tx8FZNY=; b=Als7a01a3DgXcooi+eTIP/EuD3y537xC/nlNkE+nfK4uhVK6sbxQnBRfCZ1OKEEMrV BzBWWVaZu7VQTF56CPqbvI/TiZ3toO6PQVXYHlTdAArkbrdDf/LGsz7v6PRlcHMtlMXv p1SY1EjgqyK8gen8wzbKhjZ0EwbtMMWwgs6h7X2UzhB5SP9QodQHaANOxegShbMMjKNM 82loQ6NZdj/tWR5b42NnsS/M4bUZyaWQQSAtlozw/9PrSFcohRCqLUg8fbpu2nST/BCF /0v0E7JJe5bR7hFYI1xyHVpFVzLY9p73oRZXgkCcxRcYD+iurmReCvA7reZCQOzDcwbH q7DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bFK7v8PCavHd5P6AKw/90FrR49ReqRGsxGx0Tx8FZNY=; b=OiLke+CItEsYAAxVVMukESEc8hHL97L9mqpKSTNEQcBg3Z9f8d991RkIGTTIsdJjl6 qeBP4L0Pw8ByXD92OmveMAwob3GjPPQ5jYDRy/czzgKNW2rMAW3LyJ59NqgWklJSMmmw 28yjy1q2NIxX4atb4xu1WW4PQGYs0Yk+CRA1codltAkR9XO2jOSd0zWGmeW2yjkEBSB6 npcddKpxXUQgTFqrtN6m30YF0shpC/h5RVXHxyc6HCkwYLCHxFrFKJchtD0ruCbm62FB qlMCj/EEGFLCfxnq6xrcKgSaByghY2wgxmggIRxqNtT8V70oixd9QXEM9SdmREQwudGy iO7w== X-Gm-Message-State: APjAAAXdB3qeu52C+nOVF+bTuH6MZmKaoaU+yHcpJixqlvhlmi7i/q21 7AvQZo9aXMHRWM7kWdXjN4/DVg== X-Google-Smtp-Source: APXvYqzElGO0VyamAx9b1iQiyMa7/4VqSNh4j1J1Dxq5wNE5lLOtDXVqf10PutBi/90nYL4mqZdRjA== X-Received: by 2002:ac2:4a8f:: with SMTP id l15mr2643165lfp.21.1569511934345; Thu, 26 Sep 2019 08:32:14 -0700 (PDT) Received: from [10.0.0.72] (31-172-191-173.noc.fibertech.net.pl. [31.172.191.173]) by smtp.gmail.com with ESMTPSA id 196sm559230ljj.76.2019.09.26.08.32.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Sep 2019 08:32:13 -0700 (PDT) To: Neil Horman , Bruce Richardson Cc: Thomas Monjalon , Ray Kinsella , dev@dpdk.org, Aaron Conole , Michael Santana , John McNamara , Marko Kovacevic , David Hunt , Vladimir Medvedkin , Robert Sanford , Erik Gabriel Carrillo , mattias.ronnblom@ericsson.com, stephen@networkplumber.org, Andrzej Ostruszka References: <20190917075754.8310-1-amo@semihalf.com> <20190919151624.GA1999@bricha3-MOBL.ger.corp.intel.com> <1873473.QF300kEeir@xps> <20190923120658.GA2003@bricha3-MOBL.ger.corp.intel.com> <20190923161326.GB2003@bricha3-MOBL.ger.corp.intel.com> <42bc3e03-768f-b90c-5f81-5a1cb525bb2f@semihalf.com> <20190924102534.GA2021@bricha3-MOBL.ger.corp.intel.com> <20190924125942.GA6041@hmswarspite.think-freely.org> From: Andrzej Ostruszka Message-ID: Date: Thu, 26 Sep 2019 17:32:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190924125942.GA6041@hmswarspite.think-freely.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 01/10] build: add an option to enable LTO build X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/24/19 2:59 PM, Neil Horman wrote: > On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote: >> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote: >>> On 9/23/19 6:13 PM, Bruce Richardson wrote: [...] >> The real issue seems to be that the compat.h header has different >> compilation paths for static and shared libraries, which means that any C >> file including it can't have a .o file that can be used for both a .a and a >> .so simultaneously. Having it default to the shared library path seems to >> work fine thus far, but with LTO it seems broken as you say. Adding Neil as >> the original file author of this in case he has any suggestions here. I'd >> really rather not have to go back to building .a's and .so's separately. >> > The notion of using the same object file to link to a static archive and a dso > seems somewhat suspect to me in general. I'd think so too ... but there might be something fishy with gcc here. More on this below. [...] > That said, if the goal is to just overcome this particular situation, it might > (strong might), be sufficient to simply augment the MAP_STATIC_SYMBOL macro in > the CONFIG_RTE_BUILD_SHARED_LIB=n case to append the 'used' attribute. > Ostensibly, LTO would be smart enough then to not eliminate the symbol? Just a > thought. Just to clarify things here is the current status in a nutshell. 1. The make based build work with LTO (both static and shared). It is using CONFIG_*_SHARED_LIB option and thus different paths of rte_compat.h are used. 2. The meson build is not using config and has "SHARED" fixed to "y" in config/rte_config.h. This works and produces: - shared library that is working when linking both w/ and w/o LTO - static library that is only working when linking w/o LTO - when linking with LTO then it complains about missing symbols for which different symbol versions are defined. Augmenting MAP_STATIC_SYMBOL won't help since it is not used at all in meson build. I've played around with couple ideas. Some of them might sound stupid for you - but I'll report them anyway Modifying symbol tables ----------------------- I thought that since problems are only with versioned symbols then I'll try to modify the symbols tables archives so they look like in "static make" case e.g. (for just one symbol): $ objcopy --strip-symbol=rte_timer_subsystem_init@DPDK_2.0 \ --redefine-sym \ rte_timer_subsystem_init@@DPDK_19.05=rte_timer_subsystem_init \ librte_timer.a After this the symbol table looks like in fully static case but this doesn't work so I'm pretty sure that when using LTO linker does not check the symbol table at all and just looks in "lto" sections. Adding static macro ------------------- I've added for the shared case macro: #define MAP_STATIC_SYMBOL(f, p) f \ __attribute__((alias(RTE_STR(p)),weak)) with the idea that maybe during linking against *.a versioned symbols are not taken into account and if I add weak non-versioned symbol then it will be used when linking against *.a and when linking against *.so the strong versioned one will be used. This thinking is in contrast with the fact that meson build works w/o LTO where only versioned symbols are present in those problematic libs :) - and it doesn't work. Linker reports multiple definitions. So adding these two together it seems to me that: a) gcc is using only internal "lto" sections when linking with LTO b) gcc is storing those versioned symbols in those "lto" sections c) when linking w/ LTO against archives is not capable to use those versioned symbols in "lto" sections d) when linking w/ LTO against shared libraries is capable to use versioned symbols from "lto" sections e) when linking w/o LTO against archive is capable to use versioned symbols from global symbol table (in contrast with point 'c' above) I'd appreciate some input from those who know gcc internals. In the meantime I'll try to come up with minimal example and follow up on gcc related lists/groups. Regards Andrzej