public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Pete Batard <pete@akeo.ie>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Cohen, Eugene" <eugene@hp.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>
Subject: Re: [PATCH v4 4/6] ArmPkg/Library/CompilerIntrinsicsLib: Enable VS2017/ARM builds
Date: Fri, 12 Jan 2018 11:10:51 +0000	[thread overview]
Message-ID: <e784347a-7494-6396-7b14-1de8bbc4c769@akeo.ie> (raw)
In-Reply-To: <CAKv+Gu-yf2o+TfxKtAgUBPkq2DgR2c8F9HQ6qnhJ8T7LTt=Odg@mail.gmail.com>

On 2018.01.12 09:58, Ard Biesheuvel wrote:
>>> So, to summarise, I would much prefer if we could keep most of the
>>> current patch, and simply use the following where needed:
>>>
>>> AREA  s___aeabi_ldivmod, CODE, READONLY, ARM AREA  s___aeabi_llsr,
>>> CODE, READONLY, ARM AREA  s___aeabi_uldivmod, CODE, READONLY,
>>> ARM
>>>
>>
>> Agreed, this is fine so long as we agree on the definition of "where needed".  In general I would expect each independent assembly function to have its own AREA directive (e.g. math functions).  In some cases there will clearly be a collection of dependent functions that would be better served by a single area directive (e.g. MMU initialization functions).
>>
>> Much Thanks!
>>
>> Eugene
>>
> 
> Agreed.

Okay.

Introducing/grouping/reviewing the code areas goes beyond the scope of 
what I am planning to do for this proposal, especially as the current 
goal is to leave RVCT with as little disturbance as possible, even if 
some improvements might be applied...

So the only thing I am planning to do with the AREA's right now is have 
them under the exact same name they would have used with the RVCT_... 
macros.

I'll send a new patch to that effect in a couple hours.

Regards,

/Pete


  reply	other threads:[~2018-01-12 11:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 16:26 [PATCH v4 0/6] Add ARM support for VS2017 Pete Batard
2018-01-10 16:26 ` [PATCH v4 1/6] MdePkg: Disable some Level 4 warnings for VS2017/ARM Pete Batard
2018-01-10 16:26 ` [PATCH v4 2/6] MdePkg/Library/BaseStackCheckLib: Add Null handler " Pete Batard
2018-01-10 16:26 ` [PATCH v4 3/6] MdePkg/Library/BaseLib: Enable VS2017/ARM builds Pete Batard
2018-01-10 16:26 ` [PATCH v4 4/6] ArmPkg/Library/CompilerIntrinsicsLib: " Pete Batard
2018-01-11 10:46   ` Ard Biesheuvel
2018-01-11 15:30     ` Cohen, Eugene
2018-01-11 16:31       ` Pete Batard
2018-01-11 16:56         ` Cohen, Eugene
2018-01-12  9:58           ` Ard Biesheuvel
2018-01-12 11:10             ` Pete Batard [this message]
2018-01-12 13:25               ` Ard Biesheuvel
2018-01-10 16:26 ` [PATCH v4 5/6] MdePkg/Include: Add VA list support for VS2017/ARM Pete Batard
2018-01-10 16:26 ` [PATCH v4 6/6] BaseTools/Conf: Add VS2017/ARM support Pete Batard

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=e784347a-7494-6396-7b14-1de8bbc4c769@akeo.ie \
    --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