From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.12328.1676029538012009995 for ; Fri, 10 Feb 2023 03:45:38 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=G5p+Vl3R; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D000961D91 for ; Fri, 10 Feb 2023 11:45:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4418CC4339B for ; Fri, 10 Feb 2023 11:45:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676029536; bh=NMkAGNOlKxftBdEgUrsHY00XwYqemVUAq/CDX/UCqHA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=G5p+Vl3RY6J+kZTJGwiKWAgE4HGoHIsPQfvUZibgZg3GIEaAeQComK8hPEN68DGQX EpbwIBY4l+1J/SI0G9v63LN279bOpzrMpL1pWoskEsssZXmrAVQ3g95in1ClNd3H+Y p1T8v8SHmvSVpT+LfLnqPaQ7EcJZT0D8PA7Uy6mTHC5x0l5DO6Auaix7qqcGldXOWb gkgW3NREEnNrZ6IktQ94gSkSCORRXmYkOY4fi8aNx38WmjDPeHinn87c6wH18tCgqD WMxIHUrKKU29apRMZOF2y36CCJjhjNtJFwZgazAiv6woDOXX/Hu+9b6XFWdDyKqZ1G gTkHOeC5wO8KA== Received: by mail-lj1-f180.google.com with SMTP id a13so4269208ljq.6 for ; Fri, 10 Feb 2023 03:45:36 -0800 (PST) X-Gm-Message-State: AO0yUKVdg1sIrwn4V0wpyibtXclNmdft34iT7EmAyIvYu3T9WIRqvYkW Qp2ZTqbpNrYeu9dtE6PvP0iYM/iRCqAPcleMUcw= X-Google-Smtp-Source: AK7set//BK0N+4R7bfno9zGIw0XSrr+XF8Slys9MAL9Mdf3x5+8jysoTJVQuwKnazltHR6d9A5ww9yFgSQ7YNhjV59U= X-Received: by 2002:a2e:b4b2:0:b0:290:66b3:53e5 with SMTP id q18-20020a2eb4b2000000b0029066b353e5mr2797399ljm.57.1676029534275; Fri, 10 Feb 2023 03:45:34 -0800 (PST) MIME-Version: 1.0 References: <20230209154507.81877-1-rebecca@quicinc.com> <20230209154507.81877-2-rebecca@quicinc.com> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 10 Feb 2023 12:45:22 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 2/2] MdePkg: Update code to be more C11 compliant by using __func__ To: devel@edk2.groups.io, rebecca@bsdio.com Cc: michael.d.kinney@intel.com, "Gao, Liming" , "Liu, Zhiguang" , Leif Lindholm Content-Type: text/plain; charset="UTF-8" On Fri, 10 Feb 2023 at 02:21, Rebecca Cran wrote: > > Mike, > > Yes, it passed CI - see https://github.com/tianocore/edk2/pull/4022 . > > I wasn't sure if we cared about EBC builds these days. Given the link on > https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html > to the compiler goes to a generic page that doesn't mention it, is it > possible to get a copy if I want to verify if changes I'm making are > compatible? > We tried to get access to this at Linaro, but I don't think it is still available. Leif may remember better. > I know there was a project to add support for building EBC using LLVM, > but I'm not sure if anything came of it. > No that never went anywhere afaik. The problem was that, in EBC, sizeof() is not a compile time constant, and this breaks too many assumptions in the existing frontends, so this would only be feasible if we restricted ourselves to a specialized version of EBC that targets 64-bit architectures only, but this seems like a lot of effort for questionable benefits. Given that X64 code can run on arm64 under emulation without too many problems [0], and that the 32-bit ARM procedure call standard is fundamentally incompatible with EBC, the issue lost its urgency somewhat, at least from the side of ARM at the time. [0] https://github.com/ardbiesheuvel/X86EmulatorPkg I wonder whether we should simply drop EBC support? It is unlikely that all the changes that went into EDK2 over the years have not caused a single EBC regression in the library components that are needed to build UEFI drivers that target EBC. Or is this still being used/tested internally at Intel?