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 349D0A0613 for ; Tue, 24 Sep 2019 18:02:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F1C912BE9; Tue, 24 Sep 2019 18:02:06 +0200 (CEST) Received: from q2relay87.mxroute.com (q2relay87.mxroute.com [160.202.107.87]) by dpdk.org (Postfix) with ESMTP id BB70923D for ; Tue, 24 Sep 2019 18:02:05 +0200 (CEST) Received: from filter001.mxrelay.co ([64.52.23.203] filter001.mxrelay.co) (Authenticated sender: mN4UYu2MZsgR) by q2relay87.mxroute.com (ZoneMTA) with ESMTPSA id 16d640210f70004110.002 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 24 Sep 2019 16:02:00 +0000 X-Zone-Loop: f6fd95c6ef79a66a7812e02f974431a238958950fa0e X-Originating-IP: [64.52.23.203] Received: from galaxy.mxroute.com (unknown [23.92.70.113]) by filter001.mxrelay.co (Postfix) with ESMTPS id 1C81D1003A9; Tue, 24 Sep 2019 16:01:59 +0000 (UTC) Received: from [192.198.151.43] by galaxy.mxroute.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1iCn7Z-0007ln-NU; Tue, 24 Sep 2019 11:52:57 -0400 To: Neil Horman , Bruce Richardson Cc: Andrzej Ostruszka , Thomas Monjalon , 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: Ray Kinsella Openpgp: preference=signencrypt Autocrypt: addr=mdr@ashroe.eu; keydata= mQINBFv8B3wBEAC+5ImcgbIvadt3axrTnt7Sxch3FsmWTTomXfB8YiuHT8KL8L/bFRQSL1f6 ASCHu3M89EjYazlY+vJUWLr0BhK5t/YI7bQzrOuYrl9K94vlLwzD19s/zB/g5YGGR5plJr0s JtJsFGEvF9LL3e+FKMRXveQxBB8A51nAHfwG0WSyx53d61DYz7lp4/Y4RagxaJoHp9lakn8j HV2N6rrnF+qt5ukj5SbbKWSzGg5HQF2t0QQ5tzWhCAKTfcPlnP0GymTBfNMGOReWivi3Qqzr S51Xo7hoGujUgNAM41sxpxmhx8xSwcQ5WzmxgAhJ/StNV9cb3HWIoE5StCwQ4uXOLplZNGnS uxNdegvKB95NHZjRVRChg/uMTGpg9PqYbTIFoPXjuk27sxZLRJRrueg4tLbb3HM39CJwSB++ YICcqf2N+GVD48STfcIlpp12/HI+EcDSThzfWFhaHDC0hyirHxJyHXjnZ8bUexI/5zATn/ux TpMbc/vicJxeN+qfaVqPkCbkS71cHKuPluM3jE8aNCIBNQY1/j87k5ELzg3qaesLo2n1krBH bKvFfAmQuUuJT84/IqfdVtrSCTabvDuNBDpYBV0dGbTwaRfE7i+LiJJclUr8lOvHUpJ4Y6a5 0cxEPxm498G12Z3NoY/mP5soItPIPtLR0rA0fage44zSPwp6cQARAQABtBxSYXkgS2luc2Vs bGEgPG1kckBhc2hyb2UuZXU+iQJUBBMBCAA+FiEEcDUDlKDJaDuJlfZfdJdaH/sCCpsFAlv8 B3wCGyMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdJdaH/sCCptdtRAAl0oE msa+djBVYLIsax+0f8acidtWg2l9f7kc2hEjp9h9aZCpPchQvhhemtew/nKavik3RSnLTAyn B3C/0GNlmvI1l5PFROOgPZwz4xhJKGN7jOsRrbkJa23a8ly5UXwF3Vqnlny7D3z+7cu1qq/f VRK8qFyWkAb+xgqeZ/hTcbJUWtW+l5Zb+68WGEp8hB7TuJLEWb4+VKgHTpQ4vElYj8H3Z94a 04s2PJMbLIZSgmKDASnyrKY0CzTpPXx5rSJ1q+B1FCsfepHLqt3vKSALa3ld6bJ8fSJtDUJ7 JLiU8dFZrywgDIVme01jPbjJtUScW6jONLvhI8Z2sheR71UoKqGomMHNQpZ03ViVWBEALzEt TcjWgJFn8yAmxqM4nBnZ+hE3LbMo34KCHJD4eg18ojDt3s9VrDLa+V9fNxUHPSib9FD9UX/1 +nGfU/ZABmiTuUDM7WZdXri7HaMpzDRJUKI6b+/uunF8xH/h/MHW16VuMzgI5dkOKKv1LejD dT5mA4R+2zBS+GsM0oa2hUeX9E5WwjaDzXtVDg6kYq8YvEd+m0z3M4e6diFeLS77/sAOgaYL 92UcoKD+Beym/fVuC6/55a0e12ksTmgk5/ZoEdoNQLlVgd2INtvnO+0k5BJcn66ZjKn3GbEC VqFbrnv1GnA58nEInRCTzR1k26h9nmS5Ag0EW/wHfAEQAMth1vHr3fOZkVOPfod3M6DkQir5 xJvUW5EHgYUjYCPIa2qzgIVVuLDqZgSCCinyooG5dUJONVHj3nCbITCpJp4eB3PI84RPfDcC hf/V34N/Gx5mTeoymSZDBmXT8YtvV/uJvn+LvHLO4ZJdvq5ZxmDyxfXFmkm3/lLw0+rrNdK5 pt6OnVlCqEU9tcDBezjUwDtOahyV20XqxtUttN4kQWbDRkhT+HrA9WN9l2HX91yEYC+zmF1S OhBqRoTPLrR6g4sCWgFywqztpvZWhyIicJipnjac7qL/wRS+wrWfsYy6qWLIV80beN7yoa6v ccnuy4pu2uiuhk9/edtlmFE4dNdoRf7843CV9k1yRASTlmPkU59n0TJbw+okTa9fbbQgbIb1 pWsAuicRHyLUIUz4f6kPgdgty2FgTKuPuIzJd1s8s6p2aC1qo+Obm2gnBTduB+/n1Jw+vKpt 07d+CKEKu4CWwvZZ8ktJJLeofi4hMupTYiq+oMzqH+V1k6QgNm0Da489gXllU+3EFC6W1qKj tkvQzg2rYoWeYD1Qn8iXcO4Fpk6wzylclvatBMddVlQ6qrYeTmSbCsk+m2KVrz5vIyja0o5Y yfeN29s9emXnikmNfv/dA5fpi8XCANNnz3zOfA93DOB9DBf0TQ2/OrSPGjB3op7RCfoPBZ7u AjJ9dM7VABEBAAGJAjwEGAEIACYWIQRwNQOUoMloO4mV9l90l1of+wIKmwUCW/wHfAIbDAUJ CWYBgAAKCRB0l1of+wIKm3KlD/9w/LOG5rtgtCUWPl4B3pZvGpNym6XdK8cop9saOnE85zWf u+sKWCrxNgYkYP7aZrYMPwqDvilxhbTsIJl5HhPgpTO1b0i+c0n1Tij3EElj5UCg3q8mEc17 c+5jRrY3oz77g7E3oPftAjaq1ybbXjY4K32o3JHFR6I8wX3m9wJZJe1+Y+UVrrjY65gZFxcA thNVnWKErarVQGjeNgHV4N1uF3pIx3kT1N4GSnxhoz4Bki91kvkbBhUgYfNflGURfZT3wIKK +d50jd7kqRouXUCzTdzmDh7jnYrcEFM4nvyaYu0JjSS5R672d9SK5LVIfWmoUGzqD4AVmUW8 pcv461+PXchuS8+zpltR9zajl72Q3ymlT4BTAQOlCWkD0snBoKNUB5d2EXPNV13nA0qlm4U2 GpROfJMQXjV6fyYRvttKYfM5xYKgRgtP0z5lTAbsjg9WFKq0Fndh7kUlmHjuAIwKIV4Tzo75 QO2zC0/NTaTjmrtiXhP+vkC4pcrOGNsbHuaqvsc/ZZ0siXyYsqbctj/sCd8ka2r94u+c7o4l BGaAm+FtwAfEAkXHu4y5Phuv2IRR+x1wTey1U1RaEPgN8xq0LQ1OitX4t2mQwjdPihZQBCnZ wzOrkbzlJMNrMKJpEgulmxAHmYJKgvZHXZXtLJSejFjR0GdHJcL5rwVOMWB8cg== Message-ID: <41d78c15-adfd-3800-efa4-5fb196bc6fa4@ashroe.eu> Date: Tue, 24 Sep 2019 17:01:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.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: 8bit X-AuthUser: mdr@ashroe.eu 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 24/09/2019 13:59, 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: >>> [...] >>>> However, testing on my system with the meson build, I'm getting lots of >>>> link errors [See below]. Any suggestions? >>>> >>>> /Bruce >>>> >>>> /usr/bin/ld: /tmp/dpdk-testpmd.hncbtE.ltrans93.ltrans.o: in function `ena_stop': >>>> :(.text+0x9ed6): undefined reference to `rte_timer_stop' >>> [...] >>> > The notion of using the same object file to link to a static archive and a dso > seems somewhat suspect to me in general. Well I would say there are two different things going on here, one doesn't exclude the other. > I say that because I don't see a way > for the linker to know/prove at link time that the options used to compile an > object for target (a) will be the same as those used to compile the same object > for target (b). Yes and no. So I might build an object differently for say a different platform, but I am not sure I would necessarily build it differently for static versus dynamic (linking is a different story of course). (lto is also a different story, as when you build objects with lto on, as I remember you end up with guile not bytecode) > In this particular case, you've identified an issue in > compilation changes that triggers off the building of dso's vs static archives, > but I could envision a scenario in which you might try to build targets for BSD > and Linux in parallel, or even for different machines (i.e. build for a least > common denominator x8664 target, and a highly optimized recent x8664 processor > with all the ISA extensions enabled). We don't do that currently now of course, > but we could, and the only way we could do so would be to rebuild all the > objects with the compilation flags for each separately. Ok - but there is nothing in the above in this that precludes all of these object variants being used in both static and dynamic builds, it's all down to how they are integrated - FD.io VPP does this out of the box as it happens. > > 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. +1, that would be a simple solution. > > But I think we need to take care here. While its fine solve this particular > situation, I think the notion of reusing objects for multiple link targets has > the potential to uncover many issues of this class, which won't be as solveable > without having to just rebuild objects from scratch. > > Neil > >> Regards, >> /Bruce >>