[ACTIVITY] 28 September-2 October 2015

[Christophe Lyon]

== Progress ==
2 days off (4/10)

* Infrastructure/validation: (3/10)
further checking of cross-testing results stability on aarch64-linux
- found a workaround for a timestamp problem (_Pragma3 testcase)
- looked at c11-atomic-exec-5 whose execution time ranges between 1s
and 1h :-)
- forcing make check to -j8 seems to work well, will work on a nicer
improvement

* reported and briefly looked at failure in a new libstdc++ test
(directory_iterator) on armv5t

* Misc (conf calls, meetings, emails, ....) (2/10)

* Internal (1/10)
- GNU linker patch review

[Pinski, Andrew]

Post by Christophe Lyon
== Progress ==
2 days off (4/10)
* Infrastructure/validation: (3/10)
further checking of cross-testing results stability on aarch64-linux
- found a workaround for a timestamp problem (_Pragma3 testcase)

contrib/gcc_update --touch is the best way to fix the above issue.

Post by Christophe Lyon
- looked at c11-atomic-exec-5 whose execution time ranges between 1s
and 1h :-)

I even seeing that on thunderx.

Post by Christophe Lyon
- forcing make check to -j8 seems to work well, will work on a nicer
improvement
* reported and briefly looked at failure in a new libstdc++ test
(directory_iterator) on armv5t
* Misc (conf calls, meetings, emails, ....) (2/10)
* Internal (1/10)
- GNU linker patch review
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Christophe Lyon]

On 2 October 2015 at 18:04, Pinski, Andrew

Post by Pinski, Andrew

Post by Christophe Lyon
== Progress ==
2 days off (4/10)
* Infrastructure/validation: (3/10)
further checking of cross-testing results stability on aarch64-linux
- found a workaround for a timestamp problem (_Pragma3 testcase)

contrib/gcc_update --touch is the best way to fix the above issue.

Yes, that's what I added to abe.

Post by Pinski, Andrew

Post by Christophe Lyon
- looked at c11-atomic-exec-5 whose execution time ranges between 1s
and 1h :-)

I even seeing that on thunderx.

Thanks for the confirmation, I saw your comment on bugzilla.

I understood you thought it was a HW problem with your platform.
Since we see it on different HW, it could mean there is an implementation
problem in libatomic?

Post by Pinski, Andrew

Post by Christophe Lyon
- forcing make check to -j8 seems to work well, will work on a nicer
improvement
* reported and briefly looked at failure in a new libstdc++ test
(directory_iterator) on armv5t
* Misc (conf calls, meetings, emails, ....) (2/10)
* Internal (1/10)
- GNU linker patch review
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Yao Qi]

# Progress #

* TCWG-373, Aarch64 non-stop debugging (or displaced stepping). [2/10]
Patches V1 are ready for upstream submission, but find opcodes has
already interfaces to decode instructions, so decide to use opcodes
for aarch64 GDB first.
* TCWG-387, one patch exposing one opcode interface is pushed in. [4/10]
Switch software single step code for aarch64 to using opcodes
interface. Patch is pushed in.
Rewriting prologue analyser to use opcode interface too.
* TCWG-159, Kernel awareness in GDB. [1/10]
Resume the work as Peter Griffin has cycles to do so. We are happy
with the plan so far.

* Review arm software breakpoint in GDBserver patches. [1/10]

* Misc, [2/10]

# Plan #

* TCWG-387, TCWG-373