Hi Everyone,
I have a test script from help that repeatedly builds and runs a
library under different configurations. The script includes multiple
Asan tests.
The Asan tests are producing some findings under ARM32 as shown below.
Other platforms do not include Asan findings. In addition, Valgrind
does nt produce any findings.
The test program is always built with at least -g2, and sometimes
built with -g3. However, I am not seeing the symbolication. According
to the GCC folks, asan_symbolize is not required for GCC because it
uses libbacktrace. Also see
http://bugzilla.redhat.com/show_bug.cgi?id=1250844.
Why am I lacking symbolization, and how do I achieve it?
**********
AddressSanitizer: stack-buffer-overflow on address 0xbec57b18 at pc
0x38c651 bp 0xbec579e0 sp 0xbec579e4
AddressSanitizer: stack-buffer-overflow on address 0xbedbae9c at pc
0x6553f bp 0xbedbae68 sp 0xbedbae6c
AddressSanitizer: stack-buffer-overflow on address 0xbea67b18 at pc
0x38cbc5 bp 0xbea679e0 sp 0xbea679e4
AddressSanitizer: stack-buffer-overflow on address 0xbef0fe9c at pc
0x66117 bp 0xbef0fe68 sp 0xbef0fe6c
**********
$ uname -a
Linux cubietruck 3.4.39 #35 SMP PREEMPT Tue Sep 15 17:17:33 CST 2015
armv7l armv7l armv7l GNU/Linux
$ g++ --version
g++ (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
# Progress #
* TCWG-655, Workaround ARM linux kernel ptrace bug on setting VFP
registers. [2/10]
Think about different approaches to workaround the kernel bug, but
can't work unfortunately. Propose an approach that workaround it in
gdb testing by setting affinity if the kernel is known broken.
People agree on this.
* TCWG-333, Thumb mode function pointer assignment in GDB. [3/10]
It is broken when you assign a function to a function pointer in
thumb mode in GDB. My original attempt is to skip the test, because
it is difficult to do what MIPS does nowadays. After some
discussions, I realize it is a GDB bug, and we should fix it.
Fortunately it is broken on ppc64 as well because of function
descriptor :)
* TCWG-518, ARM range stepping patches. [2/10]
V3 are reviewed, but I misunderstood one comments to V2. I'll update
patches, retest and post them.
* ARM linux kernel raises SIGILL for unknown syscall number, while GDB
expects kernel returns -ENOSYS. [2/10]
The behaviour is different from other arch. The patch in GDB side is
committed, but still need to kernel people why ARM kernel behaves
this way.
* Misc [1/10]
# Plan #
* All above,
* Off on Thur and Fri.
--
Yao
o One day off (2/10)
== Progress ==
o Extended Validation (3/10)
- Benchmarking job babysitting.
- Looked at Dejagnu issue (pid killing, resurrected an old patch)
o Upstream GCC (3/10)
- __sync bultin fix for ARMv8.1:
Careful read of the doc shows that there is no issue with the
current implementation (no need to add an extra DMB, acq/rel
semantic is sufficient in this case)
- AArch64 and ARM backend cleanup w/r to reload remaining hooks
Analysis and validation on-going
o Misc (2/10)
* Various meetings and discussions.
== Plan ==
o Continue on-going tasks
== This Week ==
* LTO (6/10)
a) TCWG-548 (2/10)
- Tweaked algorithm, which shows some improvements in reducing external
references
b) TCWG-666 (4/10)
- Had a look at bitwise-ccp
- WIP prototype patch
* Benchmarking (1/10)
- Got results for linaro-gcc-6 for coremark-pro for arm-linux-gnueabihf
* Sick Leave (2/10)
* Misc (1/10)
- Pinged for reviewing patches for TCWG-665 and TCWG-72
- Meetings
== Next Week ==
- Address upstream reviews for TCWG-665
- TCWG-666: Continue with prototype patch.
- TCWG-548: Submit upstream for feedback.
- Benchmarking: Get results for coremark-pro for aarch64-linux-gnu.
== Progress ==
TCWG-653 ARM/Thumb interworking veneers
Have completed an implementation, now in upstream review. Had initial
set of comments and posted an update. Likely to take several
iterations before commit
TCWG-612 ARM TLS support in LLD
Made a start. Looks to be more straightforward the interworking
thunks, should just be grunt-work to get done.
Updated lld slides on llvm sprint presentation.
== Plan ==
TCWG-653 and TCWG-612.
== Progress ==
* ARM: Do not test for CPUs, use SubtargetFeatures [TCWG-623] [4/10]
- Committed another patch upstream, 3 more in review
* ARM: Different ABI functions based on optimization level [TCWG-669] [3/10]
- Make sure we're ABI-compliant at -O0
- Patch in upstream review, need to fix a few things
* List of active environments with llvm-env [TCWG-640] [1/10]
- Committed internally
* Refactor SelectionDAGBuilder::visitInlineAsm [TCWG-643] [1/10]
- In progress (trying to break it up into a few helper functions)
* PR26038 - inline assembly assertion building ARM linux kernel
[TCWG-590] [1/10]
- Started investigating
== Plan ==
* Address any review comments for TCWG-623 and TCWG-669
* Submit patches for TCWG-643 and TCWG-590
Hi Andrew,
On 27 June 2016 at 19:32, Pinski, Andrew <Andrew.Pinski(a)cavium.com> wrote:
>> No gain expected in implementing an Ifunc'ed version of the library.
>
> How did you prove that? What hardware did you run this on to prove it?
> Also have you thought at least doing an ifunc version for 128bit atomics?
up to 64bits, the calls to the libatomic routines are inlined and
armv8.1 CAS and load-operate version are used when the application is
build for armv8.1 architecture. For 128bits, a call to the lib is
made which uses the same LL/SC implementation with or without LSE
support, as CAS and load-operate instruction don't support this data
size.
I don't have armv8.1 hardware and made the analysis on the generated
assembler. Do you have use case on your side where an ifunc version
can be useful ? I'm not aware of an algorithm which can replace
effectively LL/SC implementation with shorter CAS, do you have any
pointers ? Maybe CASP can be used in some cases, I'll investigate it.
Thanks
Yvan
> Thanks,
> Andrew
>
> -----Original Message-----
> From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Yvan Roux
> Sent: Monday, June 27, 2016 1:40 AM
> To: Linaro Toolchain Mailman List <linaro-toolchain(a)lists.linaro.org>
> Subject: [ACTIVITY] Week 25
>
> == Progress ==
> o Extended Validation (1/10)
> - Benchmarking job babysitting.
>
> o Upstream GCC (4/10)
> - ARMv8.1 libatomic: Analysis completed.
> No gain expected in implementing an Ifunc'ed version of the library.
> - Working on __sync buitlins potential fix.
>
> o Misc (5/10)
> * Various meetings and discussions.
> * Internal appraisal
>
> == Plan ==
> o Continue on-going tasks (__sync, benchmarking) _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
== Progress ==
o Extended Validation (1/10)
- Benchmarking job babysitting.
o Upstream GCC (4/10)
- ARMv8.1 libatomic: Analysis completed.
No gain expected in implementing an Ifunc'ed version of the library.
- Working on __sync buitlins potential fix.
o Misc (5/10)
* Various meetings and discussions.
* Internal appraisal
== Plan ==
o Continue on-going tasks (__sync, benchmarking)
# Progress #
* TCWG-333, ISA bit treatment in ARM thumb mode.
Got some comments from Maciej (MIPS) and need to address them.
* TCWG-518, ARM range stepping patches. [2/10]
Combine the path of "proceed" and "resume" so that we only change one
place instead of two to support range stepping. Patches are being
tested.
* TCWG-655, Workaround ARM linux kernel ptrace bug... [2/10]
by pining both program and debugger on the same core in the affected
test cases.
* Off on Wed to Fri. [6/10]
# Plan #
* Continue things above,
--
Yao
