From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a7-19.smtp-out.eu-west-1.amazonses.com (a7-19.smtp-out.eu-west-1.amazonses.com [54.240.7.19]) by mx.groups.io with SMTP id smtpd.web10.66604.1680517794702316032 for ; Mon, 03 Apr 2023 03:29:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ipxe.org header.s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2 header.b=d+sInXSp; spf=pass (domain: eu-west-1.amazonses.com, ip: 54.240.7.19, mailfrom: 0102018746aa8382-eabf5475-59a6-4741-a8b1-ca3d5b49da92-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2; d=ipxe.org; t=1680517792; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=5ic+QVREy0DDhKmj1uCoGke3+cn0Jbv/DqAKwHZj1Eo=; b=d+sInXSpCcQDO6y/CvrxB/RjeEVRydvz9Nn/f71XZBfsFqHNOn4eQ+PJPTjdeC8o Hc8aqewd/vnCWnvRVLfsY6BZHPh7C6/brqxW9exxVAb/RBIlGDVd7XxG6bFITklI6IC YeG9oHGqZQS1eZjZ8RyRlkyK6Z2RpT8HPKVK3rBciR5CabcgF1jP6kIebAO+7kZ/U6r /xE6z2QKYkyns7WvnrwemY+AKrsR1bGBDVc+AZiFSPpcFDZtWCUSCUgTRoY5j42bOuN LyPtEJ6oh/gNkuLWboQklQpMai4NAG4DlTjDaLzvCNhFEHEYaQ7TDOIrA+GsxRM+QMr pOWRUoL/Og== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=shh3fegwg5fppqsuzphvschd53n6ihuv; d=amazonses.com; t=1680517792; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=5ic+QVREy0DDhKmj1uCoGke3+cn0Jbv/DqAKwHZj1Eo=; b=QE82+Yyoh6IRzyiC0Vf/bSJaHuY54DjvazNoZDCBwJZOOO3Z0COdeujOt8iPEE6f k0gqsUBZlcOdLUQ/K11vvZ5Ojl7kYunoeOpuaVuke8jDyA8OVROtEKS6mzwZl0qkUcU OSM9yNlTBUVYIr69+FG5yFyidnVuj3WsWg95hJZg= Message-ID: <0102018746aa8382-eabf5475-59a6-4741-a8b1-ca3d5b49da92-000000@eu-west-1.amazonses.com> Date: Mon, 3 Apr 2023 10:29:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: devel@edk2.groups.io, lichao@loongson.cn, maobibo@loongson.cn Cc: WANG Xuerui , qemu-devel , Song Gao , =?UTF-8?B?5p2o5bCP5aif?= , Gerd Hoffmann References: <1f1d3d9f-c3df-4f29-df66-886410994cc3@xen0n.name> <67517424-0f32-09f8-6446-53f71ebd59b5@loongson.cn> <317e3008-e2bd-8af6-2cf5-dad49d98cb8d@loongson.cn> From: "Michael Brown" Subject: Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Feedback-ID: 1.eu-west-1.fspj4M/5bzJ9NLRzJP0PaxRwxrpZqiDQJ1IF94CF2TA=:AmazonSES X-SES-Outgoing: 2023.04.03-54.240.7.19 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/04/2023 11:13, Chao Li wrote: > This problem is because the gcc-12 does not yet to support the option > 'mno-explicit-reloc', this option is used to open the new reloaction > type for LoongArch, this new feature is very important for LoongArch, > because it can reduce the binary size and improve code execution > efficiency, so we turn it on when submitting the code to the EDK2 repo. Is it possible to produce a _functional_ LoongArch64 EDK2 binary without this option, even if the resulting binary is less efficient? (I'm the person who updated Fedora's binutils and cross-gcc packages to ensure that LoongArch64 was supported in Fedora 38, and this -mno-explicit-relocs issue is also currently blocking me from merging LoongArch64 support into iPXE.) Thanks, Michael