What I need to confirm is if the Linaro 5.3 would generate such code from a normal block of C without any kind of asm in it? Detecting the code is part of the kernel...I need to figure out where it was generated. Is Linaro 5.3 going to generate such code without explicitly writing it in?
----- Original Message -----From: Andrew Pinski <Andrew.Pinski(a)cavium.com>To: stimits(a)comcast.net, Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>Sent: Mon, 05 Sep 2016 17:21:24 -0000 (UTC)Subject: RE: Question on "Using deprecated CP15 barrier instruction".
Simple answer is yes. There are a lot of assembly out there and someone (seen it in the past) could have used this barrier method in their code and not really thought it was going to change in the future.
Thanks,
Andrew
From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org]On Behalf Of stimits(a)comcast.netSent: Monday, September 5, 2016 8:10 AMTo: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>Subject: Question on "Using deprecated CP15 barrier instruction".
Hi,
For reference, the following questions refer to a Linux 3.10 aarch64 kernel (ARMv8, ARMv8-A) compiled with Linaro5.3-2016.02 (5.3-2016.02 arm64 CROSS_COMPILE and 5.3-2016.02 armhf CROSS32CC cross compiled from x86_64). This Linux kernel compile requires the full 64-bit tool chain plus the 32-bit gcc.
There is a Linux kernel file "arch/arm64/kernel/deprecated.c". Within that file is a block of code which is apparently designed to detect some sort of older obsolete 32-bit code. Specifically, the warning message is "Using deprecated CP15 barrier instruction". I wouldn't think that this kernel, when compiled with such a recent compiler, would ever introduce CP15 barrier code (from what I see barrier code was deprecated in ARMv7 and used to deal with obsolete ARMv6 code). Is there any chance the 32-bit 5.3 gcc would still generate CP15 barrier code?
Although this kernel and "most" modules are built with Linaro 5.3 I'd like to be able to narrow the cause down to existing binary modules not compiled with the 5.3 Linaro. If I can guarantee 5.3 32-bit gcc does not produce the CP15 barrier instruction then I'll know it is in pre-built binary modules. Can anyone tell me if C code compiled from Linaro version 5.3 32-bit gcc code would ever contain CP15 instructions?
Thanks!
== Progress ==
o Linaro GCC/Validation (7/10)
- Merged bkk16 buildfarm developments into main job.
- Backports: Reviews, dependencies tracking and backports.
- Analysed extended validation results.
o Misc (3/10)
* Various meetings and discussions.
== Plan ==
o Release 2016.09 Snapshots
o GNU Cauldron
== Progress ==
- IPA-VRP: Re-based ipa-cp/ipa-prop on top of Prathameshes commit
(quite a few conflicts) and did full testing before posting to the
list. Patch approved for commit.
- Waiting for Early-VRP patch to commit rest of the patches in the series
- All other patches are OK now.
- Looking at tree-vrp in details. Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77387
- Looking at re-assoc wrong code generation issue (PR72835). Posted
another attempt to fix for review
= Next ==
- Work on tree-vrp improvements
- Follow up on pending patches
== This Week ==
* TCWG-779 (4/10)
- Upstream patch iterations
* NULL pointer propagation in ipa-bitwise-cp (4/10)
- WIP patch
* Benchmarking (1/10)
- Found how to set iterations for coremark
- Submitted job for setting up hack session on Juno
* Misc (1/10)
- Meetings
== Next Week ==
- NULL pointer propagation
- TCWG-779
- GNU Cauldron
* Holiday on Monday. [2/10]
# Progress #
* TCWG-685, GDB 7.12 release. No new issue. [1/10]
* TCWG-655, ARM linux kernel ptrace bug. [3/10]
Teach GDB testsuite to detect such kernel bug, and skip all tests
related to floating point. Patches are committed.
On the other hand, upgrade my arm kernel to 4.7.2, on which the ptrace
bug is fixed.
* TCWG-518, range stepping on ARM. [2/10].
Turned it on, but it causes some threads starvation. Investigating.
* Finish the reproducer to show odd behaviour of armv8 kernel in si_code
after PTRACE_SINGLESTEP and Will Deacon fixed it
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/453289…
[1/10]
* Think about the GDB plan, and write down a list of things I need to
do. [1/10]
# Plan #
* TCWG-685, TCWG-518.
* GNU Cauldron.
--
Yao Qi
== Activity ==
[TCWG-610] Sent .ARM.exidx for upstream review.
Will need to rework and simplify bit to make more specific to ARM. In
summary abandon pretence of SHF_LINK_ORDER in general and concentrate
on supporting its one known use case in .ARM.exidx sections.
Made a couple of drafts of forthcoming LLVM Cauldron presentation
- Presented locally
- Modified slides after overrunning time
== Plans ==
[TCGWG-610] Rework and resend for review
llvm-cauldron on Thursday
Intending to take Friday as holiday to take advantage of visiting
parents whilst up North.
