- linaro-toolchain - lists.linaro.org

Linaro GDB 7.2 2010.11-0 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.2. Linaro GDB 7.2 2010.11-0 is the second release in the 7.2 series. Based off the latest GDB 7.2, it includes a number of ARM-focused bug fixes and enhancements. This release concentrates on the GDB test suite and tidies up a number of failures. The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.2-2010.11-0 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Michael

15 years, 5 months

1
0
0 0

Auto-detection of vector size for NEON

by Ira Rosen

Hi, It looks like it's enough to implement targetm.vectorize. autovectorize_vector_sizes for NEON in order to enable initial auto-detection of vector size. With the attached patch and -mvectorize-with-neon-quad flag, the vectorizer first tries to vectorize for 128 bit, and if this fails, it tries to vectorize for 64 bit. For example, in the attached testcase number of iterations is too small for 128 bit (first 2 iterations have to be peeled in order to align the array accesses), but is sufficient for 64 bit (the accesses are aligned here). I'd appreciate your comments on the patch, and I also have a few questions: 1. Why the default vector size is 64? 2. Where is the place of NEON vectorization tests? I found NEON tests with intrinsics at gcc.target/arm, is that the right place? 3. According to gcc.dg/vect/vect.exp the only flag that is used for NEON (in addition to target independent flags) is -ffast-math. Is that enough? Thanks, Ira ChangeLog: * config/arm/arm.c (arm_autovectorize_vector_sizes): New function. (TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES): Define. Index: config/arm/arm.c =================================================================== --- config/arm/arm.c (revision 166032) +++ config/arm/arm.c (working copy) @@ -246,6 +246,7 @@ static bool arm_builtin_support_vector_misalignmen const_tree type, int misalignment, bool is_packed); +static unsigned int arm_autovectorize_vector_sizes (void); /* Table of machine attributes. */ @@ -391,6 +392,9 @@ static const struct default_options arm_option_opt #define TARGET_VECTOR_MODE_SUPPORTED_P arm_vector_mode_supported_p #undef TARGET_VECTORIZE_PREFERRED_SIMD_MODE #define TARGET_VECTORIZE_PREFERRED_SIMD_MODE arm_preferred_simd_mode +#undef TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES +#define TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES \ + arm_autovectorize_vector_sizes #undef TARGET_MACHINE_DEPENDENT_REORG #define TARGET_MACHINE_DEPENDENT_REORG arm_reorg @@ -23223,6 +23227,12 @@ arm_expand_sync (enum machine_mode mode, } } +static unsigned int +arm_autovectorize_vector_sizes (void) +{ + return TARGET_NEON_VECTORIZE_QUAD ? 16 | 8 : 0; +} + static bool arm_vector_alignment_reachable (const_tree type, bool is_packed) { test: #define N 5 unsigned int ub[N+2] = {1,1,6,39,12,18,14}; unsigned int uc[N+2] = {2,3,4,11,6,7,1}; void main1 () { int i; unsigned int udiff = 2; unsigned int umax = 10; for (i = 0; i < N; i++) { /* Summation. */ udiff += (ub[i+2] - uc[i]); /* Maximum. */ umax = umax < uc[i+2] ? uc[i+2] : umax; } }

15 years, 5 months

3
5
0 0

Weekly meeting at 0900 UTC today

by Michael Hope

Hi there. Just a reminder that today's call is the first at the new time of 0900 UTC which is 9am in the UK, 10am in Germany, 11am in Israel, and 5pm in China. I've updated the meetings page at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings with the new details. -- Michael

15 years, 5 months

1
0
0 0

Help on merging two patches

by Yao Qi

Hi, I am backporint some patches from FSF mainline, which may improve Linaro 4.5 gcc on thumb2 speed. The first one is done by Richard E. "Improve optimization to transform TST into LSLS" http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02518.html After it applied to Linaro 4.5 tree, EEMBC speed number downgrades, while code size is reduced to some extent. The code difference is like this, 6801 ldr r1, [r0, #0] f831 3013 ldrh.w r3, [r1, r3, lsl #1] -f413 6f00 tst.w r3, #2048 ; 0x800 -f43f af41 beq.w cc <t_run_test+0xcc> +0518 lsls r0, r3, #20 +f57f af44 bpl.w cc <t_run_test+0xcc> 4610 mov r0, r2 After reading cortex-a8 TRM, I can't find exact timing cycles of lsls. Under Chung-Lin's help, we feel that lsls should be slower than tst, but don't have any evidence to prove. If any people is familiar with arm microarch, help is welcome. If our assumption is correct, we may can change this patch to an optimization specific to size only. The second patch is Bernd's "Fix an if statement in arm_rtx_costs_1" http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02096.html After this patch applied, EEMBC benchmark number is not changed. Shall we merge this patch to linaro 4.5 tree? I am inclined to merge it, but if you have concerns on this patch, let us discuss here. -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 5 months

3
4
0 0

Problems with BeagleBoard installation

by Ira Rosen

Hi, I am trying to install my new BeagleBoard xM. I started with https://wiki.linaro.org/Releases/DailyBuilds, but it failed to write to the SD card giving some errors about QEMU (I can try that again if the error messages are important). Dave Martin also gave me this link https://wiki.linaro.org/Source/ImageInstallation, but it doesn't exist anymore. So, I tried these instructions: https://wiki.linaro.org/Source/VexpressImageInstallation with http://snapshots.linaro.org/10.11-daily/linaro-headless/20101107/0/images/t… http://jameswestby.net:8080/view/Hardware%20Packs/job/linaro-omap3%20hwpack… --dev beagle). The installation of the SD card went ok, but the board doesn't work. During boot I see the printings as in the attached file and it doesn't go any further. I hope someone can help me with that, because otherwise I am at dead end... Thanks, Ira

15 years, 5 months

1
0
0 0

Changing meetings

by Michael Hope

Hi there. I plan to change the Toolchain WG meetings due to daylight savings and to better cover the US. The Monday meeting will be at 0900 UTC which is 9 am in the UK, 10 am in central Europe, and 5 pm in Beijing. The standup calls will be merged into one at 1800 UTC on Wednesday which is 6 pm in the UK, 7 pm in central Europe, and 1 pm on the US East Coast. I don't expect China to call in as it's a quite unreasonable time. I'll update the invites and wiki page to reflect this. We'll start the new times next week, so Monday the 8th will be the first meeting at the new time. -- Michael

15 years, 6 months

3
2
0 0

Links

by Michael Hope

This is more for the people in the sprint... http://ex.seabright.co.nz/helpers/blueprints#toolchain http://ex.seabright.co.nz/helpers/planner -- Michael

15 years, 6 months

1
0
0 0

Report of thumb2 tuning investigation

by Yao Qi

The gaol and plan of investigation has been described in [1] In the plan, this task is divided into three parts, 1) patch backport, 2) regression fix, and 3) exploration and study other ARM compilers. This report follow the same manner. 1. Patch backport. 8 patches are listed in [1]. Backport them to Linaro 4.5 tree will improve speed performance. Action/Recommendation: Backport them if speed improves. These patches are ones that I think they *should* improve speed, but "performance surprise" is not impossible. 2. Regression fix. So far (until r99399), Linaro GCC 4.5 is slower than FSF GCC 4.5.0 on some EEMBC benchmarks. Performance regression is introduced by four commits, r99324,r99330,r99369,r99380, see details in [2]. Action/Recommendation: Figure out why speed regression is introduced, and try to fix it. One cent here is that how to avoid speed regression. I do believe that sometimes regression is unavoidable, but it is better if can track them, and keep them manageable. 3. Exploration and study other ARM compilers. In this part, I don't find any possible thumb-2 specific improvements. However, loop optimization and instruction scheduling should be improved on ARM. (This statement may be true to all ports, or even all compilers) Some tickets are opened for this part, LP:660644 Missed optimization opportunities LP:662692 Inner loop in autcor00 can be optimized better LP:656957 LP:645267 Improve code generation on switch statement LP:663793 Tune Swing Modulo Scheduling or Selective Scheduling for ARM LP:656373 Try -fsched-pressure for ARM I have to admit that instruction scheduling is quite hard, but if we can do something here, that will be great. I've put it in "performance-insdie-gcc" session on UDS. Let us talk about it a little there next week. During this investigation, I also find LTO or "whole-program optimization" is useful to some EEMBC benchmarks. (I didn't run LTO/WPO at all, but I got this when read source of benchmarks) [1] Plan of CS304: Thumb2 tuning investigation. http://lists.linaro.org/pipermail/linaro-toolchain/2010-October/000300.html [2] https://wiki.linaro.org/YaoQi/Sandbox/Thumb2SpeedOptimization -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 6 months

1
0
0 0

finding in 4.5.2 20101003 (Linaro) [release 4.5-2010.10-0]

by leonid.moiseichuk＠nokia.com

Hello, Sorry I cannot find a bugzilla. One issue detected during compilation of ffmpeg, it looks like gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I"/home/ldm/misc/tc/suite/cases/ffmpeg/ffmpeg" -O3 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99 -fomit-frame-pointer -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -fno-math-errno -fno-signed-zeros -c -o libavcodec/dsputil.o libavcodec/dsputil.c /tmp/ccK6jdSP.s: Assembler messages: /tmp/ccK6jdSP.s:34764: Error: VFP/Neon double precision register expected -- `vmovl.s16 q3,s12' /tmp/ccK6jdSP.s:34781: Error: VFP/Neon double precision register expected -- `vmovl.s16 q2,s8' /tmp/ccK6jdSP.s:34798: Error: VFP/Neon double precision register expected -- `vmovl.s16 q1,s4' /tmp/ccK6jdSP.s:34800: Error: VFP/Neon double precision register expected -- `vmovl.s16 q0,s0' /tmp/ccK6jdSP.s:34820: Error: VFP/Neon double precision register expected -- `vmovl.s16 q8,s8' The sources, assembler and test case are attached. With best wishes, Leonid

15 years, 6 months

3
4
0 0

2010-10-18 Toolchain WG minutes

by Michael Hope

Minutes from the 2010-10-18 call are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-18 I'm afraid I lost the recording of this call so the minutes are incomplete Minutes from the 2010-10-20 standup call are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-18 The calls focused on the upcoming summit. -- Michael

15 years, 6 months

1
0
0 0

Linaro@UDS sessions

by Michael Hope

Hi there. I've updated the list of potential Summit sessions based on yesterdays call. Could people please check the Sessions table on https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-18 and flesh out the agenda for sessions that have your name against them. The agenda should be five to ten discussion points, preferably of things that are not well understood and could use input from the group. There's a good discussion on what to expect at a Summit here: http://oubiwann.blogspot.com/2010/10/q-the-ubuntu-developer-summits.html You can check the already-approved sessions here: http://summit.ubuntu.com/uds-n/ Feel free to join in to any other sessions you might find interesting. There will be quite a few people with diverse backgrounds there, including ~80 people from Linaro, ~400 from Ubuntu, ~200 from the community, and ~200 remote. The overlap between Toolchain and Ubuntu interests might not be great, so I'll make sure a common work room is available for idle time. -- Michael

15 years, 6 months

1
0
0 0

Flavoured toolchains anyone?

by Marcin Juszkiewicz

Some of Linaro developers works with ARM devices older then ARMv7-a architecture. Other people experiments with hard-float ABI. Each of them has to rebuild toolchain for own use and that means playing with components to have them build properly. But it is no more - I made some patches and armel-cross-toolchain-base since 1.53 version + newer source packages for gcc-4.[45]-armel-cross have support for "debian/flavour" file which allows to set some flags related to toolchain build. So far supported things are: - ARM architecture - float ABI - FPU mode - Thumb mode This feature is not merged into regular Ubuntu packages yet as this is work in progress which needs to be cleaned first. http://people.linaro.org/~hrw/armel-cross-toolchain/ has all source packages needed. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 6 months

2
1
0 0

Flavoured toolchains anyone?

by Marcin Juszkiewicz

Some of Linaro developers works with ARM devices older then ARMv7-a architecture. Other people experiments with hard-float ABI. Each of them has to rebuild toolchain for own use and that means playing with components to have them build properly. But it is no more - I made some patches and armel-cross-toolchain-base since 1.53 version + newer source packages for gcc-4.[45]-armel-cross have support for "debian/flavour" file which allows to set some flags related to toolchain build. So far supported things are: - ARM architecture - float ABI - FPU mode - Thumb mode This feature is not merged into regular Ubuntu packages yet as this is work in progress which needs to be cleaned first. http://people.linaro.org/~hrw/armel-cross-toolchain/ has all source packages needed. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 6 months

1
0
0 0

NEON vectorization: use of specialized load/store instructions

by Julian Brown

I meant to send this to the "external" Linaro toolchain mailing list, not the internal CS one. Apologies to those who receive it twice! In a follow-up message, Joseph Myers pointed out a post he'd written previously on the same subject: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html In further followups (at the risk of misrepresenting Joseph & Paul Brook's opinions!), there seemed to be general agreement that a scheme something like that outlined below, with "permuting" loads/stores and some way of handling multiple in-register layouts for vectors seems like it will be a necessary addition to the vectorizer, going forward. Julian Begin forwarded message: Date: Thu, 7 Oct 2010 16:45:17 +0100 From: Julian Brown <julian(a)codesourcery.com> To: Ira Rosen <IRAR(a)il.ibm.com> Cc: Tejas Belagod <Tejas.Belagod(a)arm.com>, Linaro List <gnu-linaro-tools(a)codesourcery.com> Subject: [gnu-linaro-tools] NEON vectorization: use of specialized load/store instructions Hi, We're having some system issues, so I thought I'd take the chance to write down some things I've been thinking about re: utilising the NEON load/store instructions more effectively. I've also attempted to summarize the problems with big-endian mode. All unverified as of yet, so please take with a pinch of salt :-). Comments appreciated. It's been a while since I last thought about some of this stuff... Cheers, Julian Use of specialized load instructions ==================================== To provide good support for NEON's element and structure load/store instructions, GCC lacks support for a couple of key features: 1. A good way of representing a set of two, three or four vector registers (either D- or Q-sized), possibly with non-unit stride. 2. A generalised mapping between memory locations and lane numbers. To start with point 1: currently the element and structure load/store instructions are only supported via intrinsics. These are specified to load and store as if going via an array embedded in a union, i.e.: typedef struct int8x8x2_t { int8x8_t val[2]; } int8x8x2_t; __extension__ static __inline int8x8x2_t __attribute__ ((__always_inline__)) vld2_s8 (const int8_t * __a) { union { int8x8x2_t __i; __builtin_neon_ti __o; } __rv; __rv.__o = __builtin_neon_vld2v8qi ((const __builtin_neon_qi *) __a); return __rv.__i; } Even for a trivial test program, e.g.: #include <arm_neon.h> int foo (int8_t *x) { int8x8x2_t result = vld2_s8 (x); return vget_lane_s8 (result.val[0], 1); } We will generate code like so: sub sp, sp, #32 vld2.8 {d16-d17}, [r0] mov r3, sp vstmia sp, {d16-d17} add ip, sp, #16 ldmia r3, {r0, r1, r2, r3} stmia ip, {r0, r1, r2, r3} fldd d16, [sp, #16] vmov.s8 r0, d16[1] add sp, sp, #32 bx lr I.e., rather than being used directly, the registers loaded by vld2 will always be spilled to the stack then reloaded. This obviously reduces the usefulness of these intrinsics by a large factor. With some planning, it'd be good to find a powerful enough solution to this problem so that the same representation for multiple registers can be used by the autovectorizer as well as the intrinsic-handling code. (One difficulty is that the "foo.val[X]" interface should still be available to user code. There's probably no need for "val" to literally be an array, though other representations would require front-end changes). Assuming it's hard for the register allocator to deal with highly-constrained situations like requiring four consecutive registers, one (ugly) possibility might be to run a pass before register allocation, looking for "big" multi-register vectors and pre-allocating them to hard registers. Even using a fixed allocation of a single set of registers (e.g. make it so that all multi-reg loads/stores larger than a Q register must use d0-d7, or whatever) would probably give better code than what we produce at present, in most cases. Now, point 2. To start with, an aside: AIUI, there is currently an assumption in the vectoriser code that increasing element numbers in vector registers correspond to increasing addresses when those registers are loaded from and stored to memory (as if the vector was a short array, or alternatively as if a union of the vector register and an array of element-types had the same numberings for lanes and array indices corresponding to the same elements). Unfortunately that is only true for NEON in little-endian mode: in big-endian mode, the story is more complicated, for reasons I will try to explain. To remain compliant with the soft-float variant of the ARM EABI, we must pass vector register arguments in ARM registers (or the stack), not vector registers. This means that we must be very careful with the ordering of elements for values passed to functions. Consider the trivial function: int __attribute__((noinline)) qux (int16x8_t x) { x = vaddq_s16 (x, x); return vgetq_lane_s16 (x, 1); } This is compiled by GCC to the following (slightly unimpressively): vmov d18, r1, r0 @ v8hi vmov d19, r3, r2 vmov d20, r1, r0 @ v8hi vmov d21, r3, r2 vadd.i16 q8, q9, q10 vmov.s16 r0, d16[1] bx lr Which may then be called like, e.g.: ldmia sp, {r0-r3} blx qux So: notice that we're careful that when vector values are transferred from NEON registers to core registers, the same result will be transferred to/from memory when we use ldm/stm (core registers) or vldm/vstm (vector registers) -- i.e. we might use "vldm rX, {d18-d19}", storing d18 and d19 in consecutive increasing addresses, or "ldmia rX, {r0-r3}", again with consecutive registers in increasing memory locations, and we get the same outcome. The fact that we can use the multiple-register loads/stores is also important for spilling/reloading between vector and core registers, which inevitably happens occasionally. Notice also that when we call the above function like so: typedef union { int16x8_t quadvec; int16_t half[8]; } u; int foo (int8_t *x) { u bar; int i; for (i = 0; i < 8; i++) bar.half[i] = i; qux (bar.quadvec); } The value returned from "qux" is NOT 2 (1+1), as it would be if we were accessing the value at index 1 in the superimposed array in the union "u". The vgetq_lane_s16 call still interprets the array as if it had been loaded in little-endian element order. But we don't get the result we would have if the vector had been interpreted in purely big-endian order either (i.e. 12, 6+6)! In fact from the perspective of the element numbering used by vgetq_lane_s16, the vector elements we see for each of the (equal) operands of the "vadd" instruction in the qux function are: equiv. core register lane number (at function entry) value ----------- -------------------- ----- [0] high part of r1 3 [1] low part of r1 2 [2] high part of r0 1 [3] low part of r0 0 [4] high part of r3 7 [5] low part of r3 6 [6] high part of r2 5 [7] low part of r2 4 So the value returned will be 2+2, 4. Now, coming back to the vectorizer. Current practice means that increasing element numbers should correspond to increasing memory locations: i.e., that "array ordering" is in effect, just as in the call to vgetq_lane_s16 in the above example. This leads to an anomaly: it means that when the vectorizer asks for a particular element, it will generally get a different one. Most of the time we get away with this, since the vectorizer mostly deals with "opaque" vectors which are operated on element-wise: i.e. we only deal with data at the granularity of whole vectors, so it doesn't matter which order the elements are in. The ARM implementations of reduction operations fortuitously calculate the results across all elements simultaneously, so when one of those elements is extracted, we still get the right answer. One notable exception to this though is the movmisalign<mode> patterns: these are implemented using the vld1 and vst1 instructions, which load elements in "array" order (increasing elements from increasing memory locations), even in big-endian mode. Since vectors loaded using those instructions are "incompatible" with the above scheme, such misaligned accesses are simply disabled in big-endian mode. Of course, generally, sticking with the current non-solution in big-endian mode is not sustainable (and is probably already broken in various cases). So it might be worth thinking about whether supporting big-endian mode properly, as well as handling the more complex load and store element/structure instructions, can be done using some generalised solution. I'm thinking (without having much idea about how feasible such an idea is) of something along the lines of a function (in the mathematical sense) attached to each vector value manipulated by the vectorizer, to map that value's element numberings to and from memory offsets. So then the quad-word vector of 16-bit elements discussed above would look like, in big-endian mode: foo, {6, 4, 2, 0, 14, 12, 10, 8} Whereas in little-endian mode (or in big-endian mode, for vectors loaded using vld1), it would look like: foo, {0, 2, 4, 6, 8, 10, 12, 14} And then, perhaps more interestingly, a vector loaded using e.g. a "multiple 3-element structures" load, vld3.16 {d1, d2, d3}, [rN] Might look like (in either endianness, assuming we can represent a vector of such size in our hypothetical scheme): foo, {0, 6, 12, 18, 2, 8, 14, 20, 4, 10, 16, 22} Though it's not clear that such a scheme would be powerful enough to represent the whole range of element/structure loads/stores available (you'd probably need to be able to specify skipped or don't-care elements to do that, at least).

15 years, 6 months

3
4
0 0

Plan of CS304: Thumb2 tuning investigation

by Yao Qi

First of all, the goal of this work is about investigation on speed improvement on linaro gcc 4.5. Finally, the output/result of this work is to list all possible recommendations/actions to improve speed on linaro 4.5. Comments to this plan are welcome. So far, we can improve speed in three ways, 1. Backport patches from FSF GCC 4.6. Note that we don't want to backport the whole 4.6. 2. Benchmark with FSF GCC 4.5.0. Fix performance regressions if there are on linaro gcc 4.5. Output is the reason of performance regression, or even further, give recommendations on how to fix it. 3. Study the code generated by other ARM compilers, and give recommendations on how to improve GCC to do better job. I'll describe these three ways in details in the following sections, - Backport patches from FSF GCC 4.6 I went through gcc-patches archive, and select several patches that are helpful to code improvements. 1 ifcvt optimization. Target independent. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00832.html 2 redundant register move for sign extending. Thumb2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137 3. PR 45335 Use ldrd and strd to access two consecutive words. Not yet approved. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00059.html 4. Fix an if statement in arm_rtx_costs_1. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02096.html 5. Reduce code duplication for Thumb2 move patterns http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00624.html 6. ARM ldm/stm peepholes http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00512.html 7. PR44999 Replace "and r0, r0, #255" with uxtb in thumb2 http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01700.html 8. Improve optimization to transform TST into LSLS http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02518.html 9. Fix bswap patterns for ARM / Thumb and Thumb2. http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01238.html - Fix speed regression I found speed regression on EEMBC on linaro 4.5, compared with FSF GCC 4.5.0, and I'll investigate why speed regression happens on these cases. Here is a table below about speed regression compared between FSF GCC 4.5.0 and Linaro GCC 4.5 (revno:99398) O2 O3 puwmod01, -5.5 -3.5 bitmnp01, -7.9 -0.7 routelookup, -6.4 -8.2 conven00data_1, -7.2 -5.8 conven00data_2, -8.1 -7.3 conven00data_3, -6.6 -5.5 viterb00data_1, -1.7 +5.9 viterb00data_2, -4.3 +2.6 viterb00data_3, -2.3 +1.8 viterb00data_4, -5.3 -0.3 - Study the code generated by other ARM compilers. In this part, I'll study the binary generated by other ARM compilers, and try to teach GCC smart enough to do the same thing. This piece of work is quite open, and hard to estimate how much output we could get. -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 6 months

4
6
0 0

Gcc test suite failures

by Nicolas Pitre

People here might want to have a look at this bug: http://gcc.gnu.org/bugzilla/show_bg.cgi?id=45979 Note that the heap randomization feature added to the kernel was part of a Linaro security blueprint. Nicolas

15 years, 6 months

3
2
0 0

Linaro Toolchain 2010.10 release

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the 2010.10 consolidation release including Linaro GCC 4.4, Linaro GCC 4.5, and the first version of Linaro GDB 7.2. Linaro GDB 7.2 2010.10-0 is the first release in the 7.2 series. Based off the latest GDB 7.2, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: * Backtraces in Thumb-2 code are significantly improved * Much better prologue and epilogue parsing * Improved software watchpoint support * Many test suite tidy-ups Linaro GCC 4.5 is the third release in the 4.5 series. Based off the latest GCC 4.5.1+svn, it includes many ARM-focused performance improvements and bug fixes. Linaro GCC 4.4 is the fourth release in the 4.4 series. Based off the latest GCC 4.4.5, it fixes many of the issues found during building Ubuntu over the last few months. Interesting changes include: * Linaro GCC 4.4 is now based off FSF GCC 4.4.5 * Cortex A8 and Cortex A9 scheduler NEON improvements * Better code generation for constant addresses with inline assembly * Better code for copying small constant strings * Various correctness improvements Downloads are available from the Linaro GCC and GDB pages on Launchpad: https://launchpad.net/gcc-linaro https://launchpad.net/gdb-linaro -- Michael

15 years, 6 months

1
0
0 0

DCC device driver and gdb server

by Øyvind Harboe

Hi all, I was wondering someone knows about a ARM DCC (debug communications channel) device driver. The idea is to run gdbserver on /dev/dcc such that application debugging does not hog a serial/ethernet port. I'd modify OpenOCD to forward the DCC onto a TCP/IP port to connect GDB to the gdbserver. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer

15 years, 6 months

3
5
0 0

New Linaro Toolchain meeting covering American timezones

by Michael Hope

(cc'ed to linaro-toolchain, bcc'ed to others who may be interested) I'm considering adding a new Linaro Toolchain meeting to cover people in the North/South American timezones. We've got quite a few people in that area who are interested in the toolchain but can't make the current 0900 UTC calls. How about a weekly half-hour call on Wednesdays at 1800 UTC? Once daylight savings drops out on the 7th of November, this would be 1000 Sacramento/PST, 1200 Houston/CST, and a reasonable evening time for those in Europe who wish to join. This will be a technical call and can cover topics such as status updates, release plans, reported problems, and any input from toolchain users. Please send me an email if you are interested, -- Michael

15 years, 6 months

3
3
0 0

System directories when cross-compiling

by Michael Hope

Hi Marcin. Would you consider passing --enable-poison-system-directories to the cross compiler configure? This makes the '-Wpoison-system-directories' option available which warns you if the cross compiler picks up a library or header file from /usr instead of the cross-build environment. I'm talking with someone who's looking at using the Linaro compiler and had a strange error due to picking up the host crtn.o. Having this warning would of tracked down the problem faster. -- Michael

15 years, 6 months

4
4
0 0

the linaro toolchain and older arm versions

by John Rigby

I believe that the libgcc.a in our toolchain contains Thumb-2 code. I verified this by doing objdump on libgcc.a and I see combinations of 16 and 32 bit instructions. So does that mean that the toolchain is only usable for ARM versions that support Thumb-2? Thanks, John

15 years, 6 months

13
21
0 0

CS MinGW patches

by Andrew Stubbs

As discussed in the meeting yesterday, CodeSourcery has a few MinGW patches that I had not merged into Linaro GCC. I have now investigated these patches, and I'm fairly happy that most are not necessary for Linaro. They're mainly about interworking with Cygwin. The one exception is this one: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01214.html (and even that is primarily a GDB issue). Andrew

15 years, 7 months

3
3
0 0

2010-10-04 Toolchain WG minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04 A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/ Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle. -- Michael

15 years, 7 months

5
8
0 0

ltrace + thumb2

by Zach Welch

I made a patch for ltrace that adds support for Thumb-2. There's not much to it, but it allows me to trace applications built for Cortex-A8. Without it, users will experience this bug: https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796 Unfortunately, it appears that the upstream tree is not well-maintained. I posted it to the mailing list for the project, but others' patches have been ignored for many months. However, my post precipitated another contributor to offer to maintain the package. I also posted this patch as the proposed solution for the above LP bug, which should allow Linaro to benefit from the work without worrying about upstream. In fact, a new version of the package appears to have been released that includes my patch (0.5.3-2ubuntu6). Please give this updated package a whirl and let me know if there is more work to be done. Thoughts? Unless I hear feedback from others, I will assume that this tool now works for Cortex-A[89] and move on to other tasks. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

15 years, 7 months

4
9
0 0

People wanting Cortex-A9 boards

by Michael Hope

(this is for current Toolchain WG members. Sorry if I got anyone else's hopes up) We'll soon be coming into some decent dual-core Cortex-A9 boards that have 1 GB of RAM and a good set of USB ports. I've asked for four of them with hard drives to go into the data centre for general use. Would anyone also like one for their desk? Note that you're generally better off using a data centre board as it's one less thing to maintain. -- Michael

15 years, 7 months

1
0
0 0

Armel cross compilers for lucid

by Marcin Juszkiewicz

Hi I finally built armel cross compiler packages for Ubuntu 10.04 'Lucid' LTS. They are available in unsigned APT repository: deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./ They are built from Maverick packages: - binutils-source - eglibc-source - gcc-4.4-source - gcc-4.5-source - linux-source-2.6.35 - armel-cross-toolchain-base - gcc-4.4-armel-cross - gcc-4.5-armel-cross So they do not give exactly same versions as compilers used in 10.04 - please remember about it while doing cross builds. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 7 months

3
3
0 0

ffmpeg regression

by Michael Hope

Hi Julian. For your reference, the performance of ffmpeg on a certain h.264 video decode has regressed since 4.4.0. See: http://ex.seabright.co.nz/helpers/benchcompare for the relative numbers. We're significantly better than 4.4.0 in the two other test videos, and better than 4.5.1 in all. The video itself is here: http://ex.seabright.co.nz/misc/cbuild/live/cbuild/files/ffmpeg/03-src13_hrc… ffmpeg is configured with -mfpu=vfp3 with the hand-written assembler backend turned off. The vfp3 is an accident - I forgot to explicitly set it to neon. You can see how to ffmpeg was configured here: http://ex.seabright.co.nz/misc/cbuild/live/cbuild/lib/ffmpegbench.mk The particular version is available here: http://ex.seabright.co.nz/misc/cbuild/live/cbuild/files/ffmpeg-0.6.tar.xz If you have time, please have a look at it. If not file a ticket on Launchpad and we'll look at it as part of the speed improvements. -- Michael

15 years, 7 months

2
2
0 0

Host strip corrupts cross-built binaries

by Loïc Minier

Hi folks apparently some tool calls "strip" instead of "$triplet-strip" when cross-building; this is something we shall fix, but it is apparently corrupting the binaries in some cases: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/615765 It seems the ELF architecture isn't set properly, or so I'm told. Which component is to blame here? Are we looking at a binutils or a gcc bug for not being able to set or read enough data that the architecture mismatch isn't detected? What could we do about it? Thanks! -- Loïc Minier

15 years, 7 months

5
10
0 0

2010-09-27 Toolchain WG Minutes

by Michael Hope

The minutes from the (short) 2010-09-27 Toolchain WG meeting are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-09-27 A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/2010/09/2010-09-27-weekly-call/ Fairly quiet this week due to being in the middle of things. Discussions include the Toolcahin WG Versatile Express board status, upstream patch status, how to divide future work up with ARM, LTO, and benchmarks. -- Michael

15 years, 7 months

1
0
0 0

Linaro Valgrind snapshot 20100927 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the availability of a "developer preview" of Valgrind which includes the support for ARM and Thumb which has recently been added by the Valgrind developers. Our aim with this preview release is to advertise Valgrind's improved ARM support and encourage people to try it out and find bugs before the official 3.6.0 release. Please report bugs via upstream's BTS: http://valgrind.org/support/bug_reports.html or you can ask on linaro-toolchain(a)lists.linaro.org if you have any problems. This release is a snapshot of upstream subversion; it should generally work but you may encounter bugs, especially if you run it on hand-optimised assembly that uses obscure instructions. New (upstream) features in this snapshot include: * Greatly improved support for ARM * Support for the Thumb instruction set * Support for NEON and VFPv3 instructions Known issues: * callgrind has difficulty identifying ARM function call and return so may not produce useful results Downloads are available from the Linaro Overlay PPA: https://launchpad.net/~linaro-maintainers/+archive/overlay ...so if you're running Linaro on an ARM system you should be able to just install it with 'apt-get install valgrind'. -- Peter Maydell

15 years, 7 months

1
0
0 0

Rough OpenOCD Plan

by Zach Welch

To All Ye Linaro Toolchain Folk, (and OpenOCD developers too) After a week of reading specifications and code, I am ready to start doing some serious hacking on OpenOCD. The following outlines my present plans and expectations, with the caveat that time can change everything. Last week, I started testing my BeagleBoard with OpenOCD, so I have begun trying to validate and improve the Cortex-A8 support. Indeed, I have already committed a minor patch that fixed a bug in the trunk caused by new command syntax required to distinguish physical memory addresses from virtual ones. That bug had been preventing the BeagleBoard support from working for several months, so this seems to show that nobody has been using (or even testing) the latest code with that board. It seems that much of the debug architecture can be shared between these two cores, so features added and bugs fixed for A8 should help me implement A9 faster. Indeed, A9 support may be more a matter of refactoring the existing code than developing new code. In this respect, the lists of tasks for A8 and A9 may end up proceeding in parallel. Cortex-A8: 1) Add missing topology detection for determining location of AHB-AP (for system memory access), APB-AP (for DAP and other CoreSight components), and register address range for accessing the DAP. 2) Fix Halt After Reset functionality (using vector catch magic). 3) Expose missing VFP3/NEON registers (only when present). 4) Fix various memory and resource leaks. Cortex-A9: 1) Basic bring-up to successful attachment with debugger. 2) Develop board scripts for common evaluation boards. 3) Work on advanced features: - download and run algorithms out of memory, - breakpoints/watchpoints, - tracing and performance monitoring, 4) Ensure SMP support works out-of-the-box. Finally, it would be good to produce a new release when all of these changes have made it into the tree. Due to various factors, the project has not achieved a regular release schedule, but these features would help to justify the effort from the community. P.S. I have cc'd the openocd-development list in the hope of generating useful feedback, but it requires subscribing to post (last I checked). Sorry for the bad netiquette. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

15 years, 7 months

2
3
0 0

Linaro GDB release process

by Ulrich Weigand

Hello, I've now checked the Linaro branding changes in to the gdb-linaro Bazaar repository. I've created a Wiki page describing the Linaro GDB release process based on that repository: http://wiki.linaro.org/WorkingGroups/ToolChain/GDBReleaseProcess (modeled after Andrew's GCCReleaseProcess page) Review and comments are welcome! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 7 months

4
6
0 0

NEON vectorization improvements - preliminary notes

by Julian Brown

Hi, In case this is useful in its current (unfinished!) form: here are some notes I made whilst looking at a couple of the items listed for CS308 here: https://wiki.linaro.org/Internal/Contractors/CodeSourcery Namely: * automatic vector size selection (it's currently selected by command line switch) * also consider ARMv6 SIMD vectors (see CS309) * mixed size vectors (using to most appropriate size in each case) * ensure that all gcc vectorizer pattern names are implemented in the machine description (those that can be). I've not even started on looking at: * loops with more than two basic blocks (caused by if statements (anything else?)) * use of specialized load instructions * Conversly, perhaps identify NEON capabilities not covered by GCC patterns, and add them to gcc (e.g. vld2/vld3/vld4 insns) * any other missed opportunities (identify common idioms and teach the compiler to deal with them) I'm not likely to have time to restart work on the vectorization study for at least a couple of days, because of other CodeSourcery work. But perhaps the attached will still be useful in the meantime. Do you (Ira) have access to the ARM ISA docs detailing the NEON instructions? Cheers, Julian

15 years, 7 months

3
4
0 0

arm thumb veneer question

by John Rigby

While trying out the u-boot-next branch I found a problem. First some explanation. On most platforms, u-boot is linked to the address it will first start running. For example when using NOR flash U-Boot will be linked to an address in flash. Very early in the boot process, U-Boot copies itself to the top and ram and jumps there. This relocation has worked for years on powerpc and other arches. The -next tree adds this for arm and it almost works. The part that does not work is that some veneer routines do not get fixed up. Here is an example. A routine called i2c_init calls __aeabi_idiv. Here is the disassembly: ... 288: e59f0148 ldr r0, [pc, #328] ; 3d8 <i2c_init+0x1a4> 28c: e1a01083 lsl r1, r3, #1 290: ebfffffe bl 0 <__aeabi_idiv> 294: e2507006 subs r7, r0, #6 298: 4a000001 bmi 2a4 <i2c_init+0x70> Later after this .o is linked with everything else and libgcc that morphs to: 8000b384: e59f0148 ldr r0, [pc, #328] ; 8000b4d4 <_end+0xfff97c98> 8000b388: e1a01083 lsl r1, r3, #1 8000b38c: eb00aa43 bl 80035ca0 <____aeabi_idiv_veneer> 8000b390: e2507006 subs r7, r0, #6 8000b394: 4a000001 bmi 8000b3a0 <i2c_init+0x70> and the veneer version is at the end of text with other veneers: 80035ca0 <____aeabi_idiv_veneer>: 80035ca0: e51ff004 ldr pc, [pc, #-4] ; 80035ca4 <_end+0xfffc2468> 80035ca4: 80035999 .word 0x80035999 80035ca8 <____aeabi_llsl_veneer>: 80035ca8: e51ff004 ldr pc, [pc, #-4] ; 80035cac <_end+0xfffc2470> 80035cac: 80035c7d .word 0x80035c7d 80035cb0 <____aeabi_lasr_veneer>: 80035cb0: e51ff004 ldr pc, [pc, #-4] ; 80035cb4 <_end+0xfffc2478> 80035cb4: 80035c61 .word 0x80035c61 80035cb8 <____aeabi_llsr_veneer>: 80035cb8: e51ff004 ldr pc, [pc, #-4] ; 80035cbc <_end+0xfffc2480> 80035cbc: 80035c49 .word 0x80035c49 80035cc0 <____aeabi_uidivmod_veneer>: 80035cc0: e51ff004 ldr pc, [pc, #-4] ; 80035cc4 <_end+0xfffc2488> 80035cc4: 8003597d .word 0x8003597d 80035cc8 <____aeabi_uidiv_veneer>: 80035cc8: e51ff004 ldr pc, [pc, #-4] ; 80035ccc <_end+0xfffc2490> 80035ccc: 80035721 .word 0x80035721 80035cd0 <____aeabi_idivmod_veneer>: 80035cd0: e51ff004 ldr pc, [pc, #-4] ; 80035cd4 <_end+0xfffc2498> 80035cd4: 80035c2d .word 0x80035c2d then if we look at 80035998 we see some thumb code. 80035998 <__aeabi_idiv>: 80035998: 2900 cmp r1, #0 8003599a: f000 813e beq.w 80035c1a <.divsi3_nodiv0+0x27c> When u-boot copies itself to ram it relocates the jump tables it knows about and could relocate the addresses in the veneer routines if it knew about them. There are at least three possible ways to fix these: 1) u-boot has its own private libgcc and if I use it the problem goes away. 2) is there an option for the toolchain to use an arm libgcc instead of thumb? 3) is there a way to find the veneers at runtime and fix them up? All input welcome. Thanks, John

15 years, 7 months

5
15
0 0

Branding for Linaro GDB package

by Ulrich Weigand

Hello Michael, I'm looking into "branding" changes needed for a Linaro GDB release. So far I've made the following changes: - Set default PKGVERSION to "Linaro GDB" instead of "GDB" - Set default BUGURL to "http://bugs.launchpad.net/gdb-linaro/" instead of "http://www.gnu.org/software/gdb/bugs/" - Set version number according to Linaro version scheme - Update release script to generate tarballs/directories named "gdb-linaro-$VERSION" instead of "gdb-$VERSION". As a result, the default GDB startup output now reads: GNU gdb (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. Do you agree that this is the way we should go? Have I overlooked anything? Unless there are objections, I'm planning to check these changes in later this week. As a related question, the generated files in a standard GDB 7.2 release seem to have been built on a relatively old system (RHEL 4 ?), which is visible through the versions of tools like bison, flex, texinfo, and gettext used to build those files. When building our Linaro GDB release tarballs, should we: - just use the tools as installed on a recent build system (say, Ubuntu Lucid), or - attempt to rebuild the release with the exact same set of tools used for the GDB 7.2 release? The second option has the advantage of reducing the amount of changes, e.g. visible in a full diff of the release tarballs. However, it has the disadvantage that reconstructing those exact set of tools (including Red Hat patches, it seems) is somewhat difficult, and can in addition lead to somewhat outdated results ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 7 months

4
6
0 0

OpenOCD

by Zach Welch

Hi all, I was recently hired by CodeSourcery and have been assigned to Linaro for the purpose of improving OpenOCD. Specifically, I will be adding new support for Cortex-A9 SMP, though I may also make a few improvements to its handling of Cortex-A8 in the process. If you have experience using OpenOCD in these contexts, let me know if you have any specific requests for features or fixes, and I will try to fold them into my plans. After this cross-posted introduction, I believe that most of my correspondence will appear on the Toolchain mailing list, but I wanted to make sure that everyone knows that they can find me there. Cheers, -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

15 years, 7 months

5
5
0 0

Linaro GCC 4.4 and 4.5 2010.09 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.4 and Linaro GCC 4.5. Linaro GCC 4.4 is the third release in the 4.4 series. Based off the latest GCC 4.4.4, it pulls in the pre-4.4.5 changes made by the FSF over the last six months. Linaro GCC 4.5 is the second release in the 4.5 series. Based off the latest GCC 4.5.1, it finishes the merge of many ARM-focused performance improvements and bug fixes. Interesting changes include: * Improved performance on the Cortex-A9 * Backports of a range of performance improvements from mainline * New inline versions of the GCC builtin sync primitives Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro Also available is an early release of optimised string routines for the Cortex-A series, including a mix of NEON and Thumb-2 versions of memcpy(), memset(), strcpy(), strcmp(), and strlen(). For more information see: https://launchpad.net/cortex-strings Pre-build packages are available in the Linaro Toolchain PPA at: https://launchpad.net/~linaro-toolchain-dev/+archive/ppa -- Michael

15 years, 7 months

5
11
0 0

Thumb2 code size improvements

by Yao Qi

Hi, We are looking for some possible improvements and optimizations on thumb2 code size. Currently, I am running some benchmarks with compilation flag "-Os -march=armv7-a -mthumb", and hope to find some thing interesting that we can improve. Beside that, do you have some ideas on this topic? or do you have some observations on thumb2 code that we may probably improve the size? Any thoughts on this are appreciated. Yao

15 years, 7 months

11
30
0 0

State of cross compiler packages

by Marcin Juszkiewicz

I think that it is easier to describe situation in email then on irc. Currently there are 4 packages related to cross compilation support: - armel-cross-toolchain-base (a-c-t-base in short) - gcc-4.4-armel-cross - gcc-4.5-armel-cross - gcc-defaults-armel-cross Each of them got into archive but they need to be updated to get installable packages. Status of each package: 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source 4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross toolchain and generates: - binutils-arm-linux-gnueabi (from binutils-source) - libc6(-dev,-dbg)-armel-cross (from eglibc-source) - linux-libc-dev-armel-cross (from linux-source-2.6.35) - gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from gcc-4.5-source) libgcc1* packages have /usr/share/doc/ directories as symlinks to /usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/ I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have /usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix this symlink by providing those files in libgcc1 package instead. 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with gcc-4.4-source 4.4.4-14ubuntu4 version. This package provides compilers, libstc++6-4.4-(dev,dbg,pic)-armel-cross, libmudflap0-4.4-dev-armel-cross and gcc-4.4-arm-linux-gnueabi-base packages. I have 1.38 version ready to upload which fixes #637454 #640298 bugs. 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with gcc-4.5-source 4.5.1-7ubuntu1 version. This package provides compilers and runtime libraries. But it does not provide libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because they are in a-c-t-base source package. All resulting packages have /usr/share/doc/ directories pointing into gcc-4.5-arm-linux-gnueabi-base one which is policy violation. I have 1.37 version ready to upload which fixes #637454 #640298 bugs and provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is removed. 4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any changes. Main problem is that packages generated from gcc-4.5-source are split into two packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and gcc-4.5-armel-cross (all the rest). This was required to allow to bootstrap cross compiler but gives problems when one is built with other version of gcc-4.5-source then other - resulting packages are not installable (we have it now in archive). It is also a thing which Matthias does not like and I understand it. For now my only solution is to build both with one version of gcc-4.5-source. What are your opinions? http://marcin.juszkiewicz.com.pl/download/ubuntu/ is download link for mentioned versions. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 7 months

2
2
0 0

Re: GCC PRE patch; apply or not?

by Steven Bosscher

xf. http://lists.linaro.org/pipermail/linaro-toolchain/2010-August/000069.html > It is not upstreamable due to copyright issues, but we have a policy > that we can keep such patches, if we wish. I wrote this patch. If I am the copyright issue, then there is no issue. I have a copyright assignment for all my GCC work to the FSF. That assignment also covers the patch in the e-mail stored at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html. I consider copyright to all my patches assigned to the FSF if I have submitted the patches to gcc-patches(a)gcc.gnu.org, or attached them to a Problem Report in GCC bugzilla, or both. The only reason why this patch for GIMPLE PRE is not in the FSF GCC already, is that I just never cared enough to pursue it. GCC is just a hobby for me, and experimenting with ideas is fun. Doing all the required testing for inclusion in the FSF GCC is not fun and it costs time that I usually can't find. I am just too busy with other things to clear off this and other pending patches/ideas from my TODO list :-) If you wish to submit this patch for the FSF GCC, please feel free to do so. In fact, I'd encourage you to do so. Likewise for my patch for e.g. http://gcc.gnu.org/PR20070, and for the GIMPLE hoisting pass. Ciao! Steven

15 years, 7 months

1
0
0 0

binutils testsuite Thumb-2 coverage

by Chung-Lin Tang

Hi, about the status of binutils testsuite Thumb coverage (CS204 in the workplan), I have filed two Launchpad bugs: #640263: Testsuite coverage: Thumb-2 VFP/NEON encodings https://bugs.launchpad.net/binutils-linaro/+bug/640263 #640272: Testsuite coverage: Thumb relocations https://bugs.launchpad.net/binutils-linaro/+bug/640272 To summarize: I currently do not see any testing of Thumb-2 VFP/NEON encodings; Thumb mode relocations are also only barely tested in the ld testsuite. Also, please inform if there are any other areas of binutils Thumb testing that may be of concern to Linaro. Thanks, Chung-Lin

15 years, 7 months

2
1
0 0

Thumb2 size optimization report

by Yao Qi

* Goal Goal of this work is to look for thumb2 code size improvements on FSF GCC trunk. * Methodology ** Build FSF GCC trunk w/ and wo/ hardfp, run benchmarks including eembc, spec2000, and dhrystone, and check asm code to see if there is any possible improvements on size. ** Get input and suggestion from ARM experts. ** Search open PRs in GCC bugzilla. * Results Each item has been tracked on launchpad, and is listed with some elements, ** Cause: cause of this problem is known or unknown ** Difficulty: estimation of implementation difficulty ** Recommendation: Yao's recommendation on that bug for next step 1. LP:633233 Push/pop low register rather than high register when keeping stack alignment As Richard E. pointed out, it was implemented in gcc-4.5 on 2009, but Yao still can see the usage of r8 on FSF GCC trunk. Cause: Might be a regression if problem disappears on gcc-4.5. Difficulty: Easy. might not hard to fix a regression. Recommendations: Fix this regression if it is. 2. LP:633243 Improve regrename to make use of low registers. Get input from Bernd S. and Julian B. Initial implementation has been suggested by Bernd S. Cause: current regrename in gcc treats high and low registers equally. Difficulty: Medium. Recommendation: Implement it as Bernd suggested, and do benchmarking to see how much size is improved. 3. LP:634682 Redundant uxth/sxth insn are generated Cause: Unknown Difficulty: Unknown Recommendation: No recommendation so far. 4. LP:634696 Function is not inlined properly with -Os In consumer/cjpeg/jmemmgr.c, GCC inlined out_of_memory() with -Os, so increase code size. Cause: Unknown. Difficulty: Unknown Recommendation: Educate GCC to inline carefully when -Os is turned on. 5. GCC PR40730 LP:634731 Redundant memory load 6. LP:634738 inefficient code to extract least bits from an integer value GCC PR40697 is for thumb-1. The same problem is in thumb-2. Cause: Unknown. Difficulty: Medium. Recommendation: Fix it the similar way as fixing GCC PR40697. 7. LP:634891 Replace load/store by memcpy more aggressively Difficulty: Should be easy. Recommendation: Fix to this problem might be "reduce threshold value once -Os is turned on". 8. LP:637220 allocate local variables with fewer instructions GCC PR40657 is about this kind of problem, and was fixed. The similar prolbme exits on gcc with hardfp. Cause: Unknown. Difficulty: Unknown. Recommendation: No recommendation so far. 9. GCC PR 43721 Failure to optimize (a/b) and (a%b) into single __aeabi_idivmod call Difficulty: Medium or easy. Recommendation: No. 10. LP:637814 Combine add/move to add LP:637882 Combine ldr/mov to ldr Possible improvements have been found. No idea how to fix it yet. Cause: Unknown. Difficulty: Unknown. Recommendation: No. 11. LP:638014 Replace memset by memclr when 2nd parameter is zero Difficulty: Easy. Recommendation: No recommendation so far. 12. LP:625233 Merge constant pools for small functions Cause: Unknown. Difficulty: Medium. Recommendation: No. 13. LP:638935 Replace multiple vldr by vldm Some vldr insns accessing consecutive address can be replaced by single vldm. It is not about thumb2, but related to code size optimization. Cause: Unknown. Difficulty: Medium. Recommendation: No. -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 7 months

2
2
0 0

Cross compiling for embedded targets

by Michael Hope

Hi there. I've always wanted to mix this: http://www.futurlec.com/ET-STM32_Stamp.shtml with some of this: http://bit.ly/cD0JPS to control my one of these: http://www.traxxas.com/products/electric/rustler2006/gallery/3705-3qrtr-Bla… and it sounds like a good opportunity to dogfood the Linaro toolchain at the same time. What's the best way to set up a Cortex-M3 toolchain with an appropriate newlib and libgcc? A wrapper script works fine but I need a way of recompiling libgcc for the Cortex-M series. I'd love to get a arm-none-eabi toolchain package out of this that others could use. Could I re-work the cross packaging to use newlib and change the configure flags instead? Are there existing Debianised cross packages that I could reuse? Ta, -- Michael

15 years, 7 months

5
5
0 0

2010.09 build results

by Michael Hope

Hi Andrew. Well, the builds are done and they're OK. I've added the ability to compare against an explicit release to make checking regressions easier. 4.4 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.4-2010.09-1/logs… i686 and x86_64 have not regressed since 2010.08. On arm, and ignoring the limits test, 2010.09 adds a failure on gcc.c-torture/compile/991026-2.c. According to the log the run timed out but I can't reproduce it. 4.5 results are here: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5-2010.09-0/logs… i686 has not regressed since 2010.08. x86_64 fails on gcc.target/i386/wmul-1.c, but this is a new tests for new features and are not a regression against 4.5.1. arm is messier. The following new failures exist: Vectoriser related: * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorized 1 loops" 1 * g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorizing stmts using SLP" 1 * gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect "vectorized 1 loops" 1 * gcc.dg/vect/vect-reduc-dot-s16b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-1c.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/vect-reduc-pattern-2b.c scan-tree-dump-times vect "vectorized 1 loops" 0 * gcc.dg/vect/wrapv-vect-reduc-pattern-2c.c scan-tree-dump-times vect "vectorized 1 loops" 0 Others: * gcc.target/arm/neon-load-df0.c scan-assembler vmov.i32[ \t]+[dD][0-9]+, #0\n * gcc.target/arm/synchronize.c scan-assembler __sync_synchronize neon-load-df0 is a new test. synchronize.c is an incorrect test as the compiler now correctly uses the dmb instruction. Your thoughts? -- Michael

15 years, 7 months

2
1
0 0

gdb-linaro bzr tree

by Yao Qi

Hi, I tried linaro gdb branch just now, $ bzr branch lp:gdb-linaro parent branch is bzr+ssh://bazaar.launchpad.net/%2Bbranch/gdb-linaro/, which looks strange. In gcc-linaro, parent branch is bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.5/ I thought parent branch of linaro gdb tree should be like bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gdb-linaro/7.2/ Is there something wrong in this branch?

15 years, 7 months

1
0
0 0

armel cross toolchain packages available in PPA

by Marcin Juszkiewicz

I would like to announce that my work on armel cross toolchain got to the very nice point - all packages are available from PPA. What does it mean to you? 1. no "are you sure to install those unverified packages" messages from APT 2. ability to easily rebuild toolchain on own machines So if you used my repository from people.canonical.com then please switch to PPA one: add-apt-repository ppa:hrw/armel-cross-compilers Old repository will be available for some time but will not get any updates. Next step: merging those packages into Maverick release. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 7 months

2
1
0 0

Basic benchmarks

by Michael Hope

I've been checking over the benchmarks as a lead up to the 2010.09 release. We're in a good way compared to both 4.4.4 and 4.5.1 for most non-trivial tests. * pybench is 10.9 % faster than 4.4.4 and 7.7 % faster than 4.5.1. * linpack is 46.4 % faster than 4.4.4 and the same as 4.5.1. * ffmpeg h.264 video decode (with hand written assembler versions turned off) is 15.4 % faster than 4.4.4 and 1.2 % faster than 4.5.1. All results are statistically invalid and against poor workloads, but I'll work on that. See http://ex.seabright.co.nz/helpers/benchcompare for more. -- Michael

15 years, 7 months

3
4
0 0

Re: Thumb2 code size improvements

by Yao Qi

Loïc Minier wrote: > I see you moved the wiki page to the public space, thanks > > Couple of notes: > * make sure you use the rename action on the page, I think this will > preserver history (I didn't check whether you did or not, but I think > not) No, I didn't. I use copy and paste. I'll use rename action. > * add a page at the old location with "#redirect NewPage" or > "#refresh 0 http://newurl/" OK, got it. Thanks for your help on wiki.

15 years, 8 months

1
0
0 0

2010-09-06 Toolchain WG Meeting Minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-09-06 A copy and activity reports are included below. -- Michael Attendees • Name Email IRC Nick Andrew Stubbs ams(a)codesourcery.com ams_cs Chung-Lin Tang cltang(a)codesourcery.com cltang Julian Brown julian(a)codesourcery.com jbrown Loïc Minier lool(a)linaro.org lool Marcin Juszkiewicz marcin.juszkiewicz(a)linaro.org hrw Matthias Klose doko(a)canonical.com doko Michael Hope michael.hope(a)linaro.org michaelh Peter Maydell peter.maydell(a)linaro.org pm215 Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Yao Qi yao(a)codesourcery.com yao Agenda • Licensing of string routines • State of valgrind • State of GDB • Open tickets □ 600298, 616141, 604753: SMP/sync related □ 605059 4.4.5 □ 629671 ICE in reload_cse_simplify_operands in thumb-1 mode □ 590696 Wrong use of objdump during cross build • Upcoming release • Creating blueprints Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Richard to check with the legal department on string licensing issues • ACTION: Peter to talk with valgrind upstream re: Linaro releasing a ARM-focused version • ACTION: Michael to organise an 'experimental' PPA that toolchain output can go into • ACTION: Michael to talk with Cody Somerville re: building on ARM • ACTION: Michael to set up a GDB 7.2 based off the release tarball • ACTION: Andrew to pull sync changes back into 4.4 for this release • ACTION: Michael to assign appropriate sync ticket to Andrew to track the backport • ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4 for this release • ACTION: Julian to do a basic investigation into 629671 • ACTION: Andrew to merge the cross-compile objdump ticket into this release and re-kick upstream process Action Items from Previous Meeting • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense • DONE: Yao to continue on GDB for a week then switch to investigation • ACTION: Peter to check into the state and progress of valgrind for the meeting on the 30th. • ACTION: Chung-Lin to shift the CSL backport list out onto the Linaro wiki • ACTION: Michael to see about doing an archive rebuild with 4.5 • DONE: Michael to send IBM's list to Yao Minutes String routines: • Michael asked Richard about getting the current str* routines by ARM transferred to Linaro • Linaro will then get these into other C libraries • FSF prefers LGPL and copyright for glibc • Linaro prefers MIT/X11 everywhere so that fixes and improvements can be shared • Richard is concerned about the copyright assignment and any patent grant • ACTION: Richard to check with the legal department on string licensing issues • Extreme fallback is to re-write the routines to all be under Linaro copyright. memcpy() and similar may need this Valgrind: • Peter has been looking at how it works on the ARM platform • Upstream is very responsive to issues • Now works on Firefox and OO.org • Upstrem doesn't have any particular release cycle • ARM changes are pretty extensive and can't be extracted • Peter suggested making valgrind available in a PPA to start with • NEON detection at startup is remaining issue • What next? □ Packaging is straight forward □ Don't want to steal upstream's thunder or release something inappropriate □ ACTION: Peter to talk with valgrind upstream re: Linaro releasing a ARM-focused version • Could bring into the Linaro overlay PPA • ACTION: Michael to organise an 'experimental' PPA that toolchain output can go into • ACTION: Michael to talk with Cody Somerville re: building on ARM GDB: • 7.2 is now available • Time to start up a gdb-linaro based on that • Matthias mentioned that we will have GDB 7.2 on Maverick • How should we manage the source □ QEMU is over git □ Could use bzr or git □ bzr with Launchpad can't handle multiple branches when pulling from git □ GDB is unique in how it's mixed in with the rest of the projects hosted on sourceare □ Branches as such are trucky □ Could just base off tarballs □ ACTION: Michael to set up a GDB 7.2 based off the release tarball Tickets: • ACTION: Andrew to pull sync changes back into 4.4 for this release • ACTION: Michael to assign appropriate sync ticket to Andrew to track the backport • ACTION: Andrew to merge the current post 4.4.4 release branch into our 4.4 for this release • ACTION: Julian to do a basic investigation into 629671 • ACTION: Andrew to merge the cross-compile objdump ticket into this release and re-kick upstream process Patch tracker: • Andrew noted that it is now fully populated with the GCC data • Has assigned various patches that still need to go upstream to Yao and Julian Next meeting is on 2010-09-08 on the public code. --- Chung-Lin Tang == Linaro Toolchain == * Google ARM patch sets: committed a second set to SG++ 4.5 trunk on Tues. AndrewS pushed both sets to Linaro. Worked on a third set, those related to PR42235, but this time regression test results were not so clean. Will look into, but considering whether to stop the backports here. * LP:628526, submitted a patch to gcc-patches for explicitly turning off stack protection in libgcc build flags, awaiting response. * LP:601030, eglibc 2.11/12 problem with ___longjmp_chk on x86-64. Problem seems to be clear, fix quite simple, but so far cannot seem to reproduce and verify. Also unclear if I should send the fix to eglibc or glibc, the idea of the latter making me a bit nervous... :P == libffi == * Got an acknowledgement from the libffi maintainer that he'll review the VFP hard-float support patch soon. == This week == * Look into remaining Google approved patches, mainly those related to PR42235 and PR42575. * Try to reproduce LP:601030 and send patch soon. * Linaro GCC investigations. --- Andrew Stubbs == Linaro GCC == * Michael has get the new patch tracker into a usable state. I've transferred all the data from the old wiki tracker, and looked up the remaining data as far as I can. The new tracker should now be fully populated with data. It's here, for the moment: http://ex.seabright.co.nz/helpers/patchtrack * Start Yao and Julian on the optimization investigation tasks. * Continue trawl through the CS bugs looking for candidates to push to the Linaro tracker. == Other == * Public holiday on Monday. * Attended the monthly CS/Linaro sync meeting. --- Yao Qi == Linaro GDB wrap up == * LP:615993 gdb.base/sigstep.exp failures Patch was committed to gdb mainline and 7.2 branch. * LP:615995 gdb.base/watch-vfork.exp failures Discussed with Pedro, create a patch, which fixed failures on ARM, but can't fix failures on x86(they are caused by different problems). Leave the x86 failures there, and patch is being reviewed in gdb-patches. == Linaro GCC == * CS306:Investigate on thumb2 improvement Read/understand previous effort related on code size improvement from CSL wiki pages. Experiment with CSL scripts for size benchmarking. With Dan's help, run benchmarking in a correct/reasonable way. 'Reproduce' some inefficient code mentioned by Julian. Some of them are still there. == Misc == * LP:605042 Revert one patch, and rebuild it. No seg fault is found. == This Week == * Continue my work on CS306. --- Peter Maydell RAG: Red: Amber: virtio-system writeup not going as fast as expected Green: ARM legal OK now received Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | ? | | I need to replan this (no forward progress this week because more important stuff intervened) Progress: virtio-system: - actually trying a SATA disk revealed that the PB926 PCI interrupt mapping was wrong; now fixed after consulting the schematics and a round or two of patch testing with Arnd - I have a PB1176 board but it doesn't seem to talk to the serial port on poweron. Will try a firmware reflash but it might just be broken... - no progress on writeup because other things intervened. valgrind: - went through the motions of getting a valgrind svn snapshot into the ubuntu packaging - tested on pegatron (A8, maverick, thumb2), found four bugs: + BX PC not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249775 + RBIT not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249924 + pwrite64 syscall not implemented (fixed upstream) https://bugs.kde.org/show_bug.cgi?id=249996 + test for presence of neon wrong https://bugs.kde.org/show_bug.cgi?id=249775 With a bodge for the last and the fixes for the first 3, valgrind now successfully runs openoffice and firefox. other: - Investigated https://bugs.launchpad.net/bugs/628471 : qemu-maemo doesn't work with new linaro beagleboard kernels. It looks like we now try to probe for NAND (which failed earlier for other reasons which I suspect are a now-fixed bug), and qemu-maemo's NAND implementation doesn't map anything at the address the nand code is trying to poll for a status bit. - first post to qemu-devel :-) (review of somebody's patch to not confuse SMC with BKPT in the arm decoder) Plans: virtio-system: - hoping to get the qemu patches into the ubuntu qemu-maemo package, which will avoid the need to talk about patching qemu - finish the writeup and put it on the wiki - test PCI patches on PB1176 valgrind: - respin a valgrind with proper fixes for everything and put it in a PPA somewhere other: - come up with some fix or workaround for #628471 - put the rebased ubuntu qemu-maemo work up onto gitorious so other people can see it Absences: Friday 5 November and 20 other days in this calendar year

15 years, 8 months

1
0
0 0

Re: Patch tracker

by Michael Hope

Looks good. I've created a real project, added a README/LICENSE, and merged your changes. See: https://launchpad.net/tcwg-web There was a funny render difference between Firefox and Chromium - revisions with no bugs lead to a rowspan of zero which Firefox doesn't like. I also pulled some common code out into a function and used the built-in variable 'loop'. 'loop' is quite nice as it provides values like .index, .first, .odd, and so on based on your position in the loop. -- Michael On Fri, Sep 3, 2010 at 11:02 PM, Andrew Stubbs <ams(a)codesourcery.com> wrote: > Hi Michael, > > I've been playing with you patch tracker, and come up with this: > > https://code.launchpad.net/~ams-codesourcery/+junk/tcwg-web > > I don't seem to be able to propose an official merge request to your branch, > but it's just a quick implementation anyway, and could probably be cleaned > up. > > The patch renders each ticket in it's own row (without changing the way the > first two columns are rendered). This means they can have their own colour > and we can maybe see better what status goes with what bug. > > To see an example of what it does, see revision 4.4:93544 > > Andrew >

15 years, 8 months

1
0
0 0

State of cross compiler packages

by Marcin Juszkiewicz

I want to share status of my cross compiler packages work with all of you. Some time ago I did a split of them into two: - armel-cross-toolchain-base (1.36 now) - armel-cross-toolchain (1.29 now) Where first one provides binutils, linux headers, libc6 and libgcc packages. Second provides final gcc. Today I got a-c-t-base to a moment when it builds fine on PPA [1]. 1.36 got sent for rebuild to fix missing gcc-4.5-arm-linux-gnueabi-base package. When it will build then a-c-toolchain package will get uploaded for build. Result will deprecate my current repository at people.canonical.com [2] because PPA gives signed repository. On Monday I will probably have to update both components because there was gcc-4.4 upload so probably gcc-4.5 will follow (so I will be able to drop one patch). Additionally I made 'gcc-defaults-armel-cross' package (available in [1]) which makes installing of cross compilers a bit easier (no need to worry which version to install - just "apt-get install gcc-arm-linux-gnueabi" is enough). Selection of cross gcc version is done in other way then native one. Native is using "gcc" package which contains /usr/bin/gcc as symlink to /usr/bin/gcc-4.4 file. Cross gcc uses "update-alternatives" to setup /usr/bin/arm-linux- gnueabi-gcc file. I want to fix it in 11.04 so cross gcc will use same method as native one. 1. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler 2. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 8 months

2
1
0 0

GDB 7.2 released

by Ulrich Weigand

Michael, a quick update to our discussion today: actually, GDB 7.2 has already been released earlier today: http://sourceware.org/ml/gdb-announce/2010/msg00003.html Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 8 months

1
0
0 0

Re: Glibc 2.12 issue

by Michael Hope

Hi Alexander. I've looked into the problem and the linker error is caused by a mix of stack protector options between libgcc and the C library. GCC includes a feature called the stack smashing protector which detects writing past the end of a stack based object. It's quite nice as it gives decent protection against buffer overruns which are the most common type of security vulnerability. The implementation is straight forward: when compiled with -fstack-protector, any function with a stack-based character array will have extra stack checking code inserted into the prologue and epilogue. The prologue allocates a canary value at the top of stack and fills it in with the value of '__stack_chk_guard' provided by libssp. The epilogue checks this value and calls `__stack_chk_fail` if it has been changed. The stack protector can interfere with some code and isn't applicable in others. The problem here is caused by a stack up of things: * glibc knows about -fstack-protector and turns it on and off for different functions and libraries * gcc knows about -fstack-protector and includes libssp if required * glibc knows about libgcc and statically links against it to ensure availability * Meego seems to turn on -fstack-protector by default (as does Ubuntu) This results in the libgcc function '_gcc_Unwind_Backtrace' being built with the stack protector and the glibc library 'libanl' without. At static link time GCC sees that the stack protector is off and skips linking against libssp, causing the missing symbol error. The solution is to add -fno-stack-protector to the libgcc build options and rebuild the compiler. I've heard (but can't track down the link) that the ARM libgcc unwind functions must be built this way in any case. See http://svn.debian.org/wsvn/gcccvs/branches/sid/gcc-4.5/debian/patches/gcc-d… for how Debian does this. Hope that helps, -- Michael On Fri, Aug 27, 2010 at 9:06 PM, <Alexander.Kanevskiy(a)nokia.com> wrote: > Hi Michael. > > I've created for you account in MeeGo OBS (build system that we use in MeeGo > is OpenSuSE build system) > > login: michaelh > password: wog-feg-da > Web client url: https://build.meego.com > API url: https://api.meego.com > > The build log that had problem with glibc 2.12 + gcc 4.5 you can find here: > > https://build.meego.com/package/live_build_log?arch=armv7el&package=glibc&pr > oject=home%3Akad%3Abranches%3ATrunk%3ATesting&repository=standard > > Might be you have some idea what went wrong, as our toolchain people were > not able to find why combination of latest gcc plus glibc 2.11.x works, but > not gcc 4.5 + glibc 2.12.0 :( > > This log is from my home project inside OBS, where stuff is already a bit > outdated. I'll ask Jan-Simon from Linux Fundation to point to right place > where latest builds are present, so you can experiment with them. > > -- > Best regards, Alexander Kanevskiy. > > >

15 years, 8 months

4
6
0 0

Ubuntu GCC version numbers

by Andrew Stubbs

Hi all, I've just discovered that Ubuntu is not using the Linaro release information in the --version string. This is not ideal when we get bug reports as it makes it hard to understand what Linaro release to use to reproduce the issue. Therefore, I've created a new wiki page to track the mappings: https://wiki.linaro.org/WorkingGroups/ToolChain/VersionMappings For now this only applies to GCC, but no doubt other tools will follow. Please help keep it up to date if you find a version is missing. I've added it to the GCC release process wiki page, so hopefully it should get looked at at least once a month. Andrew

15 years, 8 months

2
2
0 0

Versatile Express board

by Michael Hope

Hi there. We have a Toolchain WG has a Versatile Express board coming our way. It's a quad-core Cortex-A9 with 1 GB of RAM, so quite decent really. Does anyone have a pressing need for it? If not then I'll take it and make it available over SSH. -- Michael

15 years, 8 months

2
2
0 0

Toolchain WG - 2010-08-24 meeting minutes

by Michael Hope

Please find the activity reports and minutes for Monday's meeting below. The minutes are also available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-23 Minutes from the Wednesday and Friday standup calls are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-20 -- Michael Attendees • Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Chung-Lin Tang cltang(a)codesourcery.com cltang Matthias Klose doko(a)canonical.com doko Michael Hope michael.hope(a)linaro.org michaelh Peter Maydell peter.maydell(a)linaro.org pm215 Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Yao Qi yao.qi(a)linaro.org yao Agenda • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 • Upcoming release □ GCC 4.4 □ GCC 4.5 □ GDB □ Strings • 4.6 backport approach • Creating blueprints • Connecting with other groups Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Chung-Lin to move the list of other backports out of the CSL wiki and into Linaro • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense • ACTION: Yao to continue on GDB for a week then switch to investigation • ACTION: Peter to check into the state and progress of valgrind for the meeting on the 30th. Action Items from Previous Meeting Minutes Tickets: • Went through the open tickets in the agenda • Andrew will backport the SMP changes, including the sync primitives • Andrew will backport the A9 changes □ Most of the changes should come through easily □ There is a write after write hazard □ Currently uses the new cost infrastructure □ Backport the cost infrastructure if it will be used further in the future 4.6 branch: • Andrew suggested starting a 4.6 branch after the start of stage 3 □ Start landing patches early □ When FSF 4.6.0 comes out, we will have a corresponding Linaro 4.6.0 • ACTION: Chung-Lin to move the list of other backports out of the CSL wiki and into Linaro String routines: • Richard asked about the response • Michael had replies from Roland McGrath (http://sourceware.org/ml/ libc-alpha/2010-08/msg00029.html) but not the wider gcc-sc • All other architectures are LGPL and FSF assigned • The current approach is to assign a particular version to glibc • Could cause a small maintenance problem in the future • Richard isn't sure that we can assign copyright of a particular version • ACTION: Michael to re-check with TSC that we can assign copyright but keep ability to relicense 4.6 backports: • Talked about the approach for backporting 4.6 features • Won't backport every single change as then Linaro 4.5 becomes FSF 4.6 • Backport correctness fixes as the problem is found • Backport performance changes as they occur • Discussed how upstream could be tracked □ Notification of any CSL or ARM authered changes will come from them □ All changes are supposed to go through gcc-patches □ Andrew notes that gcc-cvs provides a filtered view of what actually landed □ At least monitor these lists and search for ARM|Thumb|NEON|XSCALE| Cortex|Coretx|VFP|Snapdragon|OMAP Michael noted that IBM are interested in the ARM compiler and plan to get involved soon. Michael has asked again for A9 hardware. No news yet. Future: • Would like to spend some time soon running invetigrations to spit out some blueprints • ACTION: Yao to continue on GDB for a week then switch to investigation • Andrew noted that there is one more person to come from CSL • Will ask that person to do investigation • Richard is keen to see the blueprints to check against what ARM is doing □ Michael asked for information about their planning process so that we can line things up Valgrind: • Peter noted that the valgrind changes have been committed upstream • ACTION: Peter to check into the state and progress of valgrind for the meeting on the 30th. Next meeting is a stand-up meeting on 2010-08-25 on the public code. --- Andrew Stubbs == GCC 4.5 == * Continued pushing 4.5 patches to Linaro. I have now caught up with current development I think. * Lots of discussion on the patch tracker. You'd think it was more important than the compiler .... :( == Upstream == * Did before and after tests of the Coretex-A5 scheduler against upstream HEAD. All seemed well (or at least, no worse) so I've posted the patch upstream. No word back yet .... --- Chung-Lin Tang == Hard-float == * Testing EEMBC softfp vs. hard-float calling convention performance numbers. * The only conclusive result was that OAmark is 2%-3% faster, presumably due to vector graphics-like code in that suite. May look into other code (was suggested Cairo) to see if any gain in changing to hard-float. * Withdraw earlier comment on small improvements on Automark (was not apparent after more experiment runs). * Currently working to produce report files. == Linaro GCC == * Looking at getting into GCC backport work this week. --- Yao Qi == Linaro GDB == * LP:615997 gdb.dwarf2/dw2-ref-missing-frame.exp failure Patch is committed to gdb mainline. * LP:615999 gdb.gdb/selftest.exp failure Patch is committed to gdb mainline. * LP:615995 gdb.base/watch-vfork.exp : Watchpoint triggers after vfork (sw) (timeout) With Pedro's help, got to know the failure of this case on arm and x86 are different. Created a patch as Ulrich suggested, and it works on 2.6.32, while fails in a different way on 2.6.35. Failure is caused by debuggee process is killed by a SIGTRAP. Still no clue why that can happen. == Linaro GCC == * My patch to PR45094 is approved, and checked in to mainline. == This Week == * Fix LP:615995 and other linaro gdb bugs. --- Ulrich Weigand == GCC == * Collected and wrote up suggestions for future GCC work == GDB == * Opened Launchpad bugs for known GDB problems and testsuite failures * Investigated bug #620595 (gdb.threads/threxit-hop-specific.exp failure) * Fixed bug #615998 (gdb.gdb/observer.exp failures) in mainline and 7.2 * Worked on upstream fix for #620595 (gdb.threads/threxit-hop-specific.exp failure) * Analyzed bug #620611 (Unable to backtrace out of vector page 0xffff0000) == Infrastructure == * Continued working with our order&control team to acquire IGEPv2 boards --- Peter Maydell RAG: Red: None Amber: ARM legal OK for qemu contributions still pending Green: we have approval for laptops for linaro secondees Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | 2010-08-27 | | Progress: virtio-system: - got my versatile kernel/qemu running with virtio disk and network versus non-virtio - ran some basic benchmarking (bonnie++ for disk, tbench for net). Disk is faster with virtio, but strangely networking is not! - tried an upstream qemu too -- net virtio still slower - built a realview kernel in preparation for testing Arnd's PCI patches on hardware qemu-focused-kernel: - some research into which ARM dev boards support PCI in hardware, kernel and qemu, to try to find a good choice for basing a qemu-focused kernel on merge-other-branches: - started compiling list of qemu branches for possible consolidation Issues: the intersection of (recent ARM hardware) (PCI support) and (supported in qemu) looks suspiciously like the empty set. Plans: virtio-system: - borrow some versatile or realview hardware and test Arnd Bergmann's PCI patches - make a start on writing up the config/benchmark results qemu-focused-kernel: - flesh out this blueprint valgrind: - try to build an ARM valgrind from upstream's thumb branch Absences: Friday 5 November and 20 other days in this calendar year

15 years, 8 months

1
0
0 0

Toolchain WG - 2010-08-18 stand up minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 I'm going to stop sending out emails about the stand up minutes and include links the weekly minutes instead. Trick of the day: w3m -dump https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-18 | xclip -selection clipboard ...dumps a web page straight into your clipboard for pasting into an email client. -- Michael Attendees • Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Yao Qi yao.qi(a)linaro.org yao Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Peter Maydell peter.maydell(a)linaro.org pm215 Julian Brown julian(a)codesourcery.com jbrown Loïc Minier loic.minier(a)linaro.org lool Michael Hope michael.hope(a)linaro.org michaelh Chung-Lin Tang cltang(a)codesourcery.com cltang Agenda • Standup meeting Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting Action Items from Previous Meeting • DONE: Michael to think about synchronising Linaro releases with upstream • DONE: Michael to organise a call with Matthias, Loic to continue the topic • DONE: Michael to write up and email patch tracker mechanics for review • DONE: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • ACTION: Andrew to look into frequent runs of CSL benchmarks • ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement Minutes • Michael □ Continuing on patch tracking □ Continuing investigating string routines □ Julican noted that using NEON adds power usage and adds a context switch cost • Andrew □ Has a few patches left to go □ The ones left are a bit curlier □ Reviewing the upstream state of the current patches □ Will be sending the Cortex-A5 work upstream • Yao □ is continuing with the GDB bug fixes □ Most are caused by the testsuite □ Michael noted that we want to make any work we do available early. If landing on trunk, either backport to 7.2 or note for later pulling into our branch • Ulrich □ Working on bugs such as: ☆ Tracking thumb bit on a long jump ☆ Tracing in the kernel stubs □ Is currently working upstream □ Mentioned the ICACHE flush problem seen on Michael's board ☆ ACTION: Michael will try to upgrade the kernel from Angstrom 2.6.32 to a Linaro kernel • Peter □ Continues on virtio and QEMU □ Network benchmark currently shows virtio performing worse than emulated □ Looking upstream to see if this problem exists □ Still waiting on approval to release work. Richard will take care of next week • Chung-Lin □ Starting on hard vs soft FP performance tests □ Testing on a i.MX51 board □ Michael wants Chung-Lin to finish up on libffi soon • Julian □ Working on a vector conditions patch □ Currently seeing a segfault in compiled applications □ ACTION: Michael will re-try the build failures that Julian saw by the end of this week Next meeting is a stand-up meeting on 2010-08-20 on the public code.

15 years, 8 months

1
0
0 0

Patch Tracking Use Cases

by Andrew Stubbs

The patch tracking conversation has got a little out-of-hand, and I know I've misunderstood some of the features Michael has been proposing, and I suspect vice versa. So, here's my attempt to compare and contrast the various advantages, disadvantages, and differences of the ideas so far, by means of use cases. Looking at this, I think we can probably come up with a solution that uses the good bits from each (maybe method 1 with the milestone/status policy from method 2, for example). Please read the below, and let me know if I left anything out, or if I misunderstood something. Andrew ==== For the purposes of this document: * Method 0 is my original patch tracker, here: https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.5UpstreamPatches * Method 1 is Michael's proposed patch tracker, here: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%201 and here: http://ex.seabright.co.nz/helpers/patchtrack * Method 2 is my proposed system, here: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%202 --------------------------------------------------------- 1. What does a user have to do to get a patch tracked? Method 0: Nothing. New rows are added to the wiki page regularly by a script and cron-job. Method 1: Nothing. The tracking report is updated regularly. Method 2: Nothing. New tickets are created automatically, regularly. ------------------------------------------------------------ 2. How to find tracking information for a revision? Method 0: Search the wiki page for the revision number. Method 1: Goto the report page, click through to all the various associated tickets, if any. Method 2: Go to launchpad, and search for "r123456", or select it from the list in the relevant gcc-linaro-tracking milestone. ------------------------------------------------------------ 3. How to find tracking information for a bug fix? Method 0: Search the wiki page for the bug number - hopefully somebody has posted a link. Alternatively, the first line of the commit message will be present. If that doesn't work, then find the revision number by other means (bzr). Method 1: Go to the bug ticket - it should be there, or a link to another bug that has it. Alternatively, go to the tracker report page, and search for the commit message. If that fails try to identify the revision number by other means (bzr) Method 2: Go to the bug ticket - if the bug was committed with --fixes, there will be a link to the tracking ticket. Alternatively, search gcc-linaro-tracking to find the commit message. If that fails try to identify the revision number by other means (bzr) ---------------------------------------------------------- 4. How to add new tracking information? Method 0: Edit the wiki page. Method 1: Add the new information to one or all of the associated bugs, if any. If there are no existing tickets, create a new ticket (using the link on the tracker report) and put the information there. Method 2: Add the information to the ticket. ----------------------------------------------------------- 5. How to indicate that the bug is upstream? Method 0: Edit the wiki page, set the bgcolor to green. Method 1: Assign all the bug tickets to a gcc-linaro-tracking milestone. Method 2: Mark the bug "Fix committed". Ensure that the ticket has the correct milestone. ------------------------------------------------------------ 6. How to list all patches that need to go upstream? Method 0: View the wiki page - the patches are highlighted in red and yellow. Method 1: View the tracker report - the patches are highlighted in red, yellow, and orange. (Note that launchpad will only list the patches that already had a ticket attached, or else somebody has create one. This will usually only include patches where somebody had something to say about it.) Method 2: All open bugs in gcc-linaro-tracking. ------------------------------------------------------------- 7. How to list all patches that need forwarding on rebase from 4.5 to 4.6? Method 0: Any patches marked in red or yellow on the wiki page need forwarding. Any patches marked in green with an upstream landing number of 4.7 or higher also need forwarding. (This information is not yet encoded in the page, but it's a wiki, so flexibility is not a problem.) Any patches in grey also need considering. Some are uninteresting version bumps and such. Some are patches we plan to carry forever. Probably a new colour could be used to make this clearer - it's a wiki. Method 1: Any patches in the report not yet upstream need forwarding. Any patches in launchpad against the 4.7 milestone (or higher) also need forwarding. Any patches in the "never" milestone also need considering. Some might be ancient patches we used to carry in 4.4, but have since been dropped. Some will be patches we intend to carry. Method 2: All patches against the 4.7 milestone, both open and closed (modify the launchpad search criteria) need forwarding. All patches in the "series:never,milestone:4.5" milestone in the "won't fix" state need forwarding. (Patches we don't intend to carry forward will be "closed", and patches from 4.4 won't be in "series:never,milestone:4.5", so we never have to worry about those.) ------------------------------------------------------------------ 8. How to we track what patches have been forwarded on rebase already? Method 0: It's a wiki, add a column. Method 1: Committing the patch on a new branch will (with --fixes) will cause launchpad to list the commit on the bug page. There's no way to query this though. Method 2: Committing the patch on a new branch will give a "new" patch to track. The trackerbot will create a new ticket for this revision. The old ticket will be marked as a "duplicate" of the new one (manually, or automatically). The new bugs will have "4.6/r123456" in the subject line, so can be easily be differentiated. ----------------------------------------------------------------- 9. What else needs doing on a rebase? Method 0: Create a new page with a new table. Forward the information from the old table manually, by editing the wiki. Method 1: Create a new tracker report. Method 2: Set up the trackerbot on the new branch. ------------------------------------------------------------------ 10. What prompts users to use the system? Method 0: Nothing. (Management nagging.) Method 1: Nothing mentioned so far. Method 2: The bug is always assigned to somebody. They'll be notified by email, and it will show up on their launchpad pages. ------------------------------------------------------------------ 11. What happens when a bug produces multiple patches? Method 0: Multiple lines in the table, initially. But, it's a wiki, so they can be edited, moved around, and coalesced as required. Method 1: The same bug has to track multiple patches. ????? How does that work with the 'affects gcc-linaro-tracking' lines? Method 2: One ticket per commit. Each is tracked separately, but the user is free to mark each ticket as a duplicate of the other, and/or move the data from one ticket to another. ------------------------------------------------------------------ 12. What happens when one commit fixes multiple bugs? Method 0: Nothing special. Method 1: Multiple bugs will track the same submission process. Either the user must post all the data to all the bugs, or one bug must get (manually) appointed the master bug, and the others have links posted. Method 2: One ticket will be created to track the patch. The ticket will contain links to all the bugs, and each bug will contain a back-link. This is very little different to the normal case.

15 years, 8 months

1
0
0 0

Patch tracking method

by Michael Hope

I've fleshed out a potential way of tracking patches at: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%201 It's not too bad if you're a developer. The extra steps are: * Create a ticket * Mark that ticket as affecting upstream * Change the status as the patch evolves * Mark where the patch lands when finished This is all done through Launchpad's existing interface. Thoughts? -- Michael

15 years, 8 months

3
9
0 0

Re: [Bug 620229] [NEW] [4.5:r99360] Code hoisting improvements

by Michael Hope

Sorry about these. Hopefully I'm done. On Thu, Aug 19, 2010 at 2:28 PM, Michael Hope <620229(a)bugs.launchpad.net> wrote: > Public bug reported: > > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > ** Affects: gcc-linaro > Importance: Undecided > Status: New > > ** Affects: gcc-linaro/4.5 > Importance: Undecided > Status: New > > > ** Tags: revision > > -- > [4.5:r99360] Code hoisting improvements > https://bugs.launchpad.net/bugs/620229 > You received this bug notification because you are a direct subscriber > of the bug. > > Status in Linaro GCC: New > Status in Linaro GCC 4.5 series: New > > Bug description: > Related: lp:gcc-linaro/4.5,revno=99360 > > Code hoisting improvements > > Merged from SourceryG++ > > (Backport from FSF) > > > To unsubscribe from this bug, go to: > https://bugs.launchpad.net/gcc-linaro/+bug/620229/+subscribe >

15 years, 8 months

1
0
0 0

Dhrystone

by Michael Hope

I know that Dhrystone isn't a very good benchmark, but it's still interesting: https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/Dhrystone If we can get twice the performance out of strcpy() and memcpy() then the Dhrystone result should go up by almost 30 %. It would make a nice headline at least :) -- Michael

15 years, 8 months

2
1
0 0

Toolchain WG - 2010-08-17 meeting minutes

by Michael Hope

...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-16 Activity reports are included below. -- Michael Attendees Name Email IRC Nick Andrew Stubbs andrew.stubbs(a)linaro.org ams Julian Brown julian(a)codesourcery.com jbrown Loïc Minier loic.minier(a)linaro.org lool Matt Gretton-Dann ARM Matthias Klose doko(a)canonical.com doko Michael Hope michael.hope(a)linaro.org michaelh Peter Maydell peter.maydell(a)linaro.org pm215 Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Yao Qi yao.qi(a)linaro.org yao Agenda • Benchmarks □ ffmpeg (h.264), libmad (mp3), LAPACK, CoreMark, Dhrystone, and memcpy() □ EEMBC □ Methods of benchmarking • Patch tracking □ Minimum features □ Discovering upstream patches to backport □ Example version at http://ex.seabright.co.nz/helpers/patchtrack □ Ticket view at http://ex.seabright.co.nz/helpers/tickets • Upstream tracking □ Ubuntu tracks release+SVN. What should we do? • memcpy() and friends □ https://wiki.linaro.org/WorkingGroups/ToolChain/StringRoutines □ Copyright issues with EGLIBC • Hardware status • Creating blueprints • Connecting with other groups • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 Action Items from this Meeting • ACTION: Michael to think about synchronising Linaro releases with upstream • ACTION: Michael to organise a call with Matthias, Loic to continue the topic • ACTION: Michael to write up and email patch tracker mechanics for review • ACTION: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • ACTION: Andrew to look into frequent runs of CSL benchmarks • ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement Action Items from Previous Meeting • DONE: Richard to ask the GCC developers on IRC what the status of 4.4.5 is □ Matthias talked with Jacob and they expect a release at the end of August • DONE: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17 • DONE: Ulrich to ticket GDB items • DONE: Michael to understand whiteboards as a way of organising features Minutes Upstream patches: • Loic, Matthias, and Michael discussed tracking the upstream release branch • Upstream has a roughly three week cycle on patch releases • Matthias tracks this release branch and pulls in SVN as a patch into Ubuntu • Michael is concerned about the extra work, pulling a partial □ feature, catching a regression, fallout due to releasing something that upstream hasn't released, • Release branches are very stable. Chance of a regression is low • Better chance of getting a problem fixed upstream if caught early before the release • Loic: harder to track upstream • Loic: also harder to identify a Linaro release - FSF-4.4.4+svr12345+bzr6789... • Matthias spoke with Jacob in GCC. They expect a release at the end of □ August • Michael prefers basing on released versions only • Michael also wants to be able to reproduce any issues found in Ubuntu. Hard at the □ moment as Ubuntu runs Linaro plus a reasonably large set of patches ts to be able • One approach: merge the day after the Linaro release. Gives the maximum time for □ testing. Still a month behind, still have Ubuntu GCC != Linaro GCC • Matthias □ Would continue to keep diff between Linaro and upstream □ Is doing changes upstream □ Would have to maintain those separately □ If there are release critical changes, would have to do them himself • Discussed different phase of Linaro GCC vs Ubuntu - the releases won't be in sync so there will always be a need for release critical fixes in Ubuntu • ACTION: Michael to think about synchronising Linaro releases with upstream □ Drift the Linaro release to be a week later than the upstream release • Andrew wasn't concerned. Noted that the release branches are really good • ACTION: Michael to organise a call with Matthias, Loic to continue the topic Patch tracking: • Cortex-A5 changes are coming into Linaro • Michael did a quick show and tell on the patch tracker hack • ACTION: Michael to write up and email patch tracker mechanics for review Other topics: • Ulrich is out on vacation next week • ACTION: Ulrich to add his time away to the Linaro calendar • ACTION: Michael and Ulrich to add GDB new features as blueprints to Launchpad • Michael noted that we use bzr for version control wherever possible, including for QEMU • Michael asked Andrew if we could start regular runs of the commonly used benchmark • ACTION: Andrew to look into frequent runs of CSL benchmarks • String routines □ Michael talked with upstream and they greatly prefer FSF+LGPL □ ACTION: Michael to make sure Linaro has a FSF copyright assignment agreement • Loic mentioned Valgrind patches □ Peter is interested in helping Next meeting is a stand-up meeting on 2010-18-11 on the public code. -- Julian Brown == GCC 4.5 bugs in Launchpad == * Attempted to reproduce bugs against Linaro GCC 4.5 in Launchpad: issues #614184, #614185 and #614186. The last of these has been closed as invalid by the submitter already, and the first two don't seem to reproduce using a cross-compiler (i.e. using CS's build machinery), nor with a natively-bootstrapped bzr head build (as of some day last week). So, no real progress there. == GCC 4.5 vectorization improvements == * Started tracking down the causes of some failures in vect.exp: pr43430-1.c failed because of missing vector comparison support. This seemed relatively straightforward to implement using NEON instructions, so I had a go at doing that. Similarly another test fails (vect-35.c) because of missing support for widening/narrowing patterns, though I'm still investigating a fix for that. -- Andrew Stubbs == Linaro GCC releases == * Merged GCC 4.5.1 into the Linaro sources. * Respun the 4.5-2010.08 release. == Linaro GCC 4.5 == * Continued pushing SG++ patches into Linaro. I'm now most of the way through these, but I had hoped to have had it done by now. == Other == * Lost a few hours to internet outages. An engineer came out and changed all the connections, so hopefully that's solved the problem. It seems the recent bad weather had got into the underground cables between here and the street cabinet. It's fibre from there, so in theory it must be local. * Took Wednesday as vacation. -- Peter Maydell Subject: [weekly][linaro] report week 32 RAG: Red: None Amber: ARM legal OK for qemu contributions Green: booted versatile+virtio kernel on qemu Milestones: none as yet Progress: virtio-system: - identified which qemu patches give a qemu which can boot linaro alpha-3 on beagle emulation - built a kernel for 'versatile' flavour with virtio support - found some patches from qemu upstream which are needed for newer versatile kernels to boot - got my versatile kernel running on qemu with the linaro rootfs mounted via virtio - put various qemu changes/patches into a git tree, so (a) I know what I changed and (b) as an exercise in learning git Issues: none Plans: virtio-system: - get versatile to boot *without* virtio for comparison - find an io benchmark and do some benchmarking qemu-focused-kernel: - flesh out this blueprint Absences: None planned. -- Chung-Lin Tang == libffi VFP hard-float support == Testsuite fixes and final tuning before submitting. Had to port some stuff from the GCC testsuite to let libffi's testsuite support a dg-skip-if option, to skip some variadic function tests based on compiler options (skip when -mfloat-abi=hard), and I am not a DejaGNU/expect/Tcl expert...:P Whole patch was submitted to main libffi mailing list on Sunday, waiting for feedback. (see http://sourceware.org/ml/libffi-discuss/2010/msg00153.html) == This week == * See if any feedback on libffi patch. * Start Linaro 4.5 EEMBC comparisons. * Catch up on GCC work. -- Yao Qi == Linaro GCC == * Pinged ARM backend maintainer for my patch to GCC PR45094. Still no response. * Submit my patch on ARM target triplet in gcc-patches. With Dan's help, got GCC write access. Checked in my patch. * Update status of LP bugs. Mark them as Fix Released since failures go away in gcc-linaro-4.4-2010.08-0. == Linaro GDB == * Search something about GDB from my brain, like gdb test, tcl/expect, ptrace/breakpointetc. Fortunately, most of them are still there. :) * LP:615997 gdb.dwarf2/dw2-ref-missing-frame.exp failure Failure is caused by alignment of test case. Sent a patch to gdb-patches, and revise it with Dan's help. * LP:615989 gdb.base/pending.exp Failure is caused by wrong code in .debug_line. Failure goes away when it is compiled by gcc-linaro-4.5-2010.08-1. Open a gcc bug LP:617384. * LP:615995 gdb.base/watch-vfork.exp : Watchpoint triggers after vfork (sw) (timeout) Reproduce it on x86. GDB is waiting endlessly between TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORK_DONE. Looks like child of debuggee hangs on 'signal'. == This Week == * Look into LP:615995 deeply, and other linaro gdb bugs.

15 years, 8 months

3
4
0 0

apr/eglibc issue with shared mutexes

by Loïc Minier

Hi I'm concerned that the workaround for apr was just uploaded in the form of disabling process shared mutexes (see LP #599874), but we didn't address or investigate the root cause in eglibc. Would someone be able to look at LP #604753 where the issue is tracked? Thanks! -- Loïc Minier

15 years, 8 months

1
0
0 0

2010-08-16 Agenda

by Michael Hope

...is available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-16 -- Michael Agenda • Benchmarks □ ffmpeg (h.264), libmad (mp3), LAPACK, CoreMark, Dhrystone, and memcpy() □ EEMBC □ Methods of benchmarking • Patch tracking □ Minimum features □ Discovering upstream patches to backport □ Example version at http://ex.seabright.co.nz/helpers/patchtrack □ Ticket view at http://ex.seabright.co.nz/helpers/tickets • Upstream tracking □ Ubuntu tracks release+SVN. What should we do? • memcpy() and friends □ https://wiki.linaro.org/WorkingGroups/ToolChain/StringRoutines □ Copyright issues with EGLIBC • Hardware status • Creating blueprints • Connecting with other groups • Open tickets □ 616141 Backport the sync_* primitive fixes □ 590696 fix wrong use of objdump during cross build □ 600277 Backport ARM Cortex A9 scheduling changes □ 605059 Merge 4.4.5 Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • TBD Action Items from Previous Meeting • ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is • ACTION: Andrew to merge 4.5.1 and the Firefox fix by 2010-08-17 • ACTION: Ulrich to ticket GDB items • ACTION: Michael to understand whiteboards as a way of organising features

15 years, 8 months

1
0
0 0

Toolchain WG - 2010-08-12 Standup notes

by Michael Hope

...are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-11 -- Michael Attendees • Name Email IRC Nick Yao Qi yao.qi(a)linaro.org yao Ulrich Weigand ulrich.weigand(a)linaro.org uweigand Richard Earnshaw richard.earnshaw(a)arm.com rearnshaw Peter Maydell peter.maydell(a)linaro.org pm215 Michael Hope michael.hope(a)linaro.org michaelh Julian Brown julian(a)codesourcery.com jbrown Chung-Lin Tang cltang(a)codesourcery.com cltang Agenda • Stand up call Blueprint Assignee Initial delivery of Linaro GCC 4.4 ams Cross Compiler Packages hrw Action Items from this Meeting • ACTION: Michael to email his configure options to Julian • ACTION: Richard, if he's going, will set up Action Items from Previous Meeting Minutes • Julian □ Continues to merge 4.4 into the CSL 4.5 branch □ Andrew is pushing changes out to the Linaro branch □ Can't reproduce some failures □ ACTION: Michael to email his configure options to Julian • Ulrich □ Has been ticketing the GDB features and faults for him and Yao to work on • Yao □ GCC patch has been approved upstream □ Going through the GDB tickets • Chung-Lin □ Doing some last optimisations □ Preparing to send the patch upstream • Peter □ Looking into virtio □ Amit has been working on similar □ Michael suggests getting on IRC and asking □ Almost has approval to work publicly • Richard □ Issues were found with the sync fixes. These are being reworked • Michael □ Looked at benchmarks and string routines □ Want the group to start pulling the A9 changes down □ And other A9 pipeline changes □ Richard suggests pulling Marcus's 4.4 sync primitives fix in too • GCC Summit □ Overlaps with UDS □ Ulrich suggests a BoF session on the ARM toolchain □ ACTION: Richard, if he's going, will set up □ Not enough material for a paper at the moment The next meeting is the stand up call on Friday.

15 years, 8 months

2
1
0 0

should linaro-toolchain be listed on GettingInvolved?

by Peter Maydell

I wanted to point somebody at this mailing list (linaro-toolchain), and I noticed that it wasn't listed here: https://wiki.linaro.org/GettingInvolved which is the first place I tried. Is that deliberate, or just an oversight? thanks -- Peter Maydell

15 years, 8 months

2
1
0 0

2010-08-09 Agenda

by Michael Hope

The agenda for today's meeting is available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-09 Note the new conference code. # Review action items from last meeting # New public call-in number: code 263 441 7169 # Release status 4.4 at http://ex.seabright.co.nz/build/gcc-linaro-4.4-2010.08-0/ 4.5 at http://ex.seabright.co.nz/build/gcc-linaro-4.5-2010.08-0/ Ubuntu toolchain would prefer 4.5.1 # Next focus * Merging patches upstream * Prioritising GDB features # Future focus * Emphasise performance, neutral on correctness * Topics to investigate o Vectoriser o Pipeline o PGO o Upstream research topics * Topics for UDS * Benchmarks -- Michael

15 years, 8 months

2
1
0 0

GDB features and bugfixes

by Ulrich Weigand

Hi Michael, here's a list of features and bugfixes that can serve as a basis for Monday's discussion on what we should be working on in GDB in the future. The goal of the list is to fix currently known problems with GDB, including the testsuite, as well as bringing GDB on ARM in line with other platforms by adding required back-end support to enable common GDB features that are already supported elsewhere. It does not yet include anything completely new that we'd develop specifically for ARM. If anybody knows of a feature or bugfix I've missed, please let me know! Features/fixes involving kernel support: - hardware watchpoint support - Neon registers in core files - Interrupted syscall handling - PTRACE_ATTACH disabled ? Features/fixes involving GCC support: - backtrace from abort (missing LR save) - debug info for args in varargs routine GDB features/fixes: - prologue parsing on Thumb-2 - displaced stepping on Thumb - syscall tracing support - improved epilogue detection (fix software watchpoints) - multi-threaded debugging inferior crashes - multi-threaded Thumb/ARM state tracking - signal handler stepping - inferior call fixes - misc. other testsuite regressions gdbserver features/fixes - Neon register support - fast tracepoints Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 8 months

2
2
0 0

Toolchain WG - 2010-08-07 Standup notes

by Michael Hope

= Friday 7th August 2010 = == This month's meetings == <<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,08,,,,WorkingGroups/ToolChain/MeetingTemplate)>> == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Chung-Lin Tang || cltang(a)codesourcery.com || cltang || || Julian Brown || julian(a)codesourcery.com || jbrown || || Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw || || Michael Hope || michael.hope(a)linaro.org || michaelh || || Peter Maydell || peter.maydell(a)linaro.org || pm215 || || Richard Earnshaw || richard.earnshaw(a)arm.com || rearnshaw || || Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand || || Yao Qi || yao.qi(a)linaro.org || yao || == Agenda == * Stand up meeting == Action Items from this Meeting == == Action Items from Previous Meeting == == Minutes == * Andrew: * Continues to push the 4.5 patches * Seen one regression so far which he is investigating * Continues to approve 4.4 merge requests * Spinning 2010.08 release today * Will give tarball to michaelh to also build * Yao: * Continuing on bug fixes and merges * [[LP:602174]]: Problem has gone away, to confirm on release * [[LP:602288]]: Leave test in-place. Change was backed out * [[LP:602190]]: will set options in test case * Ulrich: * Investigating test failures * getfem++ failure is triggered in wrapped library * May be due to a different environment * Will investigate further * Richard: * Cortex-A9 patches sent upstream (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00481.html) * `__sync` primitive patches sent upstream (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00492.html) * Peter * Introduced himself * Julian: * Porting patches from 4.4 to the 4.5 CSL branch is ongoing * Continuing with the misalignment patch issues * Looking into failures on the 4.5 CSL branch * Michael asked Julian to look at the 4.5 tests on Linaro as well * Marcin: * All stages of the cross compiler are done * Sent a link to the PPA over IRC * Mentioned that configure objcopy issue. Michael says that the TCWG will take it over * Vacation is coming up in about a week * Chung-Lin: * Now running the libffi test suite * Four regressions so far * Andrew is organising access to the benchmark suite * Michael: do want to be able to reproduce these results in the future. Please record everything needed to reproduce (compiler, host, environment, scripts, etc.) * Michael: * Extending the builds further. Added eglibc. * Thinking about what's next * Discuss on Monday

15 years, 9 months

1
0
0 0

Conference code for Monday

by Michael Hope

Monday's call will be on conference code 263 441 7169. The dial-in numbers are the usual Canonical numbers listed here: https://docs.google.com/Doc?id=af8g8fcnf79_498dfz9v9fv -- Michael

15 years, 9 months

1
0
0 0

LP:602190 & LP:602285

by Yao Qi

LP:602190(https://bugs.launchpad.net/gcc-linaro/+bug/602190) and LP:602285(https://bugs.launchpad.net/gcc-linaro/+bug/602285) are related to this patch below. You can get more details from comments of these bugs, since I've added my understand of the cause in comments. This patch is to improve the performance of generated code, however, these two bugs are related to this patch(, correct me if I am wrong). Now, we have two options, 1) revert this patch, and make these test case pass; 2) keep this patch and fix test cases, 3) fix bugs and keep this patch, What do you think? 2009-08-26 Daniel Jacobowitz <dan(a)codesourcery.com> Issue #6131 - Enable additional optimizations by default in Lite Issue #6103 - Reduce default unrolling parameters at -O3 * release-notes-csl.xml (Improved optimization for ARM): New note. gcc/ * config/arm/arm.c (arm_override_options): If flag_unroll_loops has the default value, adjust unrolling parameters. (arm_optimization_options): Set flag_unroll_loops to a default value. Enable flag_promote_loop_indices. Modified: gcc/config/arm/arm.c ============================================================================== --- gcc/config/arm/arm.c (original) +++ gcc/config/arm/arm.c Fri Aug 28 14:41:19 2009 @@ -55,6 +55,7 @@ #include "langhooks.h" #include "df.h" #include "intl.h" +#include "params.h" /* Forward definitions of types. */ typedef struct minipool_node Mnode; @@ -1857,6 +1858,29 @@ warning (0, "-low-irq-latency has no effect when compiling for the Thumb"); low_irq_latency = 0; + } + + /* CSL LOCAL */ + /* Loop unrolling can be a substantial win. At -O2, limit to 2x + unrolling by default to prevent excessive code growth; at -O3, + limit to 4x unrolling by default. We know we are not optimizing + for size if this is set (see arm_optimization_options). */ + if (flag_unroll_loops == 2) + { + if (optimize == 2) + { + flag_unroll_loops = 1; + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES)) + set_param_value ("max-unroll-times", 2); + } + else if (optimize > 2) + { + flag_unroll_loops = 1; + if (!PARAM_SET_P (PARAM_MAX_UNROLL_TIMES)) + set_param_value ("max-unroll-times", 4); + } + else + flag_unroll_loops = 0; } } @@ -21175,6 +21199,17 @@ set_param_value ("max-inline-insns-single", 1); set_param_value ("max-inline-insns-auto", 1); } + else + { + /* CSL LOCAL */ + /* Set flag_unroll_loops to a default value, so that we can tell + if it was specified on the command line; see + arm_override_options. */ + flag_unroll_loops = 2; + /* Promote loop indices to int where possible. Consider moving this + to -Os, also. */ + flag_promote_loop_indices = 1; + } } -- Yao Qi CodeSourcery yao(a)codesourcery.com (650) 331-3385 x739

15 years, 9 months

3
4
0 0

Initial QEMU work

by Michael Hope

Hi Peter. Further to our call yesterday, I've created four blueprints that cover the initial QEMU work: https://blueprints.launchpad.net/qemu-linaro virtio-system and qemu-focused-kernel should be done first, but you might as well start looking at merge-other-branches in the background. I haven't gone into great detail - feel free to flesh out the blueprints as you go, and don't hesitate to ask if you need more information. -- Michael

15 years, 9 months

1
0
0 0

Multiarch paths and toolchain implications

by Ulrich Weigand

Hi Wookey, I've finally completed a first of draft the write-up of toolchain implications of multiarch paths that we discussed in Prague. Sorry it took a while, but it got a lot longer than I expected :-/ I'd appreciate any feedback and comments! Multiarch paths and toolchain implications == Overview and goals == Binary files in packages are usually platform-specific, that is they work only on the architecture they were built for. Therefore, the packaging system provides platform-specific versions for them. Currently, these versions will install platform-specific files to the same file system locations, which implies that only one of them can be installed into a system at the same time. The goal of the "multiarch" effort is to lift this limitation, and allow multiple platform-specific versions of the same package to be installed into the same file system at the same time. In addition, each package should install to the same file system locations no matter on which host architecture the installation is performed (that is, no rewriting of path names during installation). This approach could solve a number of existing situations that are not handled well by today's packaging mechanisms: - Systems able to run binaries of more than one ISA natively. - Support for multiple incompatible ABI variants on the same ISA. - Support for processor-optimized ABI-compatible library variants. - NFS file system images exported to hosts of different architectures. - Target file systems for ISA emulators etc. - Development packages for cross-compilation. In order to support this, platform-specific versions of a multiarch package must have the property that for each file, it is either 100% identical across platforms, or else it must be installed to separate locations in the file system. The latter is the case at least for executable files, shared libraries, static libraries and object files, and to some extent maybe header files. This means that in a multiarch world, such files must move to different locations in the file system than they are now. This causes a variety of issues to be solved; in particular, most of the existing locations are defined by the LHS and/or are assumed to have well-known values by various system tools. In this document, I want to focus on the impact of file system hierarchy changes to two tasks in particular: - loading/running an executable - building an executable from source In the following two sections, I'll provide details on file system paths are currently handled in these two areas. In the final section, I'll discuss suggestions how to extend the current behavior to support multiarch paths. == Loading/running an executable == Running a new executable starts with the execve () system call. The Linux kernel supports execution of a variety of executable types; most commonly used are - native ELF executable - ELF exectuable for a secondary native ISA (32-bit on 64-bit) - #! scripts - user-defined execution handlers (via binfmt_misc) The binary itself is passed via full (or relative) pathname to the execve call; the kernel does not make file system hierarchy assuptions. By convention, callers of execve ususally search well-known path locations (via the PATH environment variable) when locating executables. How to adapt these conventions for multiarch is beyond the scope of this document. With #! scripts and binfmt_misc handlers, the kernel will involve a user-space helper to start execution. The location of these handlers themselves and secondary files they in turn may require is provided by user space (e.g. in the #! line, or in the parameters installed into the binfmt_misc file system). Again, adapting these path names is beyond the scope of this document. For native ELF executables, there are two additional classes of files involved in the initial load process: the ELF interpreter (dynamic loader), and shared libraries required by the executable. The ELF interpreter name is provided in the PT_INTERP program header of the ELF executable to be loaded; the kernel makes no file name assumptions here. This program header is generated by the linker when performing final link of a dynamically linked executable; it uses the file name passed via the -dynamic-linker argument. (Note that while the linker will fall back to some hard-coded path if that argument is missing, on many Linux platforms this default is in fact incorrect and does not correspond to a ELF interpreter actually installed in the file system in current distributions. Passing a correct -dynamic-linker argument is therefore mandatory.) In normal builds, the -dynamic-linker switch is passed to the linker by the GCC compiler driver. This in turn gets the proper argument to be used on the target platform from the specs file; the (correct) default value is hard-coded into the GCC platform back-end sources. On bi-arch platforms, GCC will automatically choose the correct variant depending on compile options like -m32 or -m64. Again, the logic to do so is hard-coded into the back-end. Unfortunately, various bi-arch platforms use different schemes today: amd64: /lib/ld-linux.so.2 vs. /lib64/ld-linux-x86-64.so.2 ia64: /lib/ld-linux.so.2 vs. /lib/ld-linux-ia64.so.2 mips: /lib/ld.so.1 vs. /lib64/ld.so.1 ppc: /lib/ld.so.1 vs. /lib64/ld64.so.1 s390: /lib/ld.so.1 vs. /lib/ld64.so.1 sparc: /lib/ld-linux.so.2 vs. /lib64/ld-linux.so.2 Once the dynamic interpreter is loaded, it will go on and load dynamic libraries required by the executable. For this discussion, we will consider only the case where the interpreter is ld.so as provided by glibc. As opposed to the kernel, glibc does in fact *search* for libraries, and makes a variety of path name assumptions while doing so. It will consider paths encoded via -rpath, the LD_LIBRARY_PATH environment variable, and knows of certain hard-coded system library directories. It also provides a mechanism to automatically choose the best out of a number of libraries available on the system, depending on which capabilities the hardware / OS provides. Specifically, glibc determines a list of search directory prefixes, and a list of capability suffixes. The directory prefixes are: - any directory named in the (deprecated) DT_RPATH dynamic tag of the requesting object, or, recursively, any parent object (note that DT_RPATH is ignored if DT_RUNPATH is also present) - any directory listed in the LD_LIBRARY_PATH environment variable - any directory named in the DT_RUNPATH dynamic tag of the requesting object (only) - the system directories, which are on Linux hard-coded to: * /lib$(biarch_suffix) * /usr/lib$(biarch_suffix) where $(biarch_suffix) may be "64" on 64-bit bi-arch platforms. The capability suffixes are determined from the following list of capabilities: - For each hardware capability that is present on the hardware as indicated by a bit set in the AT_HWCAP auxillary vector entry, and is considered "important" according to glibc's hard-coded list of important hwcaps (platform-dependent), a well-known string provided by glibc's platform back-end. - For each "extra" hardware capability present on the hardware as indicated by a GNU NOTE section in the vDSO provided by the kernel, a string provided in that same note. - A string identifying the platform as a whole, as provided by the kernel via the AT_PLATFORM auxillary vector entry. - For each software capability supported by glibc and the kernel, a well-known string. The only such capability supported today is "tls", indicating support for thread-local storage. The full list of capability suffixes is created from the list of supported capabilities by forming every sub-sequence. For example, if the platform is "i686", supports the important hwcap "sse2" and TLS, the list of suffixes is: sse2/i686/tls sse2/i686 sse2 i686/tls i686 tls <empty> The total list of directories to be searched is then formed by concatenating every directory prefix with every capability suffix. Various caching mechanisms are employed to reduce the run-time overhead of this large search space. Note: This method of searching capability suffixes is employed only by glibc at run time; it is unknown to the toolchain at compile time. This implies that an executable will have been linked against the "base" version of a library, and the "capability-specific" version of the library is only substituted at run time. Therefore, all capability-specific versions must be ABI-compatible to the base version, in particular they must provide the same soname and symbol versions, and they must use compatible function calling conventions. == Building an executable from source == For this discussion, we only consider GCC and the GNU toolchain, installed into the usual locations as system toolchain, and in the absence of any special-purpose options (-B) or environment variables (GCC_EXEC_PREFIX, COMPILER_PATH, LIBRARY_PATH ...). However, we do consider the three typical modes of operation: - native compilation - cross-compilation using a "traditional" toolchain install - cross-compilation using a sysroot During the build process, the toolchain performs a number of searches for files. In particular, it looks for (executable) components of the toolchain itself; for include files; for startup object files; and for static and dynamic libraries. In doing so, the GNU toolchain considers locations derived from any of the following "roots": - Private GCC installation directories * /usr/lib/gcc * /usr/libexec/gcc These hold both GCC components and target-specific headers and libraries provided by GCC itself. - GNU toolchain installation directories * /usr/$(target) These directories hold files used across multiple components of the GNU toolchain, including the compiler and binutils. In addition, they may also hold target libraries and headers; in particular for libraries traditionally considered part of the toolchain, like newlib for embedded systems. In fact, in the "traditional" installation of a GNU cross-toolchain, *all* default target libraries and headers are found here. However, the toolchain directories are always consulted for native compilation as well (if present)! - The install "prefix" This is what is specified via the --prefix configure option. The toolchain will look for headers and libraries under that root, allowing for building and installing of multiple software packages that depend on each other into a shared prefix. (This is really only relevant when the toolchain is *not* installed as system toolchain, e.g. in a setup where you provide a GNU toolchain + separately built GNU packages on a non-GNU system in some distinct non-system directory.) - System directories * /lib$(biarch_suffix) * /usr/lib$(biarch_suffix) * /usr/local/lib$(biarch_suffix) * /usr/include * /usr/local/include These are default locations defined by the OS and hard-coded into the toolchain sources. The examples above are those used for Linux. On bi-arch platforms, $(biarch_suffix) may be the suffix "64". These directories are used only for native compilation; however in a "sysroot" cross-compiler, they are used for cross-compilation as well, prefixed by the sysroot directory. In addition to the base directory paths refered to above, the GNU toolchain supports the so-called "multilib" mechanism. This is intended to provide support for multiple incompatible ABIs on a single platform. This is implemented by the GCC back-end having hard-coded information about which compiler option causes an incompatible ABI change, and a hard-coded "multilib" directory suffix name corresponding to that option. For example, on PowerPC the -msoft-float option is associated with the multilib suffix "nof", which means libraries using the soft-float ABI (passing floating point values in integer registers) can be provided in directories like: /usr/lib/gcc/powerpc-linux/4.4.4/nof /usr/lib/nof The multilib suffix is appended to all directories searched for libraries by GCC and passed via -L options to the linker. The linker itself does not have any particular knowledge of multilibs, and will continue to consult its default search directories if a library is not found in the -L paths. If multiple orthogonal ABI-changing options are used in a single compilation, multiple multilib suffixes can be used in series. As a special consideration, some compiler options may correspond to multiple incompatible ABIs that are already supported by the OS, but using directory names differently from what GCC would use internally. As the typical example, on bi-arch systems the OS will normally provide the default 64-bit libraries in /usr/lib64, while also providing 32-bit libraries in /usr/lib. For GCC on the other side, 64-bit is the default (meaning no multilib suffix), while the -m32 option is associated with the multilib suffix "32". To solve this problem, the GCC back-end may provide a secondary OS multilib suffix which is used in place of the primary multilib suffix for all library directories derived from *system* paths as opposed to GCC paths. For example, in the typical bi-arch setup, the -m32 option is associated with the OS multilib suffix "../lib". Given the that primary system library directory is /usr/lib64 on such systems, this has the effect of causing the toolchain to search /usr/lib64/gcc/powerpc64-linux/4.4.4 /usr/lib64 for default compilations, and /usr/lib64/gcc/powerpc64-linux/4.4.4/32 /usr/lib64/../lib (i.e. /usr/lib) for -m32 compilations. The following rules specify in detail which directories are searched at which phase of compilation. The following parameters are used: $(target) GNU target triple (as specified at configure time) $(version) GCC version number $(prefix) Determined at configure time, usually /usr or /usr/local $(libdir) Determined at configure time, usually $(prefix)/lib $(libexecdir) Determined at configure time, usually $(prefix)/libexec $(tooldir) GNU toolchain directory, usually $(prefix)/$(target) $(gcc_gxx_include_dir) Location of C++ header files. Determined at configure time: * If --with-gxx-include-dir is given, the specified directory * Otherwise, if --enable-version-specific-runtime-libs is given: $(libdir)/gcc/$(target)/$(version)/include/c++ * Otherwise for all cross-compilers (including with sysroot!): $(tooldir)/include/c++/$(version) * Otherwise for native compilers: $(prefix)/include/c++/$(version) $(multi) Multilib suffix appended for GCC include and library directories $(multi_os) OS multilib suffix appended for system library directories $(sysroot) Sysroot directory (empty for native compilers) Directories searched by the compiler driver for executables (cc1, as, ...): 1. GCC directories: $(libexecdir)/gcc/$(target)/$(version) $(libexecdir)/gcc/$(target) $(libdir)/gcc/$(target)/$(version) $(libdir)/gcc/$(target) 2. Toolchain directories: $(tooldir)/bin/$(target)/$(version) $(tooldir)/bin Directories searched by the compiler for include files: 1. G++ directories (when compiling C++ code only): $(gcc_gxx_include_dir) $(gcc_gxx_include_dir)/$(target)[/$(multi)] $(gcc_gxx_include_dir)/backward 2. Prefix directories (if distinct from system directories): [native only] $(prefix)/include 3. GCC directories: $(libdir)/gcc/$(target)/$(version)/include $(libdir)/gcc/$(target)/$(version)/include-fixed 4. Toolchain directories: [cross only] $(tooldir)/sys-include $(tooldir)/include 5. System directories: [native/sysroot] $(sysroot)/usr/local/include [native/sysroot] $(sysroot)/usr/include Directories searched by the compiler driver for startup files (crt*.o): 1. GCC directories: $(libdir)/gcc/$(target)/$(version)[/$(multi)] 2. Toolchain directories: $(tooldir)/lib/$(target)/$(version)[/$(multi_os)] $(tooldir)/lib[/$(multi_os)] 3. Prefix directories: [native only] $(libdir)/$(target)/$(version)[/$(multi_os)] [native only] $(libdir)[/$(multi_os)] 4. System directories: [native/sysroot] $(sysroot)/lib/$(target)/$(version)[/$(multi_os)] [native/sysroot] $(sysroot)/lib[/$(multi_os)] [native/sysroot] $(sysroot)/usr/lib/$(target)/$(version)[/$(multi_os)] [native/sysroot] $(sysroot)/usr/lib[/$(multi_os)] Directories searched by the linker for libraries: In addition to these directories built-in to the linker, if the linker is invoked via the compiler driver, it will also search the same list of directories specified above for startup files, because those are implicitly passed in via -L options by the driver. Also, when searching for dependencies of shared libraries, the linker will attempt to mimic the search order used by the dynamic linker, including DT_RPATH/DT_RUNPATH and LD_LIBRARY_PATH lookups. 1. Prefix directories (if distinct from system directories): [native only] $(libdir)$(biarch_suffix) 2. Toolchain directories: [native/cross] $(tooldir)/lib$(biarch_suffix) 3. System directories: [native/sysroot] $(sysroot)/usr/local/lib$(biarch_suffix) [native/sysroot] $(sysroot)/usr/lib$(biarch_suffix) [native/sysroot] $(sysroot)/lib$(biarch_suffix) 4. Non-biarch directories (if distinct from the above) [native only] $(libdir) [native/cross] $(tooldir)/lib [native/sysroot] $(sysroot)/usr/local/lib [native/sysroot] $(sysroot)/usr/lib [native/sysroot] $(sysroot)/lib == Multiarch impact on the toolchain == The current multiarch proposal is to move the system library directories to a new path including the GNU target triplet, that is, instead of using /lib /usr/lib the system library directories are now called /lib/$(multiarch) /usr/lib/$(multiarch) At this point, there is no provision for multiarch executable or header file installation. What are the effects of this renaming on the toolchain, following the discussion above? * ELF interpreter The ELF interpreter would now reside in a new location, e.g. /lib/$(multiarch)/ld-linux.so.2 This allows interpreters for different architectures to be installed simultaneously, and removes the need for the various bi-arch hacks. Change would imply modification of the GCC back-end, and possibly the binutils ld default as well (even though that's currently not normally used), to build new executables using the new ELF interpreter install path. Caveats: Any executable built with the new ELF interpreter will absolutely not run on a system that does not provide the multiarch install location of the interpreter. (This is probably OK.) Executables built with the old ELF interpreter will not run on a system that *only* provides the multiarch install location. This is clearly *not* OK. To provide backwards compatibility, even a multiarch-capable system will need to install ELF interpreters at the old locations as well, possibly via symlinks. (Note that any given system can only be compatible in this way with *one* architecture, except for lucky circumstances.) As the multiarch string $(multiarch) is now embedded into each and every executable file, it becomes invariant part of the platform ABI, and needs to be strictly standardized. GNU target triplets as used today in general seem to provide too much flexibility and underspecified components to serve in such a role, at least without some additional requirements. * Shared library search paths According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string: * /lib/$(multiarch) * /usr/lib/$(multiarch) This requires modifications to glibc's ld.so loader (can possibly be provided via platform back-end changes). Backwards compatibility most likely requires that both the new multiarch location and the old location are searched. Open questions: + How are -rpath encoded paths to be handled? Option A: They are used by ld.so as-is. This implies that in a fully multiarch system, every *user* of -rpath needs to update their paths to include the multiarch target. Also, multiarch targets are once again directly embedded into exectuables. Option B: ld.so automatically appends the multiarch target string to the path as encoded in DT_RPATH/DT_RUNPATH. This may break backwards compatibility. Option C: ld.so searches both the -rpath as is, and also with multiarch target string appended. + How is LD_LIBRARY_PATH to be handled? The options here are basically analogous to the -rpath case. + What is the interaction between the multiarch string and capability suffixes (hwcaps etc.) supported by ld.so? The most straightforward option seems to be to just leave the capability mechanism unchanged, that is, ld.so would continue to append the capabitility suffixes to all directory search paths (which potentially already include a multiarch suffix). This implies that different ABI-compatible but capability-optimized versions of a library share the same multiarch prefix, but use different capability suffixes. * GCC and toolchain directory paths The core multiarch spec only refers to system directories. What about directories provided by GCC and the toolchain? Note that for a cross-development setup, we may have various combinations of host and target architectures. In this case $(host-multiarch) refers to the multiarch identifier for the host architecture, while $(target-multiarch) refers to the one for the target architecture. In addition $(target) refers to the GNU target triplet as currently used by GCC paths (which may or may not be equal to $(target-multiarch), depending on how the latter will end up being standardized). + GCC private directories The GCC default installation already distinguishes files that are independent of the host architecture (in /usr/lib/gcc) from those that are dependent on the host architecture (in /usr/libexec/gcc). In both cases, the target architecture is already explicitly encoded in the path namess. Thus it would appear that we'd simply have to move the libexec paths to include the multiarch string in a straightforward manner in order: /usr/lib/gcc/$(target)/$(version)/... /usr/libexec/$(host-multiarch)/gcc/$(target)/$(version)/... This assumes that two cross-compilers to the same target running on different hosts can share /usr/lib/gcc, which may not be fully possible (because two cross-compilers may build slightly different versions of target libraries due to optimization differences). In this case, the whole of /usr/lib/gcc could be moved to multiarch as well: /usr/lib/$(host-multiarch)/gcc/$(target)/$(version)/... /usr/libexec/$(host-multiarch)/gcc/$(target)/$(version)/... The alternative would be to package them separately, with the host independent files always coming from the same package (presumbly itself produced on a native system, or else one "master" host system). Note that if -in the first stage of multiarch- we do not support parallel installation of *binaries*, we may not need to do anything for the GCC directories. + Toolchain directories The /usr/$(target) directory used by various toolchain components is somewhat of a mixture of target vs. host dependent files: /usr/$(target)/bin executable files in host architecture, targeting target architecture (e.g. cross-assembler, cross-linker binaries) /usr/$(target)/sys-include target headers (only for cross-builds) /usr/$(target)/include native toolchain header files for target (like bfd.h) /usr/$(target)/lib target libraries + native toolchain libraries for target (like libbfd.a) /usr/$(target)/lib/ldscripts linker scripts used by the cross-linker In a full multiarch setup, the only directory that would require the multiarch suffix is probably bin: /usr/$(target)/bin/$(host-multiarch) As discussed above, if we want to support different versions of target libraries for the same target, as compiled with differently hosted cross-compilers, we might also have to multiarch the lib directory: /usr/$(target)/lib/$(host-multiarch) Yet another option might be to require multiarch systems to always use the sysroot cross-compile option, and not support the toolchain directory for target libraries in the first place. [Or at least, have no distribution package ever install any target library into the toolchain lib directory ...] + System directories For these, the primary multiarch rules would apply. In a sysroot configuration, the sysroot prefix is applied as usual (after the multiarch paths have been determined as for a native system). Note that we need to apply the *target* multiarch string here; in case this is different from the target triplet, the toolchain would have to have explicit knowledge of those names: /lib/$(target-multiarch) /usr/lib/$(target-multiarch) + Prefix directories For completeness' sake, we need to define how prefix directories are handled in a GCC build that is both multiarch enabled *and* not installed into the system prefix. The most straightforward solution would be to apply multiarch suffixes to the prefix directories as well: $(prefix)/lib/$(target-multiarch) $(prefix)/include/$(target-multiarch) [ if include is multiarch'ed ... ] * Multiarch and cross-compilation Using the paths as discussed in the previous section, we have some options how to perform cross-compilation on a multiarch system. The most obvious option is to build a cross-compiler with sysroot equal to "/". This means that the compiler will use target libraries and header files as installed by unmodified distribution multiarch packages for the target architecture. This should ideally be the default cross-compilation setup on a multi-arch system. In addition, it is still possible to build cross-compilers with a different sysroot, which may be useful if you want to install target libraries you build yourself into a non-system directory (and do not want to require root access for doing so). Questions: + Should we still support "traditional" cross-compilation using the toolchain directory to hold target libraries/header This is probably no longer really useful. On the other hand, it probably doesn't really hurt either ... + What about header files in a multiarch system? The current multiarch spec does not provide for multiple locations for header files. This works only if headers are identical across all targets. This is usually true, and where it isn't, can be enforced by use of conditional compilation. In fact, the latter is how things currently work on traditional bi-arch distributions. In the alternative, the toolchain could also provide for multiarch'ed header directories along the lines of /usr/include/local/$(target-multiarch) /usr/include/$(target-multiarch) which are included in addition to (and before) the usual directories. It will most likely not be necessary to do this for the GCC and toolchain directory include paths, as they are already target-specific. * Multiarch and multilib The multilib mechanism provides a way to support multiple incompatible ABI versions on the same ISA. In a multiarch world, this is supposed to be handled by different multiarch prefixes, to enable use of the package management system to handle libraries for all those variants. How can we reconcile the two systems? It would appear that the way forward is based on the existing "OS multilib suffix" mechanism. GCC already expects to need to handle naming conventions provided by the OS for where incompatible versions are to found. In a multiarch system, the straightforward solution would appear to be to use the multiarch names as-is as OS multilib suffixes. In fact, this could even handle the *default* multiarch name without requiring any further changes to GCC. For example, in a bi-arch amd64 setup, the GCC back-end might register "x86_64-linux" as default OS multilib suffix, and "i386-linux" as OS multilib suffix triggered by the (ABI changing) -m32 option. Without any further change, GCC would now search /usr/lib/x86_64-linux or /usr/lib/i386-linux as appropriate, depending on the command line options used. (This assumes that the main libdir is /usr/lib, i.e. no bi-arch configure options were used.) Note that GCC would still use its own internal multilib suffixes for its private libraries, but that seems to be OK. Caveat: This would imply those multilib names, and their association with compiler options, becomes hard-coded in the GCC back-end. However, this seems to have already been necessary (see above). == Summary == >From the preceding discussion, it would appear a multiarch setup allowing parallel installation of run-time libraries and development packages, and thus providing support for running binaries of different native ISAs and ABI variants as well as cross-compilation, might be feasible by implementing the following set of changes. Note that parallel installation of main *executable* files by multiarch packages is not (yet) supported. * Define well-known multiarch suffix names for each supported ISA/ABI combination. Well-known in particular means it is allowed for them to be hard-coded in toolchain source files, as well as in executable files and libraries built by such a toolchain. * Change GCC back-ends to use the well-known multiarch suffix as OS multilib suffix, depending on target and ABI-changing options. Also include multiarch suffix in ELF interpreter name passed to ld. (Probably need to change ld default directory search paths as well.) * Change the dynamic loader ld.so to optionally append the multiarch suffix (as a constant string pre-determined at ld.so build time) after each directory search path, before further appending capability suffixes. (See above as to open questions about -rpath and LD_LIBRARY_PATH.) * Change package build/install rules to install libraries and ld.so into multiarch library directories (not covered in this document). Change system installation to provide for backward-compatibility fallbacks (e.g. symbolic links to the ELF interpreter). * If capability-optimized ISA/ABI-compatible library variants are desired, they can be build just as today, only under the (same) multiarch suffix. They could be packaged either within a single pacakge, or else using multiple packages (of the same multiarch type). * Enforce platform-independent header files across all packages. (In the alternative, provide for multiarch include paths in GCC.) * Build cross-compiler packages with --with-sysroot=/ I'd appreciate any feedback or comments! Have I missed something? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 9 months

5
23
0 0

Bootstrapping cross compiler status

by Marcin Juszkiewicz

As you probably know I am working on bootstrapping cross compiler. Process is described on https://wiki.linaro.org/CrossCompilers page. Current status is: nearly done. Done: - Linux/stage1 - patch (LP:603087) waits approval from kernel team. - GCC 4.5/stage[12] - patch (LP:603497) created In progress: - eglibc/stage1 builds but needs packaging work Problems: - gcc/stage3 (normal full build) fails on shlibs because I do not have libc6-armel packages installed in system but dpkg-shlibdeps needs them How to bootstrap cross compiler? - apt-get source gcc-4.5 eglibc binutils linux-image-2.6.35-8-generic - copy gcc-4.5 dir to gcc-stage1 gcc-stage2 gcc-stage3 - copy eglibc dir to eglibc-stage1 eglibc-stage2 - fetch and apply my patches from LP:603087 LP:603497 LP:603498 - create directory "sysroot/" and point WITH_SYSROOT and WITH_BUILD_SYSROOT enviroment variables to it - cd binutils* && TARGET=armel dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../binutils-arm*deb . - export PATH=$PWD/sysroot/usr/bin:$PATH - export LD_LIBRARY_PATH=$PWD/sysroot/usr/x86_64-linux*/usr/arm*/lib - cd linux* && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel - cd sysroot && dpkg-deb -x ../linux-libc-dev*deb . - cd gcc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb . - cd eglibc-stage1 && DEB_STAGE=stage1 dpkg-buildpackage -b -uc -us -aarmel As packaging is not yet done for that step manual copying of debian/tmp-libc/ contents to sysroot dir is needed. - cd gcc-stage2 && DEB_STAGE=stage2 dpkg-buildpackage -b -uc -us - cd sysroot && dpkg-deb -x ../cpp*deb ../gcc*deb . - cd eglibc-stage2 && dpkg-buildpackage -b -uc -us -aarmel - cd sysroot && dpkg-deb -x ../libc*deb . - cd gcc-stage3 && dpkg-buildpackage -b -uc -us Here dpkg-shlibdeps will complain so for that step manual copying of debian/tmp/ contents to sysroot dir is needed. sysroot dir will then contain working cross compiler - so far I used it to compile hello.c and kernel for beagleboard I did not tested yet building stage3 compiler with sysroot=/ like it should be for installing it on other systems. But thats future. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 9 months

1
1
0 0

gcc-linaro-4.5+bzr99315 build results

by Michael Hope

...are available at: http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99315/ I've also finished reference builds of FSF GCC 4.4.4, 4.5.0, and 4.5.1. According to the GCC testsuite, there are no regressions between the Linaro and FSF branches and in some ways we're a bit better: On x86_64 for FSF 4.5.0 (-) vs linaro-4.5+bzr99315 (+): === gcc Summary === -# of expected passes 61211 +# of expected passes 61239 +# of unexpected successes 1 -# of expected failures 180 +# of expected failures 179 # of unsupported tests 825 On i686 FSF 4.5.0 vs linaro-4.5+bzr99315: === gcc Summary === -# of expected passes 62285 +# of expected passes 62309 # of unexpected failures 12 -# of unexpected successes 25 +# of unexpected successes 26 -# of expected failures 192 +# of expected failures 191 # of unsupported tests 533 g++, fortran, and objc are the same between builds. And, strangely enough, ARM is still building. -- Michael

15 years, 9 months

1
0
0 0

gcc-linaro-4.5+99310

by Michael Hope

Results are available here: http://ex.seabright.co.nz/build/gcc-linaro-4.5-99310/ Colourised versions of the build logs are available at: http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/i686-lu… http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/x86_64-… http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.5-99310/logs/armv7l-… i686 has # of unexpected failures 12 # of unexpected successes 26 x86_64 has: # of unexpected successes 1 armv7l has: # of unexpected failures 16 # of unexpected successes 2 g++: # of unexpected failures 6 I've started reference builds of FSF 4.4.4 and 4.5.0. i686 is done, x86_64 half done, and armv7l is still soldering along... -- Michael

15 years, 9 months

1
0
0 0

Toolchain WG - 2010-08-02 minutes

by Michael Hope

Minutes from the Toolchain WG weekly meeting are available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-02 A copy, along with activity reports, follow. -- Michael = Monday 2nd August 2010 = == This month's meetings == <<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,08,,,,WorkingGroups/ToolChain/MeetingTemplate)>> == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Julian Brown || julian(a)codesourcery.com || jbrown || || Michael Hope || michael.hope(a)linaro.org || michaelh || || Richard Earnshaw || richard.earnshaw(a)arm.com || rearnshaw || || Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand || || Yao Qi || yao.qi(a)linaro.org || yao || == Agenda == * Review action items from last meeting * New public call-in number: code 263 441 7169 * Hardware availability * Next milestone * Outstanding changes that could be merged * GCC testsuite failures and what to do about them * http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.4-93543/logs/armv7l-… ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Blueprint ||<style="text-align: center;">Assignee || || [[https://blueprints.launchpad.net/gcc-linaro/+spec/initial-4.4|Initial delivery of Linaro GCC 4.4]] || ams || || [[https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers|Cross Compiler Packages]] || hrw || == Action Items from this Meeting == * ACTION: Michael to organise and spread next Monday's call in number * ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is * ACTION: [[LP:500524]] Ulrich to backport to Linaro 4.4 * ACTION: Test failures: Michael to build FSF 4.4.4 as a baseline * ACTION: Test failures: Michael to compare FSF and Linaro GCC failures * ACTION: Test failures: All Linaro GCC failures to be ticketed * ACTION: LTO check on ARM: Michael to reproduce * ACTION: Ulrich to write up known GDB work * ACTION: [[LP:598147]]: Michael to reproduce the test failures * ACTION: [[LP:398403]]: Andrew to reproduce on his IGEP board (has more RAM) * ACTION: Michael to make sure merge requests are present for work that has been done == Action Items from Previous Meeting == * ACTION: Michael to organise and spread next Monday's call in number * DONE: Michael to re-check release dates and suggest something * Set to the second Tuesday of each month. Lines up with other Linaro releases quite well. * DONE: Michael to rename the intermediate milestone * Set to 2010.08-0. Created 2010.09-0 for the next. * DONE: Loic to find the Chrome OS contact name for the records * DONE: Ulrich to confirm PowerPC approach with Matthias * Confirmed that reverting the PowerPC changes is OK == Minutes == * Reviewed the action items from the previous meeting * Reviewed the high-priority tickets * Merging 4.4.5 * Michael is unhappy with merging for next weeks release unless 4.4.5 comes out in the next few days * Richard went through the announcements. Last was for 4.4.4 on April 30. * 4.4.5 is due around now * Expect that the GCC team are focused on 4.5.1 instead * ACTION: Richard to ask the GCC developers on IRC what the status of 4.4.5 is * [[LP:500524]] * Ulrich has done upstream in 4.4.5 * A small change, unlikely to cause correctness regressions, may cause performance regressions * ACTION: Ulrich to backport to Linaro 4.4 * GCC test suite * Michael asked what level of failures are acceptable * Richard said that the FSF GCC has never been completely clean on ARM * Failures may exist upstream * In the future, should investigate all and fix * For now, investigate regressions * ACTION: Michael to build FSF 4.4.4 as a baseline * ACTION: Michael to compare FSF and Linaro GCC failures * ACTION: All Linaro GCC failures to be ticketed * Regressions marked as 'test regression' with Medium severity * Existing failures to be marked as 'test failure' with Low severity * Wiki page [[Toolchain/UbuntuRegressions]] has triage from earlier * Ulrich noted that fixing [[LP:500524]] in Linaro will overlap with Ubuntu toolchain maintainer's current 4.4.4+svn patch * Michael said that it is the responsibility of the Ubuntu toolchain mainter to manage that * Linaro will notify them on the change * Discussed LTO * Michael sees LTO tests fail on gcc-linaro-4.5 on ARM with --enable-languages=c,c++ * Assumed it was binutils related * Ulrich: shouldn't be as GCC does most of the work * ACTION: Michael to reproduce * Future work * Focused on GCC at the moment * Need medium term plan * Focused on the core toolchain * GCC * Binutils * GDB * eglibc * New hire specialises in qemu and will focus on that * Multiarch is written up, unsure if we've agreed to do the work * ACTION: Ulrich to write up known GDB work * Medium severity tickets * [[LP:598147]] * May be three issues in one ticket * Issues due to hardening, now fixed * Stack crash due to invalid usage * Extra test failures * ACTION: Michael to reproduce the test failures * [[LP:398403]] * ACTION: Andrew to reproduce on his IGEP board (has more RAM) * Ongoing work * ACTION: Michael to make sure merge requests are present for work that has been done --- Yao: == Linaro GCC 4.4 bug fix == * LP:604874. Tried different set of configure/build options to reproduce segfaults. Ulrich Weigand finally fixed this bug. * LP:497295 It is about an ICE on maverick/arm. Reproduced ICE on maverick/x86. ICE goes awy on linaro gcc, so it is not caused by linaro patches. Finally, I find it is related to gcc-default-ssp.diff in Ubuntu. Team decide to leave it as won't fix for 4.4, and get fix from upstreams in 4.5. * Issue #3314|LP:602288 Understand previous comments on this issue, and read something on "address cost" in gcc. Looks like not easy to fix this problem. * LP:612011|GCC PR45094 Create a patch against PR45094, and tested on ARM/QEMU. Post my patch to gcc-patches first time in my life. A typo is found in my patch. I fixed typo and submit a new patch again. Suggested to run regression test again. * LP:602285|Issue #5157 This bug is caused by our restrictions to the unrolling times. Proposed two options to fix this bug. Waiting for the feedback from the team. == Misc == * Try gnu-checkout/gnu-devel/gnu-test for linaro toolchain * Read doc on ARM ABI and procedure call standard == This Week == * Get patches to PR45094 approved, and backport it for LP:612011. * Discuss with team and choose one from two options to fix LP:602285. * Other bugs on launchpad. --- Andrew: == IGEPv2 == Continued with IGEPv2 board bringup. The OS that came with the board proved inappropriate for creating Ubuntu Maverick chroots, so I looked to updating the board. The IGEP website has tutorials on how to do this using a tool called "rootstock". It didn't take to long to get the board running with a more recent kernel, but using an Ubuntu Lucid rootfs proved more problematic. Getting a base system installed is not too hard, but that doesn't have sshd or any other way to get in, and although serial output works, serial input is broken, and I don't have a USB keyboard (imagine that!) so using the video console is no good either. Solved this problem by rebuilding a new rootfs that did have sshd in it, and getting that setup right. Then installed all the new software I wanted, set up a maverick chroot on NFS to work with, and gave Yao and Chung-Lin access. All was working well, so I took the SD card out, backed it up, returned it to the board, and now it won't boot, again! To be continued .... == GCC 4.5 == Applied the first batch of SourceryG++ GCC 4.5 patches to the Linaro sources, tested them, found them good, and pushed them to launchpad. Applied another set of patches, and set them testing. Marked all the patches in the CodeSourcery patch tracker that I definitely won't be pushing to Linaro. == Linaro patch tracker == Corresponded with Michael Hope regarding the Linaro patch tracker. == Other == Finished getting the CodeSourcery build system to work with Launchpad, and the Linaro GCC configurations. -- Ulrich == GCC == * Analyzed and fixed bug #604874 (Firefox fails to build) - Fixed upstream (mainline, 4.5.2) as PR c++/45112 - Linaro GCC 4.4 branch merge request pending * Analyzed and fixed bug #500525 (bootstrap failure in stage3) - Backported mainline fix to upstream 4.4 branch * Miscellaneous bug analysis / triage / comments on: #437726, #608125, #607665, #505829, #600209 * Provided patch to revert CodeSourcery PowerPC changes from Linaro GCC 4.4 (now merged). == GDB == * Continued looking into GDB 7.2 test suite regressions * Initial implementation of Thumb-2 support in ARM prologue parsing == Miscellaneous == * Provided write-up of multiarch toolchain implications document == Infrastructure == * Ordered IGEPv2 board

15 years, 9 months

1
0
0 0

GCC PRE patch; apply or not?

by Andrew Stubbs

CS has this patch in SG++: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html This patch improves code size in a useful, target independent way, but was not committed upstream. It's not clear why. Since the patch does not belong to CodeSourcery, we can't upstream it ourselves either. Is that patch a suitable candidate for Linaro GCC? It is not upstreamable due to copyright issues, but we have a policy that we can keep such patches, if we wish. The principle of not letting Linaro and SG++ diverge too far also suggests keeping it. Any thoughts? If nobody objects soon I shall merge it in. Andrew

15 years, 9 months

3
5
0 0

-fremove-local-statics optimization

by Andrew Stubbs

As already discussed with Loic, CodeSourcery have a GCC patch that implements a new optimization: -fremove-local-statics. Essentially, it transforms code like this: int foo (void) { static int a = 1; return a; } into this: int foo (void) { int a = 1; return a; } Admittedly, if the code is written like that you might argue that the auther gets what they deserve, but apparently at least one of the EEMBC benchmarks does have these, so now we all care about it. This patch was originally submitted, by RedHat, to gcc-patches here: http://gcc.gnu.org/ml/gcc-patches/2008-07/subjects.html#00982 Some discussion later, they decided it would be better to implement the optimization using inter-procedural dead store analysis: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01602.html This doesn't seem to have actually been done. Not yet, anyway. So basically we're left with this patch that does something we want, but not in a way that can go upstream. :( The question is, should I merge this to Linaro, or not? Loic and I agreed to hold off until I'd done a bit more research and/or tried to upstream it again, but now I think we need to think again. Andrew

15 years, 9 months

3
4
0 0

Toolchain WG - 2010-07-30 minutes

by Michael Hope

The minutes from last Friday's standup call are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-30 -- Michael

15 years, 9 months

1
0
0 0

Toolchain WG - 2010-08-02 Agenda

by Michael Hope

The agenda for todays call is available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-08-02 The call will be on the usual code / numbers - I have the conference code for doing a fully public call, but not the corresponding dial in numbers. See you then, -- Michael

15 years, 9 months

1
0
0 0

gcc-linaro-4.4+bzr93543 build results

by Michael Hope

...are available here: http://ex.seabright.co.nz/build/gcc-linaro-4.4-93543/logs/armv7l-maverick-c… A highlighted version croess-referenced with the current tickets is here: http://ex.seabright.co.nz/helpers/testlog/gcc-linaro-4.4-93543/logs/armv7l-… I'd like to talk tonight about what our GCC testsuite acceptance criteria should be. -- Michael

15 years, 9 months

1
0
0 0

gcc-linaro 4.5+bzr99302 build results

by Michael Hope

The results of building the gcc-linaro 4.5 branch are here: http://ex.seabright.co.nz/build/gcc-linaro-4.5-99302/ The i686 build has gcc unexpected failures: http://ex.seabright.co.nz/build/gcc-linaro-4.5-99302/logs/i686-lucid-cbuild… # of expected passes 62301 # of unexpected failures 12 # of unexpected successes 25 # of expected failures 192 # of unsupported tests 533 The x86_64 build is clean. The armel build should be up by the time people read this. -- Michael

15 years, 9 months

1
0
0 0

Ubuntu Lucid running from SD card on IGEPv2

by Andrew Stubbs

Hi all, These are approximate instructions for installing Lucid on an IGEPv2. It uses the kernel recommended on the IGEP site because this supports the SD card. I'm sure an ubuntu kernel will be fine later. At the end, you will have an SD card that will boot the IGEPv2 board with no external intervention or devices. This recipe is derived from here: http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution Andrew ---------------------- sudo apt-get install rootstock uboot-mkimage qemu [The next step gives you the kernel, initrd, and rootfs all in one. Ideally I would have it install lxde now, to match the "demo" OS that came with the board, but I found that it hung. Create minimal install for now, and install lxde later, once the board is running.] sudo rootstock --fqdn ubuntu --login jdoe --password letmein --imagesize 2G \ --seed wget,nano,linux-firmware,wireless-tools,usbutils,openssh-server,openssh-client --dist lucid \ --serial ttyS2 --components "main universe multiverse" \ --kernel-image http://www.rcn-ee.net/deb/lucid/v2.6.33.5-l3/linux-image-2.6.33.5-l3_1.0luc… mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d vmlinuz-2.6.33.5-l3 uImage mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d initrd.img-2.6.33.5-l3 uInitrd cat > boot.source < EOF fatload mmc 0:1 0x80000000 uImage fatload mmc 0:1 0x82000000 uInitrd setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60 root=/dev/mmcblk0p2 console=ttyS2,115200n8 fixrtc bootm 0x80000000 0x82000000 EOF mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "Boot Script" -d boot.source boot.ini [Format the SD card with two paritions, mmcblk0p1 small fat-16 (label "boot"), and mmcblk0p2 large ext3 (label "rootfs").] cp uImage uInitrd boot.ini /media/boot sudo tar xzpf armel-rootfs-<date>.tgz -C /media/rootfs/ ln -s ../init.d/ssh /media/rootfs/etc/rc2.d/S01ssh [Set up /media/rootfs/etc/network/interfaces - you'll need an "auto eth0" line and something to go with it] [Boot the target, log in (jdoe/letmein)] sudo apt-get install lxde gdm [Actually, I only installed the lxde desktop so I could run it remotely using Xnest. If you want a graphical login on the video output, only then do you need gdm also. Not installing gdm means that Xorg doesn't start at boot time and eat memory and cycles.]

15 years, 9 months

2
2
0 0

Standup meeting minutes 2010-07-28

by Michael Hope

Minutes from the toolchain working group stand up call are at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-28 -- Michael == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Chung-Lin Tang || cltang(a)codesourcery.com || cltang || || Julian Brown || julian(a)codesourcery.com || jbrown || || Loïc Minier || loic.minier(a)linaro.org || lool || || Michael Hope || michael.hope(a)linaro.org || michaelh || || Richard Earnshaw || richard.earnshaw(a)arm.com || rearnshaw || || Scott Bambrough || scott.bambrough(a)linaro.org || scottb || || Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand || || Yao Qi || yao.qi(a)linaro.org || yao || == Agenda == * Stand-up call - progress, what's next, and problems == Action Items from this Meeting == * ACTION: Richard: will send Michael an email on the sync primitives * ACTION: Richard: will see where the str* assembler routines landed == Action Items from Previous Meeting == == Minutes == * Andrew: * Has received a IGEPv2 board and is trying to get it working * Having trouble with the maverick chroot * Modifying the CSL build system to use bzr * Modifying the CSL build system to try the Ubuntu glibc * 4.5 merges will start going in soon * Chung-Lin: * Looking at hard float * Working on libffi. Has looked at the internals and has started the port * Julian: * Working on porting the 4.4 changes into 4.5 * Also has a IGEPv2 board and is working with Andrew to get it going * Ulrich: * Proposed the powerpc revert to doko, who is happy with that approach * Working with upstream on [[LP:500524]]. Patch should be present in 4.4.5 * To work on the Firefox issue [[LP:604874]] * Michael: * Working on a continuous build * Starting a write-up on patch tracking * Yao * Has looked into and reproduced [[LP:604874]] * Will look into the assembly to see what is going on * Richard: * Working on the sync primitives in gcc and their use in eglibc * ACTION: Will send Michael an email on their use * Michael: any hand coded mem* or str* that he knows of? * ACTION: Richard: probably present in CSL eglibc, will investigate * Problems with the license of - want BSD as they're universal, but glibc may require LGPL Next call is on Monday

15 years, 9 months

1
0
0 0

My work on cross compiler packages

by Marcin Juszkiewicz

Hi As some of you know I am working on cross compiler packages for Ubuntu. Those of you who know what Emdebian is probably use their repositories for such stuff. Thats ok - I just want to share with you what my job will bring in near future and what I have done in last 3 months. Since 26th April I am working for Canonical as part of Linaro project. Due to my six years of OpenEmbedded experience I became part of Toolchain Working Group and started work on packaging. Specification etc are listed on blueprint page: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers I started with reviewing gcc-4.4/4.5 and binutils packaging rules and merged them as much as possible to get rid of *-cross.mk files which went bitrot a bit. As result we got packages with debug versions of libraries, dependencies are proper and as a bonus we got libmudflap cross compiled in case someone needs it. Currently I am working on bootstraping cross compiler without using dpkg-cross converted packages (aka Emdebian way). I got it working with Ubuntu Maverick versions and published all required patches in bugs linked to my blueprint. Maybe it is not easy to recreate but should work when you will try. To make it possible I also have to alter contents of *-source binary packages from binutils/eglibc/gcc/linux to have a possibility to reuse their packaging rules in new $ARCH-cross-compiler package on which I will work in next weeks. And here I have a problem. How much of debian/ directory should be provided in *-source binary packages? Minimal set just to be able to call "dpkg- buildpackage -b" and get wanted output or rather everything just in case? Why new $ARCH-cross-compiler package instead of Emdebian way? Think about buildd and how they work - nothing can be done manually there so we need to automate whole procedure. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 9 months

3
7
0 0

Toolchain WG - 2010-07-26 Meeting notes

by Michael Hope

The Toolchain Working Group meeting notes from 2010-07-26 are now available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-26 A copy follows. -- Michael = Monday 26th July 2010 = == This month's meetings == <<MonthCalendar(WorkingGroups/ToolChain/Meetings,2010,07,,,,WorkingGroups/ToolChain/MeetingTemplate)>> == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Chung-Lin Tang || cltang(a)codesourcery.com || cltang || || Julian Brown || julian(a)codesourcery.com || jbrown || || Loïc Minier || loic.minier(a)linaro.org || lool || || Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw || || Michael Hope || michael.hope(a)linaro.org || michaelh || || Scott Bambrough || scott.bambrough(a)linaro.org || scottb || || Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand || || Yao Qi || yao.qi(a)linaro.org || yao || == Agenda == * Review action items from last meeting * Feedback on the sprint * Ideas at [[Internal/MichaelHope/ToolChainMockup]] * What's next * Our focus * Release dates * Hardware availability and needs * Benchmark ideas * Open source ones * 'Typical' open source projects such as ffmpeg, libtheora * Closed tests * Next release * Blueprint status * Moving to public phone call * New starter, Chung-Lin Tang . ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Blueprint ||<style="text-align: center;">Assignee || || [[https://blueprints.launchpad.net/gcc-linaro/+spec/initial-4.4|Initial delivery of Linaro GCC 4.4]] || ams || || [[https://blueprints.launchpad.net/ubuntu/+spec/arm-m-cross-compilers|Cross Compiler Packages]] || hrw || == Action Items from this Meeting == * ACTION: Michael to organise and spread next Monday's call in number * ACTION: Michael to re-check release dates and suggest something * ACTION: Michael to rename the intermediate milestone * ACTION: Loic to find the Chrome OS contact name for the records * ACTION: Ulrich to confirm PowerPC approach with Matthias == Action Items from Previous Meeting == * DONE: Go to the sprint * DONE: Loic: announcement for linaro-announce, Andrew and MLH to review before sending * DONE: Andrew will create release via the Launchpad milestone page * DONE: Ulrich to summarise the GDB Thumb 2 issues and post so that Andrew can see if CSL have already done this. * CSL agrees that it is a problem and isn't working on it == Minutes == * Reviewed the agenda * Michael Hope is now the toolchain lead * Calls will be shifted to a public number starting next Monday * ACTION: Michael to organise and spread number. * Went over release dates * Loic suggested the second Tuesday of every month instead as it gives the rest of working week to handle problems * Michael would like to keep close to the FeatureFreeze/FinalRelease dates so that announcements coincide * ACTION: Michael to re-check dates and suggest something * The next release, due in a week, will be skipped due to no significant changes since last release * ACTION: Michael to rename milestone * Hardware availability * CSL * i.mx51 in their data centre * Julian, Andrew: have IGEPv2 * Yao, Chung-Lin: will get hardware * Loic pointed everyone to the internal hardware availability page * Ulric: is organising hardware * Loic wants to investigate using qemu as a buildd host * Michael will write-up and share his hardware. Everything should move into the data centre later * Benchmarks * Loic noted that we want everything in the open and reproducible, so prefer freely usable benchmarks * Don't want trivial benchmarks * Most commercial benchmarks include the source but have restrictions on sharing the results * Michael asked for suggestions on benchmarks * Michael to look at freely usable benchmarks such as lmbench * Current tickets * Yao and Michael will look at Firefox * Ulrich is investigating the next in the list * Michael would like to send a weekly 'State of the toolchain' update * Consumed by linaro-dev, Ubuntu toolchain maintainers, and perhaps others like Ubuntu kernel maintainers * Loic suggested via Launchpad news * Discussed communication with Ubuntu * All notification to go via Ubuntu toolchain maintainers * U-T-M has responsibility to pass this downstream * Loic talked with a developer on Chrome OS * Interested in trying the toolchain * Currently plain GCC 4.4.1 * Require something very stable * ACTION: Loic to find a name for the records * General want for us to try building Chrome OS using the Linaro toolchain * PowerPC * Ulrich talked with Matthias at the end of the sprint * From a Ubuntu perspective, don't want 4.5 to regress in features vs 4.4 * Revert the 4.4 PowerPC changes, keep SH and MIPS. Ubuntu doesn't support SH or MIPS so no change * ACTION: Ulrich to confirm with Matthias Next call is on Wednesday

15 years, 9 months

2
1
0 0

Ubuntu Binutils patches

by Andrew Stubbs

I've created a new wiki page that details what patches be plan to take from Ubuntu Binutils, and apply to Linaro Binutils: https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuBinutilsPatches Andrew

15 years, 9 months

1
0
0 0

Updated FTBFS status

by Michael Hope

The armel build that doko kicked off some time ago has completed. I've gone through and categorised the different failures and created tickets as appropriate. Latest results are here: https://wiki.linaro.org/MichaelHope/Sandbox/BuildFailures -- Michael

15 years, 9 months

1
0
0 0

Standup meeting minutes 2010-07-16

by Michael Hope

Also available at https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-16 = Friday 16th July 2010 = == Attendees == ||<rowbgcolor="#333333" rowstyle="color: white; font-weight: bold;"style="text-align: center;">Name ||<style="text-align: center;">Email ||<style="text-align: center;">IRC Nick || || Loïc Minier || loic.minier(a)linaro.org || lool || || Andrew Stubbs || andrew.stubbs(a)linaro.org || ams || || Michael Hope || michael.hope(a)linaro.org || mhope || || Ulrich Weigand || ulrich.weigand(a)linaro.org || uweigand || || Yao Qi || yao.qi(a)linaro.org || yao || || Marcin Juszkiewicz || marcin.juszkiewicz(a)linaro.org || hrw || == Agenda == * Review action items from last meeting * Personal work plan for the sprint * Release status == Action Items from this Meeting == * ACTION: (everyone) note down what you plan to do so that others can find you * ACTION: Loic: announcement for linaro-announce, Andrew and MLH to review before sending * ACTION: Andrew will create release via the Launchpad milestone page * ACTION: Ulrich to summarise and post so that Andrew can see if CSL have already done this == Action Items from Previous Meeting == * (None) == Minutes == * What do do during the sprint * See https://wiki.linaro.org/Events/2010-07-PlatformSprint/ToolChainWG * Group discussion topics in the morning * Free to make own arrangements * ACTION: (everyone) note down what you plan to do so that others can find you * Release status * doko confirmed that the tarball was OK * Andrew: nothing known remaining for the release * ACTION: Loic: announcement for linaro-announce, Andrew and MLH to review before sending * ACTION: Andrew will create release via the Launchpad milestone page * Andrew * nothing left to do except make things public * looking at FTBFS issues * looking at getting the CSL test suite running with Linaro * Michael * Still reading, making a list of questions for next week * Ulrich * looking into one of the ICE in reload. Andrew also looking. Ulrich will take over this bug * GDB build failures: noticed one significant root problem due to prologue tracing * GDB understands ARM and Thumb, but not Thumb 2 * Loic: plan for GDB Thumb 2 porting * ACTION: Ulrich to summarise and post so that Andrew can see if CSL have already done this * Specifically gnu-linaro-tools(a)codesourcery.com + linaro-toolchain(a)list.linaro.org + Pedro Alves + Dan Jacobowitz * Loic: Ubuntu has a set of detached debug symbols (http://ddebs.ubuntu.com/) which will help as reduces need for prologue parsing * Yao * merging internal CSL 4.4 patches into 4.5 * looking into Ubuntu FTBFS, trying to reproduce * Loic: would like a list of done vs remaining to get idea for progress * Andrew: would prefer to do it in a weekly status report * Marcin * Working on the staging of the GCC build * now combining into a build from scratch * has stage 1 for most cases * Loic * looking at hard float * interesting case of performance vs specialisation * discussion with Andrew re: tracking changes upstream. Will discuss at sprint -- Michael

15 years, 9 months

4
3
0 0

FTBFS update

by Michael Hope

I've updated https://wiki.linaro.org/MichaelHope/Sandbox/BuildFailures to include the six new build failures since yesterday. In my opinion, the most important are the two with compiler issues: qemu-kvm: invalid assembler https://bugs.launchpad.net/gcc-linaro/+bug/605252 libtheora: ICE on 64 bit math https://bugs.launchpad.net/gcc-linaro/+bug/605255 These are next important as they're important packages that have some type of runtime failure: apr: fails in the test phase https://bugs.launchpad.net/gcc-linaro/+bug/604862 axis2c: aborts https://bugs.launchpad.net/gcc-linaro/+bug/604864 firefox: segfaults when running a native tool during the build process https://bugs.launchpad.net/gcc-linaro/+bug/604874 -- Michael

15 years, 9 months

4
5
0 0

-mimplicit-it=thumb and FSF

by Dave Martin

Hi Richard, Am I right in understanding that fsf's primary objection to -mimplicit-it is the resulting unpredictability of the size of the assembler output for asm blocks? Note that the assmbler output size is _already_ unpredictable: what about the variable size of Thumb-2 instructions already, and what about use of assembler directives such as: #define nops(count) asm( \ ".rept " #count "\n\t" "nop\n\t" ".endr" \ ) Presumably this will defeat GCC's literal pool placement on any architecture which has literal pools. Indeed, we can come with an inexhaustible supply of such cases: it's an inevitable result of the separation between GCC and the assembler. If for Thumb-2 I assume we already have a heuristic that attempts to count the number of instructions and predicts the maximum size of the asm block as n*4 bytes (where n is the instruction count), would it be feasible to estimate a bound of n*6 bytes if using -mimplicit-it? Or, do we dump the literal before the asm block to be on the safe side (and if so, why doesn't this work equally well when using -mimplicit-it?) Re the suggestion that inline asm should be "fixed" to include explicit IT instructions, do you know a practical way to do this? My concern is that with GCC -marm, the inline asm is passed as-is to be interpreted non-unified syntax (for backwards compatibility purposes), whereas with -march>=armv6t2 -mthumb, the asm is passed (again as-is) to be interpreted in unified syntax. But with explicit IT blocks, it's impossible to be compatible with both syntaxes if my understanding is correct: Am I right in thinking that current GNU as in non-unified syntax mode, and indeed legacy versions of the tools will treat the IT instructions as an error and barf? Can you think of a way of working round this? The best I can think of right now is ghastly preprocessor stuff along the lines of #ifdef __thumb__ /* or more correctly __thumb2__ ? */ #define __asm_it_generic(mnemonic,cond) #mnemonic " " #cond "\n\t" #else #define __asm_it_generic(mnemonic,cond) /* expands to nothing */ #endif #define __it(cond) __asm_it_generic(it,cond) #define __ite(cond) __asm_it_generic(ite,cond) /* ... */ asm( __it(eq) "moveq r0, #0\n\t" __ite(eq) "bleq func1\n\t" "blne func2\n\t" ); An alternative, if we are happy to "fix" source packages in a way which breaks building them with older tools, is to pass unified assembler assembler in unified syntax too. But that would require some work in the code gen backend for arm if I understand correctly. But it's a huge task to port everything and some upstream projects may not accept the changes at all. My concern is that without some transitional approach, there's simply too much existing code for this to be viable. Do you know when unified assmbler support was introduced in fsf? Cheers ---Dave

15 years, 9 months

2
1
0 0

Ignore host includes during cross compilation

by Marcin Juszkiewicz

As some of you know I came to Linaro from OpenEmbedded project. In OE we cross compiled by default and to make it more easy we had one nice addon to gcc. When host includes were used gcc errored out with "CROSS COMPILE BADNESS: /usr/include used" style message. Patch is present in metadata: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gcc/gcc-4.4… no-host-includes.patch Some time ago replacement was announced on OE mailing list: http://thread.gmane.org/gmane.comp.handhelds.openembedded/34169 In that thread Khem Raj mentioned -Wno-poison-system-directories which is available in CSL toolchains. I would like to get that functionality in our cross compiler as this nicely shows problems in packages. I got hit by that in eglibc when it fails with: In file included from ../ports/sysdeps/arm/libc-tls.c:20:0: ../csu/libc-tls.c: In function ‘__libc_setup_tls’: ../csu/libc-tls.c:194:1: error: ‘__ARM_NR_set_tls’ undeclared (first use in this function) ../csu/libc-tls.c:194:1: note: each undeclared identifier is reported only once for each function it appears in just because unistd.h used from host instead from target includes. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 9 months

2
2
0 0

Re: Standup meeting minutes 2010-07-16

by Marcin Juszkiewicz

Dnia piątek, 16 lipca 2010 o 11:35:30 Michael Hope napisał(a): > * Marcin > * Working on the staging of the GCC build > * now combining into a build from scratch > * has stage 1 for most cases I have all stages working. Eglibc/stage1 needs work on packaging. Regards, -- JID: hrw(a)jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

15 years, 9 months

1
0
0 0

Toolchain WG - 2010-07-12 Meeting notes and activity report for last week

by Loïc Minier

[ Resent to linaro-toolchain@. ] Hey Sorry for the belated post; please find below the minutes from Monday's Toolchain Working Group meeting and the activity reports from the preceding week. You can find the full meeting notes at https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-12 = Monday 12th July 2010 = == Agenda == * Review action items from last meeting * New linaro-toolchain mailing-list * Topics for sprint [[Internal/Events/2010-07-PlatformSprint]] * Release, version numbers, uploading tarballs * No meetings next week * Blueprint status * Initial delivery of Linaro GCC 4.4 * Cross Compiler Packages == Action Items from this Meeting == * Andrew to propose the triplet change to toolchain upstream * Andrew to send email to Debian ARM on best triplet * MLH to pickup perl if pbrook doesn't have a patch by Monday evening UTC * MLH to write up wants as a toolchain developer/tester * Marcin to check if xdeb incorrectly produces a package findutils-armel * Loic to push changes on mysql == Action Items from Previous Meeting == * Loic and Andrew to extend wiki page to track progress of the merging of Ubuntu patches, assignees etc. DONE * Loic to setup and run a call on merge workflow with bzr DONE * Matthias to sort autotools issues with new cell-4.4 Linaro patch or to ask Ulrich for help :-) DONE * Marcin to fix -gcc symlink (LP #600927) and update-alternatives installability issue in his public cross-compiler packages DONE * Yao to update https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches wiki page for the issue with ADA support and the patches he merged * Yao to update https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions wiki page for the removal of the license patch DONE * Loic to create a linaro-toolchain-drivers team which can upload tarballs PARTIAL Group created, tarball upload currently not working == Minutes == * The linaro-toolchain list for toolchain related chatter; please subscribe! * Loic called for sprint topics. See https://wiki.linaro.org/Events/2010-07-PlatformSprint/ToolChainWG * Meetings have been cancelled for the week of the sprint * Mentioned the upcoming hardfp port that Debian is investigating * Port is too large for Linaro itself * Toolchain should support - best place to support, easiest to maintain due to doko * Better choice for Debian as they may get support from Linaro; won't from CSL 2010 Lite edition * Noted that there's disagreement on the Debian triplet and position of the hf marker. Problem is what is correct vs which is the path of least resistance. * ACTION Andrew to propose the triplet change to toolchain upstream? * Noted that the ARM EABI is a family of ABIs that different vendors take variants from * ACTION Andrew to send email to Debian ARM on best triplet * Milestone issue review * ACTION MLH to try perl if no progress is made by pbrook * getfem++ can't be reproduced * vect/* won't fix * mysql fix is ugly * pr9771-1.c MLH to continue or send patch otherwise * neon triggered by march=armv7a which should have occurred with Lucid GCC * Can lower priority if a missed optimisation * MLH wants help on how to best use the packaging system to do what he's used to such as * Build exactly what the Ubuntu PPA will end up as * Build a cross-compiler to try ARM failures on a fast machine * Do an incremental build * Do a non-bootstrap build * Run the compiler under a debugger * Use the test compiler to build a package * ACTION MLH to write up wants * Andrew has a process to build the tarball and will run the certification process afterwards * Loic recommended CSL developers to have local hardware * Blueprints status * Initial 4.4 release reviewed. Done except Ada patch. Andrew to edit whiteboard to note * Update broken Ubuntu patches * Loic suggests reviewing Ubuntu patches month to month * Cross compiler (Marcin) * Tidying up ugly GCC hacks * Stage 1 is now clean * ACTION Marcin to check if xdeb incorrectly produces a package called findutils-armel * ACTION Loic to push changes to mysql * Michael will run Wednesday standup call Activity reports from preceding week: = Ulrich Weigand = == GCC == * Resolved merge conflicts between cell-branch.diff and gcc444-linaro.diff (investigated and fixed additional autoconf-related build issue) * Investigated bug #602287; resolved as won't-fix for Linaro 4.4 * Started investigating bug #602289 == GDB == * Completed build and regression test of GDB 7.2 branch on beagle board * Started working on hardware-breakpoint-support blueprint == Education == * Continued getting familiar with Debian package build process * Continued getting familiar with Launchpad infrastructure * Read ARMv7 Architecture Reference Manual == Infrastructure == * Got remote access to Loic's beagle board * Started process to acquire IGEPv2 board = Yao Qi = == Linaro GCC == * Ubuntu patch ada-acats.diff on linaro gcc 4.4. ada-acats.diff and its dependent patches cause some regression failures. Spent a lot of time on trying different patch sets to linoar gcc 4.4, but failures do go away. Checked the build log of ubuntu gcc, and the same failures are there. We decide to leave this ubuntu patch. * Merged 19 ubuntu patches to linaro gcc 4.4. Learn bzr push/merge/branch/commit. Very good version control tool, and well-collaborated with launchpad. * Revert license patch in linaro gcc 4.4. * Merge CS GCC 4.4 patches to CS GCC 4.5. Choose three patches from Julian's ARM patch list. Two of them are committed into CS GCC 4.5. The third is sent to CS internal review. == Misc == * Some meetings on linaro status. = Andrew Stubbs = == GCC 4.4 == * Continued refining the blueprints. We now have the initial 4.4 toolchain delivery blueprint finalised. * Entered bugs for each of the test regressions in the Ubuntu GCC vs. FSF GCC. * Reviewed Yao's launchpad merge request for the Ubuntu GCC patches. It was all good, so I approved the request and did the merge. * Reviewed the ARM test failures to make sure they were what we anticipated they would be. * Reviewed some of the Ubuntu patches marked "Needs review". Decided not to use two, rewrote the third and submitted the new patch for review. Matthias has now accepted it, and applied it to Debian also. * Found out how to create gnu-style release tarballs and wrote a Linaro GCC release procedure document for the wiki. https://wiki.linaro.org/WorkingGroups/ToolChain/GCCReleaseProcess == GCC 4.5 == * Assisted Yao with his patch porting work, and made sure he had things to do. = Loic Minier = * Repaired Beagleboard to boot again * Cross-built ncurses; did other xdeb tests * Added color codes and improved structure of https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions and https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches * Discussed armhf port, started http://wiki.debian.org/ArmHardFloatPort * Started sprint planning and associated wiki pages Bye, -- Loïc Minier

15 years, 9 months

1
0
0 0

Upstream merge progress

by Andrew Stubbs

Hi All, I've created a new wiki page to track our upstream merge process. https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches I'll add the new patches (using the script) periodically, for now, but maybe it could go on a cron job somewhere in future. The idea is that people write useful thing in this page manually, as and when state changes. If we don't do something like this, we'll lose track of what's submitted, and what isn't. Thanks Andrew

15 years, 9 months

5
6
0 0

gcc cross-compiler

by Yao Qi

Hi, all, I notice that linaro-gcc is a native compiler on ARM, when I go through linaro gcc bugs on launchpad. When we fix bugs, shall we configure gcc as a native compiler on ARM directly, or configure gcc as a cross compiler on i386 box? Former needs extra hardware boards, while latter needs some cross compiling setting. I'd like to know how do you do that?

15 years, 9 months

3
3
0 0

Toolchain WG - 2010-07-14 Standup notes

by Michael Hope

Hi there. The notes from today's stand up call are available at: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-14 A copy follows. One thing I forgot is the upcoming sprint. Please add what you'll be working on to https://wiki.linaro.org/Internal/Events/2010-07-PlatformSprint/ToolChainWG - it's great for networking as it helps those interested in similar areas to track you down. == Attendees == * Andrew Stubbs * David Rusling * Michael Hope * Richard Earnshaw * Ulrich Weigand * Yao Qi * Juilan Brown == Minutes == * Andrew has been working on the release. A power failure last night interrupted the test suite. MLH noted that Matthias has started his own build/test process. Andrew will hold off re-running the tests * Richard has been getting involved in the ABI discussions, which seem to be winding down from ARM's point of view * Ulrich has been backporting the testsuite fixes. Next task is looking at gdb. He has run the test suite on gdb 7.2 and found more failures than expected. * Yao is continuing on the CSL 4.4 to 4.5 patch set. The process is still ongoing. MLH offered to help with any Ubuntu specific packaging problems partly due to being close in timezones. The next stand up meeting is on Friday the 16th. -- Michael

15 years, 9 months

1
0
0 0

Using bzr with the toolchain

by Michael Hope

I've expanded the notes on using bzr for toolchain development here: https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips It's now much more step-by-step and includes notes on how long operations take and how big they end up on disk or the network. -- Michael

15 years, 9 months

1
0
0 0

Review of armel regression FTBFSes

by Loïc Minier

Hey Matthias kicked an armel rebuild of Ubuntu main with a gcc-4.4 + Linaro diff package. The rebuild copy-archive is visible at: https://launchpad.net/ubuntu/+archive/test-rebuild-20100707 The failed logs are at: https://launchpad.net/ubuntu/+archive/test-rebuild-20100707/+builds?build_t… @Steve, you had offered help in reviewing the i386/amd64 rebuilds in the past (and I think Michael Hope was working on these); I would very much take help in reviewing the armel issues. Is this something the Foundations team could help with? I'd like to discuss organizing this review a bit. * First, we need to make sure we don't review the same build logs multiple times; the rebuild isn't over and builds are going to continue showing up; Matthias told me new build logs will show up at the top, so we only need to note the last package we reviewed. * We need some place tracking the build logs which we skipped (for which we didn't file a bug) and/or note last reviewed package; I propose to note this down in a wiki page. * For now, we should skip openjdk / java related issues; openjdk needs some bug fixing before we can consider using it on armel. Such issues should be documented along other instructions in the aforementioned wiki page. * I think we should skip packages which FTBFS on x86. Do we actually compare build logs before classifying these? * We should file bugs with some standard tags, perhaps linaro + armel? * I would like us to develop helpers to analyze build-logs; perhaps Lucas Nussbaum has something since he manages to analyze the grid5000 rebuild logs decently. Ideally, these tools would also allow assigning build log reviews to people, leaving comments and such. Comments welcome! Cheers, -- Loïc Minier

15 years, 9 months

3
5
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain