[ACTIVITY] 6 - 10 June 2016
== This Week == * LTO (5/10) a) committed r237207 to fix unresolved test-cases added in r236503 (1/10) b) move increase_alignment pass to regular pass (3/10) - Patch iterations based on suggestions from Honza and Richard - Understanding lto streaming and decl merging code c) TCWG-548 (1/10) - WIP patch * TCWG-319 (1/10) - updated patch submitted upstream: - changing vect_hw_misalign causes regression for vect-align-1.c * Benchmarking (1/10) - Benchmark successfully ran for linaro-gcc-5 submitted by Yvan - Benchmark for fsf-gcc-6 failed both with prebuilt route and letting job build the benchmark * Misc (3/10) - Meetings - Travel to Mumbai for Schengen Visa appointment == Next Week == - Try to get patch committed for increase_alignment - TCWG-319: Look at vect-align-1.c regression - TCWG-548: Complete implementation and validate patch. - ipa-vrp: Experiment with Kugan's patch. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] Week 23
== Progress == o Extended Validation (4/10) - Investigate and reported Glibc/libsanitizer issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 - Looked at benchmark job issues - Discuss benchmark/lava notification mechanism o Linaro GCC (1/10) - Merged FSF GCC 5.4 branch o Upstream GCC (3/10) - ARMv8.1 libatomic investigation: seems to work fine when enabling multilib on AArch64 need to investigate completeness of the support. o Misc (2/10) * Various meetings and discussions. * Backlfip patch reviews == Plan == o Backport reviews and June snapshots o Continue libatomic o Benchmarking job fixes. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 6 - 10 June 2016
* One day off on Thu [2/10] # Progress # * TCWG-639, non-8-byte-aligned watchpoint is missed on aarch64. [4/10]. It is caused by limited kernel BAS support. RedHat reports this problem and posts a patch. Good to see they start to contribute to aarch64 GDB, but I don't like the patch. Spend much time writing a prototype to prove their patch is not perfect. We agree to fix this problem by extend RSP fortunately. * TCWG-333, [3/10] I follow the way how mips does, and fix some bugs. * TCWG-547, TCWG-518, blocked in upstream review. * Misc, meetings. [1/10] # Plan # * TCWG-333, TCWG-556. * Ping TCWG-547, TCWG-518. -- Yao ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 30 May - 03 June 2016
=== This Week === Investigation of Nexus devices kernel issues.[TCWG-622] [6/10] -- Figured out source trees for various android devices and checked out kernel code. -- Comparison between watchpoint implementation of different kerenel sources supported by Nexus devices. -- Figured a way to burn a custom rom with updated kernel on Nexus 7. -- Figured Kconfig issue that was causing watchpoints not to be detected on Nexus 7. -- Watchpoint installation still doesnt work on Nexus 7. LLDB buildbot updates and maintenance [TCWG-241] [2/10] -- Upgraded cmake version after migration to new version. -- Migrating local buildbot setup (builders and testers) to ubuntu xenial 16.04 -- Buildbot restart after power outage. Miscellaneous [2/10] -- Meetings, emails, discussions etc. -- Out of office on Tuesday 31st 2016 for visa documents preparation. === Next Week === Support for watchpoint un-alligned watchpoint addresses on LLDB AArch64 [TCWG-367] -- Continue work on hardware watchpoint support. Investigation of Nexus devices kernel issues.[TCWG-622] -- Figured out steps to build custom kernel for Neuxs7. LLDB hardware watchpoint capability test and skip watchpoint testing [TCWG-622] -- Investigate possible ways to solve this issue. Miscellaneous -- Out of office on Thursday 9th June for visa interview. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 06 - 10 June 2016
=== This Week === Support for watchpoint un-alligned watchpoint addresses on LLDB AArch64 [TCWG-367] [3/10] -- Implementation successful without the need for instruction emulation. -- Watchpoint hit detection fixed with ptrace reporting hit address correctly. -- Used up watchpoint HitAddress function to return back the real address to host. Investigation of Nexus devices kernel issues.[TCWG-622] [2/10] -- Figured out steps to build custom kernel for Neuxs7. -- Kernel fails to boot though. LLDB hardware watchpoint capability test and skip watchpoint testing [TCWG-622] [2/10] -- Submitted a patch to report back correct reason for watchpoint creation failure. Miscellaneous [3/10] -- Meetings, emails, discussions etc. -- A look into LLDB xfail decorators to fail on the basis of arm ABI. -- Out of office on Thursday 9th June for visa interview. === Next Week === Support for watchpoint un-alligned watchpoint addresses on LLDB AArch64 [TCWG-367] -- Finish up work, test and submit for review upstream. LLDB hardware watchpoint capability test and skip watchpoint testing [TCWG-622] -- Patch review and further progress. Miscellaneous -- Testsuite Makefile.rulez update still pending, hopefully will be done this week. -- Xfail decorator updates to xfail based on ARM ABI. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
[TCWG] Split-stack for aarch64
Hi all,
First sorry for the long message, but I am kinda stuck on an issue
with my split-stack work for aarch64, so any new eyes to check if
I am doing things properly would be really helpful.
I pushed my current work on a local gcc git [1] and glibc [2] branches.
The current code show not issue with the placed C tests, but there
is one elusive GO tests that fails for some reason.
The glibc patch is pretty simple: it adds a tcbhead_t field
(__private_ss) which will be used to hold the split stack thread
value. Different from stack protector, split-stack requires
a pointer per thread and it is used frequently on *every* function
prologue. So faster access is through TCB direct access (one
instruction less than TLS initial-exec). I plan to digress a little
more about why I decided to use TCB access, but in a short the advantages
are:
1. It is faster than TLS initial-exec
2. Does not require any static or dynamic relocation
The rest of patch is just to add a versioned symbol so either static
or dynamic linking fails for an older glibc (to prevent split-stack
binaries to run on non-supported glibcs).
The GCC patch is more complex, but it follows the already implemented
split-stack support on other architectures (x86, powerpc64, s390).
Basically you add hooks to generate the required prologue and other
bits (C varargs requires some work) and add some runtime support on
libgcc (morestack.S).
Split-stack idea is basically as this: let say you have a function
that requires a very large stack allocation that might fail at
runtime (due ulimit -s limit). Split-stack add some instrumentation
that check if the stack allocation will fail based on initial
value and allocates stack segments as required.
So basically a function would be instrumented as:
function foo
ss := TCB::__private_ss
if SP + stack_allocation_size > ss
call __morestack
// function code
What __morestack basically does is create a new stack segment with
some slack (using a platform neutral code), change the stack pointer
and continue run the function. So a stack frame for a function
that called __morestack is as:
foo
\_ __morestack
\_ // function code
And when the function code finished its execution (including all
possible function calls), it returns to __morestack so it restore
the old stack pointer and arguments.
Now, this is the most straightforward usage of __morestack. However
GO language allows a construct [3] that allows a function to register
a callback that is called at end of its scope that allows to 'recover'
from some runtime execution failure.
And this is the remaining GO tests that fails [4]. What it basically
does is run a set of tests that allocate some different structure and
try to access it in different invalid way to check if accessing a
know null pointer is caught by the runtime (GO adds null pointer checks
for some constructs).
9 func main() {
10 ok := true
11 for _, tt := range tests {
12 func() {
13 defer func() {
14 if err := recover(); err == nil {
15 println(tt.name, "did not panic")
16 ok = false
17 }
18 }()
19 tt.fn()
20 }()
21 }
22 if !ok {
23 println("BUG")
24 }
25 }
41 var tests = []struct{
42 name string
43 fn func()
44 }{
76 {"*bigstructp", func() { use(*bigstructp) }},
108 type BigStruct struct {
109 i int
110 j float64
111 k string
112 x [128<<20]byte
113 l []byte
114 }
So basically here it tries to allocate a very big structure (BigStruct with
about 128 MBs) on stack and since it does not have stack allocation it will
need to call __morestack.
Now, if have patient to read until now, the way GCCGO does that is by
throwing an exception to unwind the stack and to add some CFI directives in
both generated code and morestack to correct handling the unwinding.
So if GCC generates the unwind information for the objects and if __morestack
have the correct unwind information it should, so I presume my patch is
failing in either define the correct exception handler directives in
morestack.S or I am failing in generate the correct __morestack call.
The __morestack call is done at 'aarch64_expand_split_stack_prologue' in
my patch as:
--
+ /* Call __morestack with a non-standard call procedure: x10 will hold
+ the requested stack pointer and x11 the required stack size to be
+ copied. */
+ args_size = crtl->args.size >= 0 ? crtl->args.size : 0;
+ reg11 = gen_rtx_REG (DImode, R11_REGNUM);
+ emit_move_insn (reg11, GEN_INT (args_size));
+ use_reg (&call_fusage, reg11);
+
+ /* Set up a minimum frame pointer to call __morestack. The SP is not
+ save on x29 prior so in _
