# Progress #
* TCWG-332, done. [1/10]
Fix GDB bug on stepping over breakpoint on ARM. Patch is pushed in.
* TCWG-423, patches are posted. [5/10].
Support gnu vector in inferior call in AArch64 GDB.
Also correctly handle HVA (homogeneous vector aggregate) in inferior
call.
* TCWG-433, done. [2/10]
All memory issues found by -fsanitize=address in GDB are fixed.
* TCWG-447, done. [1/10]
Fix GDB mainline build warnings and errors in C++ mode on ARM and
AArch64.
* Discussion on the approach of building GDB in C++. Need to test GDB
built in C++ on both ARM and AArch64, from my side. [1/10]
# Plan #
* Understand ST's jtag probe and help them to make use of multi-arch
in GDB.
* Fix GDB internal error in gdb.thread/watchpoint-fork.exp on AArch64.
* TCWG-156, GDB test parity between AArch64 and X86_64.
--
Yao
== Progress ==
* Validation (6/10)
- a few improvements in the validations using the ST compute farm
- thinking about appropriate ways of sharing validation
reports with the GCC community without flooding gcc-testresults
- moved results comparison scripts to a dedicated repo
and updated Jenkins jobs accordingly
* GCC (1/10)
- bug #1869 / glibc dependency on RHEL6
proof of concept to force use of old memcpy
but it will be much safer to build the toolchain
in a suitable container with the right distro
* Misc (conf calls, meetings, emails, ...) (3/10)
- patches and backports reviews
== Next ==
* Validation
- continue preparation of switch, as dev-01 is now back
- improve reporting
* GCC:
- check Neon tests cleanup
- bug #1869
- look at how to send valuable reports to gcc-regression
Hi,
We're currently running into issues with the OE builds due to OE-core
having moved to 2.22. So what's the plan for glibc-linaro 2.22?
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Hi,
This question has arisen in the ODP project and the thought is that a 'best
practices' answer would be more likely to be found on this list.
We have a component that wants to make use of specialized instructions for
performing CRC and/or AES computations and was wondering what is the
recommended way for an application to determine whether such instructions
are available in the toolchain and whether the user has overruled their use?
Thanks for any insight you can provide.
Bill
I think there are many issues with binary compatibility beyond
function inlining. An ODP application cannot expect all ODP
implementations to support the same number of ODP queues or
classification rules or even which classification terms (fields) are
supported (efficiently/in HW) etc. Is there some kind of lowest common
denominator an application should expect? Do we want to make
guarantees of an ODP implementation stricter? What are the
consequences of such strict functional guarantees?
I think an application that requires binary compatibility over ARMv8.1
platforms should compile and link against a specific ODP SW
implementation (possibly with some well-defined HW offloads where the
underlying platform can provide the relevant drivers). I.e. more of a
(user-space) Linux architecture than standard ODP (as influenced by
OpenGL). The important binary interfaces then becomes the interfaces
to these offloads/drivers.
On 16 November 2015 at 14:23, Nicolas Morey-Chaisemartin
<nmorey(a)kalray.eu> wrote:
>
>
> On 11/11/2015 09:45 AM, Savolainen, Petri (Nokia - FI/Espoo) wrote:
>>
>>> -----Original Message-----
>>> From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of
>>> EXT Nicolas Morey-Chaisemartin
>>> Sent: Tuesday, November 10, 2015 5:13 PM
>>> To: Zoltan Kiss; linaro-toolchain(a)lists.linaro.org
>>> Cc: lng-odp
>>> Subject: Re: [lng-odp] Runtime inlining
>>>
>>> As I said in the call last week, the problem is wider than that.
>>>
>>> ODP specifies a lot of types but not their sizes, a lot of
>>> enums/defines (things like ODP_PKTIO_INVALID) but not their value
>>> either.
>>> For our port a lot of those values were changed for
>>> performance/implementation reason. So I'm not even compatible between
>>> one version of our ODP port and another one.
>>>
>>> The only way I can see to solve this is for ODP to fix the size of all
>>> these types.
>>> Default/Invalid values are not that easy, as a pointer would have a
>>> completely different behaviour from structs/bitfields
>>>
>>> Nicolas
>>>
>> Type sizes do not need to be fixed in general, but only when an application is build for binary compatibility (the use case we are talking here). Binary compatibility and thus the fixed type sizes are defined per ISA.
>>
>> We can e.g. define a configure target (for our reference implementation == linux-generic) "--binary-compatible=armv8.x" or "--binary-compatible=x86_64". When you build your application with that option, "platform dependent" types and constants would be fixed to pre-defined values specified in (new) ODP API arch files.
>>
>> So instead of building against odp/platform/linux-generic/include/odp/plat/queue_types.h ...
>>
>> typedef ODP_HANDLE_T(odp_queue_t);
>> #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, 0)
>> #define ODP_QUEUE_NAME_LEN 32
>>
>>
>> ... you'd build against odp/arch/armv8.x/include/odp/queue_types.h ...
>>
>> typedef uintptr_t odp_queue_t;
>> #define ODP_QUEUE_INVALID ((uintptr_t)0)
>> #define ODP_QUEUE_NAME_LEN 64
>>
>>
>> ... or odp/arch/x86_64/include/odp/queue_types.h
>>
>> typedef uint64_t odp_queue_t;
>> #define ODP_QUEUE_INVALID ((uint64_t)0xffffffffffffffff)
>> #define ODP_QUEUE_NAME_LEN 32
>>
>>
>> For highest performance on a fixed target platform, you'd still build against the platform directly
>>
>> odp/platform/<soc_vendor_xyz>/include/odp/plat/queue_types.h
>>
>> typedef xyz_queue_desc_t * odp_queue_t;
>> #define ODP_QUEUE_INVALID ((xyz_queue_desc_t *)0xdeadbeef)
>> #define ODP_QUEUE_NAME_LEN 20
>>
>>
>> -Petri
>>
>
> It still means that you need to enforce a type for all ODP implementation on a given arch. Which could be problematic.
> As a precise example: the way handles are used now for odp_packet_t brings some useful features for checks and memory savings, but performance wise, they are a "disaster". One of the first thing I did was to switch them to pointers. And if I wanted a high perf linux x86_64 implementation, I'd probably do the same.
>
> Nicolas
> _______________________________________________
> lng-odp mailing list
> lng-odp(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
== Progress ==
LLDB development
-- Root Google Nexus devices and read debug module configuration with
kernel module [TCWG-429] [7/10]
-- Figure out steps to unlock and root Nexus S
-- Figure out steps to build kernel and kernel module for Nexus S
-- Tried out lldb watchpoints with custom kernel on Nexus S
-- Tried out reaching debug co processors without ptrace using kernel module.
-- Identify mix-mode debugging problems (ARM & Thumb) [TCWG-229] [2/10]
-- Ongoing Initial investigation and indentifying code areas needing changes
Miscellaneous [1/10]
-- Meetings, emails, discussions etc.
== Plan ==
-- Root Google Nexus devices and read debug module configuration with
kernel module [TCWG-429]
-- Complete app and kernel module to read debug coprocessor registers.
-- Try them out on remaining Android devices.
-- Identify mix-mode debugging problems (ARM & Thumb) [TCWG-229]
-- Further investigation and testing a mix mode application.
== Progress ==
* Buildbots (4/10)
- Found culprit for self-hosting breakages
- Bot didn't get right because of dirty builds
- Moving all self-hosting bots to clean builds (~3h)
- More work on MIPS patch breaking self-hosting
- Several breakages and bisections
- Adding first cloud (Scaleway) buildbot to local master
- No NEON, so we can't replace the Chromebooks
* Infrastructure (4/10)
- Power cut in Cambridge Lab, no generator yet
- Chromebooks fail at the time of the cut, even with the UPS
batteries still holding. I'm guessing the power regulator
depends on the internal battery to work (and we removed them)
- Bringing all bots up, etc.
- Setting up an HiKey/AMD for benchmarks (APMs are too different)
- Running EEMBC and SPEC on AMD
* Background (2/10)
- Code review, meetings, discussions, general support, etc.
- Upstreaming -meabi, which may fix builds of kernel, android, bsd
- Compiling aarch64-linux-gnu-gcc by hand because Arch pkg didn't work
o 1 day off (2/10)
== Progress ==
o Linaro GCC (6/10)
* FSF branch merge into linaro GCC 5 branch
* Troubleshot various regression after the merge
* Delivered GCC 5.2 2015.11 snapshot
o Upstream work (1/10)
* Sanitizing gfortran testsuite
o Misc (1/10)
* Various meetings
== Plan ==
o Continue on sanitizing testsuite
o Backports, infra, ...
Implement LAVA jobs for microinstance - TCWG-432 [6/10]
* Refactoring to permit sharing of code between uinstance & main
instance, as far as possible
* Further refactoring for sane submission of bundles without inserting
LAVA assumptions in the wrong places
* Tested as far as possible in main instance, using light hacks and fakebench
Jenkins benchmarking job - TCWG-348 [1/10]
* Converted pbl hacks into a sane patch for yaml-to-json.py
Controlled image builds - TCWG-360 [1/10]
* Submitted aarch64 filesystem build for review
* Generated armhf and amd64 filesystems
* Started learning how to generate hwpack
Misc [2/10]
=Plan=
Review security with shared uinstance/main instance code
Expose more data, benchmarks to bundles
Create YAML definition for Jenkins benchmarking job
Generate (controlled) hwpack for at least one target, or know what the
problems are
Write up noise control report (if time)
Have another at crashdump (if time, if new kexec patches)
* TCWG-72 (3/10)
- divmod transform approved by Richard
- builds cleanly on arm-linux-gnueabihf, aarch64-linux-gnu
- Investigating segfault with __bdi64_div.c
happens when mode == DImode and libval_mode == TImode
- Found another segfault on x86 with TImode, on arm
TImode is not supported and compiler aborts. Perhaps we should
not do the transform when mode is TImode ?
- Had a look at expand_binop_twoval_libfunc().
Wrote a similar function to obtain both results but this resulted
in infinite loop in emit_libcall_block_1
- Strangely the bug is reproducible only during the build and doesn't
trigger when compiled with preprocessed version of bid64_div.c
(passing the same set of options).
- waiting for upstream comments
* TCWG-319 (1/10)
- Submitted jobs for fp benchmark on a53, a57
* Misc:
- PR66214 appears to have gone (fixed or became latent), that was
blocking firefox LTO build with trunk
- PR65837 still appears to be present after r230327
* Public Holidays (6/10)
- Diwali festival
== Next Week ==
- Continue with TCWG-72, TCWG-319 benchmarking, target hook conversion
- Run SPEC2k6 with LTO
