Re: [2/2 ABI and toolchain part] Support Raspberry Pi [0-3] in big-endian mode

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

One correction: swp{,b} are deprecated but still supported on ARMv6.
So we need emulation for ARMv7 and later.

On 2020/11/25 23:18, Robert Swindells wrote:
> Has the testcase in bug 55704 been run on an earmv7 system to check
> whether it happens there as well as on aarch64 ?

Yes, ctfmerge for ARMv5 freezes also on MP AMRv7 system with SW-bit in
SCTLR register is set. At the moment, I don't know what we can do...

On 2020/11/27 8:53, matthew green wrote:
> > Oops, it was wrong. ARM ARM "ARMv7-A and ARMv7-R edition", or, more
> > concisely, their web page says swp{,b} instructions on ARMv7 work for
> > MP system:
> >
> > https://developer.arm.com/documentation/dht0008/a/swp-and-swpb/legacy-synchronization-instructions/limitations-of-swp-and-swpb
> >
> > | Limitations of SWP and SWPB
> > | ...
> > | In a multi-core system, preventing access to main memory for all
> > | processors for the duration of a swap instruction can reduce
> > | overall system performance.
> > | ...
> >
> > So, I guess that mrg@ disabled swp{,b} for MULTIPROCESSOR not because
> > instructions their-selves do not work, but because there are other
> > problems for ARMv5 userland on MP environment. As Robert suggested in
> > his previous message, multi-threaded applications for ARMv5 do not
> > work on MP system. See port-arm/55704 by myself:
> >
> > http://gnats.netbsd.org/55704
> >
> > Matthew, is this reason why you disabled them for MP kernel?
>
> the above link and info aren't the full story.
>
> swp and swpb are only guaranteed to work properly on the
> same CPU they execute on, not all CPUs, for armv7.  they
> reply upon features not required.  eg, see:
>
> https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/SWP--SWPB?lang=en
>
> which says:
>
> The SWP and SWPB instructions rely on the properties of
> the system beyond the processor to ensure that no stores
> from other observers can occur between the load access and
> the store access, and this might not be implemented for
> all regions of memory on some system implementations. In
> all cases, SWP and SWPB do ensure that no stores from the
> processor that executed the SWP or SWPB instruction can
> occur between the load access and the store access of the
> SWP or SWPB.
>
> ie, the quoted text above doesn't mention that the support
> for doing this isn't required.  there ares also bits in
> ID_ISAR0 and ID_ISAR4 to show this.

Ah, thank you for kind explanation. I apparently misread the manual.

Also, as Nick pointed out,

On 2020/11/26 2:36, Nick Hudson wrote:
> armv7 != armv8
>
> or am I missing something here?

SW-bit is absent in SCTLR on ARMv8. Bit 10 is reused for other purpose.
At the moment, we turn on that bit for UP kernel on >= ARMv7, but we
should check

- !MULTIPROCESSOR, and
- not running on ARMv8 or later, and
- SWP bit in ISAR0 is turned off, and
- SWP frac bit in ISAR4 is turned on

before turning on that bit. Anyway, we need software emulation for
swp{,b} also on arm32. I'm now working on it...

Thanks,
rin