On 10 November 2014 17:12, Andy Polyakov wrote:
Attached is promised patch that reworks
interworking logic. As mentioned earlier idea is to use __ARM_ARCH__>=5
|| !defined(__thumb__). Rationale is that load to pc does interworking
since ARMv5, but without __thumb__ it does what
>> Well, it probably should be noted that Thumb code with non-Thumb shared
>> library on ARMv4 takes special compiler. At least stock gcc doesn't
>> generate those magic epilogues with moveq pc,lr, but simply issues
>> "target CPU does not support interworking" warning. And passing
>> -march=armv4t
Attached is promised patch that reworks
interworking logic. As mentioned earlier idea is to use __ARM_ARCH__>=5
|| !defined(__thumb__). Rationale is that load to pc does interworking
since ARMv5, but without __thumb__ it does what we need even on ARMv4.
>>>
>>> OK, this app
>>> Attached is promised patch that reworks
>>> interworking logic. As mentioned earlier idea is to use __ARM_ARCH__>=5
>>> || !defined(__thumb__). Rationale is that load to pc does interworking
>>> since ARMv5, but without __thumb__ it does what we need even on ARMv4.
>>>
>>
>> OK, this appears to
On 8 November 2014 17:56, Andy Polyakov wrote:
> arm-linux-gnueabi-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp
> -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=8 -DTERMIO -O3 -Wall
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DS
>> Attached is promised patch that reworks
>> interworking logic. As mentioned earlier idea is to use __ARM_ARCH__>=5
>> || !defined(__thumb__). Rationale is that load to pc does interworking
>> since ARMv5, but without __thumb__ it does what we need even on ARMv4.
>>
>
> OK, this appears to build
arm-linux-gnueabi-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp
-I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -D__ARM_MAX_ARCH__=8 -DTERMIO -O3 -Wall
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DAES_ASM -DB
On 3 November 2014 18:36, Andy Polyakov wrote:
> Anyway. As nobody seems to be objecting, it sounds like we are going for
> combination of both alternatives? I.e. those who specify specific -march
> lower than armv7 would be excused from capability detection and run-time
> switch,
On 3 November 2014 15:17, Andy Polyakov wrote:
Anyway. As nobody seems to be objecting, it sounds like we are going for
combination of both alternatives? I.e. those who specify specific -march
lower than armv7 would be excused from capability detection and run-time
switch, and
On 31 October 2014 18:12, Andy Polyakov wrote:
>> Anyway. As nobody seems to be objecting, it sounds like we are going for
>> combination of both alternatives? I.e. those who specify specific -march
>> lower than armv7 would be excused from capability detection and run-time
>> switch, and those wh
Anyway. As nobody seems to be objecting, it sounds like we are going for
combination of both alternatives? I.e. those who specify specific -march
lower than armv7 would be excused from capability detection and run-time
switch, and those who additionally specify "better" -Wa and
>>> Anyway. As nobody seems to be objecting, it sounds like we are going for
>>> combination of both alternatives? I.e. those who specify specific -march
>>> lower than armv7 would be excused from capability detection and run-time
>>> switch, and those who additionally specify "better" -Wa and
>>>
> Anyway. As nobody seems to be objecting, it sounds like we are going for
> combination of both alternatives? I.e. those who specify specific -march
> lower than armv7 would be excused from capability detection and run-time
> switch, and those who additionally specify "better" -Wa and
> correspond
'd like to handle this later as separate commit,
separate from one that will address the inconsistency in ARM support we
are talking about. As for simplified logic I plan to extent current #if
and settle for
#if __ARM_ARCH__>=5 || !defined(__thumb__)
ldmia
>>> OK, that sounds doable. But if -Wa is going to be used as a matter of
>>> course to pass arch/fpu options, we should get rid of all #ifdef's
>>> against things like __thumb2__, as they can be out of sync.
>> First of all users would have to recognize and accept that they can't
>> pass -march=ar
On 27 October 2014 21:42, Andy Polyakov wrote:
>> OK, that sounds doable. But if -Wa is going to be used as a matter of
>> course to pass arch/fpu options, we should get rid of all #ifdef's
>> against things like __thumb2__, as they can be out of sync.
>
> First of all users would have to recogniz
> OK, that sounds doable. But if -Wa is going to be used as a matter of
> course to pass arch/fpu options, we should get rid of all #ifdef's
> against things like __thumb2__, as they can be out of sync.
First of all users would have to recognize and accept that they can't
pass -march=armv4 to comp
>>> where the
>>> defaults are v4 and v8 respectively, and we can add Configure targets
>>> that narrow this down for targets like these?
>> Right now there is only one linux-armv4, and there is no
>> architecture-specific flag there. This implies that you either rely on
>> compiler default or pass
On 27 October 2014 15:11, Andy Polyakov wrote:
>>> I want to remind that question is *not* about removing run-time switch
>>> as concept, but rather about distinguishing pre-ARMv7 and ARMv>=7. I.e.
>>> NEON/cryto switch will stay, the only question if it's worth imposing it
>>> on pre-ARMv7 builds
>> I want to remind that question is *not* about removing run-time switch
>> as concept, but rather about distinguishing pre-ARMv7 and ARMv>=7. I.e.
>> NEON/cryto switch will stay, the only question if it's worth imposing it
>> on pre-ARMv7 builds [assuming that such binaries will be executed even
On 26 October 2014 22:43, Andy Polyakov wrote:
> Hi,
>
>>> There is inconsistency in ARM support and I'd like to gather some
>>> opinions on how to resolve it. Circulate this to ARM people near you.
>>>
>>> At some point an inconsistency of followi
On 26 Oct 2014 22:58, Andy Polyakov wrote:
> > I would go with option 2. and detect the ARM architecture that we are
> > compiling for in the configure phase and compile for it.
>
> As mentioned in another message question was not about removing run-time
> switch as concept, but about limiting it
Hi,
> I would go with option 2. and detect the ARM architecture that we are
> compiling for in the configure phase and compile for it.
As mentioned in another message question was not about removing run-time
switch as concept, but about limiting it to ARMv>=7 targets.
> My gut feeling is that it
Hi,
>> There is inconsistency in ARM support and I'd like to gather some
>> opinions on how to resolve it. Circulate this to ARM people near you.
>>
>> At some point an inconsistency of following nature was introduced and
>> then just grew. OpenSSL attempts to
On 24 October 2014 19:17, Andy Polyakov wrote:
> There is inconsistency in ARM support and I'd like to gather some
> opinions on how to resolve it. Circulate this to ARM people near you.
>
> At some point an inconsistency of following nature was introduced and
> then just gr
parts that are not written in assembly or
neon-optimized when compiling for specific architectures.
All the best,
William
On Fri, Oct 24, 2014 at 6:02 PM, Andy Polyakov wrote:
> There is inconsistency in ARM support and I'd like to gather some
> opinions on how to resolve it. Circul
There is inconsistency in ARM support and I'd like to gather some
opinions on how to resolve it. Circulate this to ARM people near you.
At some point an inconsistency of following nature was introduced and
then just grew. OpenSSL attempts to adapt to processor it's running on
by
27 matches
Mail list logo
