public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Sami Mujawar" <sami.mujawar@arm.com>
To: Rebecca Cran <rebecca@bsdio.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Oliver Smith-Denny <osde@linux.microsoft.com>
Cc: Hemendra Dassanayake <Hemendra.Dassanayake@arm.com>,
	Akanksha Jain <Akanksha.Jain2@arm.com>
Subject: Re: [edk2-devel] ArmPkg,ArmPlatformPkg: Adding nasm files to allow builds with VS2022
Date: Thu, 24 Oct 2024 09:08:00 +0000	[thread overview]
Message-ID: <AS8PR08MB6806CE7C1C3BFFC7AFD79B87844E2@AS8PR08MB6806.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <f64a49ae-ed00-489e-a8ed-bd18dca878e6@bsdio.com>

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

Hi Rebecca,

Thank you for bringing up this topic.

I agree we should get Visual Studio compiler support for Arm in edk2. The Visual Studio static analysis has helped to detect issues in DynamicTablesPkg in the past (when we did not have any dependency on assembly code).

I can see that Visual Studio Compiler support is already available in Project Mu. Would it be good to pull in the changes from there?
We would need to:

  *   look at the compatibility of the licenses.
  *   review and align any changes with the latest edk2 code base (Note this effort would be significantly less than starting from scratch).

@Oliver Smith-Denny<mailto:osde@linux.microsoft.com> is this something you can help with, please?

Regards,

Sami Mujawar


From: Rebecca Cran <rebecca@bsdio.com>
Date: Thursday, 24 October 2024 at 00:49
To: devel@edk2.groups.io <devel@edk2.groups.io>, Leif Lindholm <quic_llindhol@quicinc.com>, Sami Mujawar <Sami.Mujawar@arm.com>
Subject: ArmPkg,ArmPlatformPkg: Adding nasm files to allow builds with VS2022
I've been wondering if it might be worth adding nasm files to ArmPkg,
ArmPlatformPkg etc. to allow platforms to be built with VS2022 - mainly
because different compilers can detect different issues with the code.

What do people think: would it be worthwhile, or should we stick with
GCC and CLANG and avoid the maintenance overhead of another set of
assembly files?


--
Rebecca
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120680): https://edk2.groups.io/g/devel/message/120680
Mute This Topic: https://groups.io/mt/109181847/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 10710 bytes --]

  reply	other threads:[~2024-10-24  9:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-23 23:48 [edk2-devel] ArmPkg,ArmPlatformPkg: Adding nasm files to allow builds with VS2022 Rebecca Cran
2024-10-24  9:08 ` Sami Mujawar [this message]
2024-10-24 15:48   ` Oliver Smith-Denny
2024-10-24 16:31     ` Rebecca Cran

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AS8PR08MB6806CE7C1C3BFFC7AFD79B87844E2@AS8PR08MB6806.eurprd08.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox