From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id 1C42F736B6 for ; Wed, 11 Nov 2015 13:34:36 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id tABDYZab028198 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Wed, 11 Nov 2015 05:34:35 -0800 Received: from Marks-MacBook-Pro.local (172.25.36.227) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.248.2; Wed, 11 Nov 2015 05:34:34 -0800 To: Alexander Kanavin , References: <5641FFD4.1050506@windriver.com> <56420F08.1050209@linux.intel.com> <56421DA6.5080700@windriver.com> <56433886.3060700@linux.intel.com> From: Mark Hatle X-Enigmail-Draft-Status: N1110 Organization: Wind River Systems Message-ID: <564343E9.9020702@windriver.com> Date: Wed, 11 Nov 2015 07:34:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56433886.3060700@linux.intel.com> Subject: Re: [PATCH 00/29] Add gobject introspection support to oe-core X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 13:34:37 -0000 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit On 11/11/15 6:45 AM, Alexander Kanavin wrote: > On 11/10/2015 06:39 PM, Mark Hatle wrote: > >>> This requires custom bitbake support I'm afraid, a specialist needs to >>> answer this. >>> >> >> Let me rephrase. Instead of calling out to qemu (or a real target) for a >> gobject and result. Can the result be cached (like we do with the config-site >> info?) This would allow me to run say a MIPS64 n64 gobject build, cache the >> results and use it on my octeon3 build (which can't run in QEMU.) > > The results in this case are .typelib files. They are raw dumps of a C > structure in memory - different compilers may produce different binary > representations of those. I wouldn't trust that they are the same and > that it's okay to copy them around like this. What makes you confident > that they are? For the same architecture (i.e. MIPS64) and the same ABI (n64), the resulting data structures, packing and similar should all be standard. Only the generated instructions and execution order would/could change. So you would need a way to generate, cache, store the results by arch/abi combo in order to do this. The issue of course is that you would need to declare the arch and abi -- the tune files are the natural place to do this (we really are declaring it there ANYWAY), and the tune features in many cases may have already done this... Something to consider -- the alternative is the dual object (one generic [arch/abi], one optimized for the tune) that can be used to run on QEMU. Twice the compile time but should work fine. Also has anyone looked at the .typelib information and determined if any of it is available via direct inspection via readelf, dwarf interpretation or other method that does not require execution? Is there a definition of the .typelib information anywhere and some simple examples of how its generated by the runtime objects? (To pursue this, the way forward is to determine a way to generate the .typelib by reading the chosen binaries in some way -- and then running a 'ptest' like check that the generated and runtime versions result in the same data.) --Mark > > Alex >