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
next prev parent 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