[ACTIVITY] weekly status
Hi, * continued to look into how to add remote support for libunwind using ptrace * reworked the lookup of the ARM specific unwind tables for local unwinding * re-use the existent (dwarf related) infrastructure to find the ARM specific unwind tables rather than doing it on our own * removes some code and the limitation of only supporting a certain amount of unw tables * (hopefully) smooths the way for remote unwinding via ptrace * submitted a patch that fixes the syntax of inline assemblies for some GCC versions Regards Ken ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
LLVM on ARM testing.
Hello, I'm interested in LLVM correct performance on ARM hardware and it looks like LLVM is kind of sensitive to what GCC version is used for its compilation. I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro 2011.05 and 4.6.1 Linaro 2011.06. Please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ It looks like LLVM HEAD does have about 28 regressions in comparison with LLVM 2.9. But also Linaro's GCC 4.6.1s do have some regressions in comparison with older GCC 4.3.4 and 4.4.1. Also what is really interesting with LLVM is how much tests fails when compiled with -O2 or default -O3 compilation option. I don't know if the culprit here is LLVM code or just GCC miscompilation/overoptimization? Is there any testing I may do to help you fix those regressions? Thanks, Karel ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: LLVM on ARM testing.
On Mon, Jul 4, 2011 at 8:39 AM, Karel Gardas wrote: > > Hello, > > I'm interested in LLVM correct performance on ARM hardware and it looks like > LLVM is kind of sensitive to what GCC version is used for its compilation. I > tested LLVM 2.9 as a reference point and LLVM > HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu > versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro > 2011.05 and 4.6.1 Linaro 2011.06. Please see > http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > It looks like LLVM HEAD does have > about 28 regressions in comparison with LLVM 2.9. But also Linaro's GCC > 4.6.1s do have some regressions in comparison with older GCC 4.3.4 and > 4.4.1. Also what is really interesting with LLVM is how much tests fails > when compiled with -O2 or default -O3 compilation option. I don't know if > the culprit here is LLVM code or just GCC miscompilation/overoptimization? > > Is there any testing I may do to help you fix those regressions? Hi Karel. That's an interesting idea - you've ended up using LLVM to test GCC. I'm not sure the source of these problems, but the first step is to treat these as an application bug and investigate from there. Load LLVM up in GDB, put a breakpoint in the assert, and see if the values look valid. Try building LLVM with -fno-strict-aliasing to see if LLVM is doing something unusual. See if a cross-compiled LLVM has the same faults. It'll be interesting to see how this turns out. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Generating ancilliary sections with gas (fwd)
On Mon, Jun 20, 2011 at 4:15 PM, Michael Hope wrote: > On Tue, Jun 14, 2011 at 9:03 AM, Nicolas Pitre > wrote: >> Hello Michael, >> >> We do have more and more instances of the following issues turning up in >> the kernel requiring toolchain assistance to solve the problem properly. >> Could you or someone from your team follow this up please? > > Hi Nicholas. Sorry for the delay. We'll talk about this at today's > meeting and I'll follow up to this thread. Hi Nicholas. We had a talk about it at the meeting (unfortunately) two weeks ago. The original request can be split into two bits: finding the current section name, and changing the assembler state at runtime. The latter is possible but a fair chunk of work. Per section and per symbol attributes are possible but not implemented. One idea would be to add a new directive such as '.permitted push neon' to allow NEON instructions from here on, and '.permitted pop' to restore the previous state. The section name work is trickier. I don't like Dave's suggestion of adding a new formal argument type which expands to the callers section name. It works, but isn't really a formal type like 'required' or 'vaargs'. An alternative is to add a new macro-local variable such as \_sectionname. Do you have a work around? How much smaller would the kernel be with support for fetching the current section name? The minutes are here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2011-06-20 -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Generating ancilliary sections with gas (fwd)
On Mon, 4 Jul 2011, Michael Hope wrote: > On Mon, Jun 20, 2011 at 4:15 PM, Michael Hope wrote: > > On Tue, Jun 14, 2011 at 9:03 AM, Nicolas Pitre > > wrote: > >> Hello Michael, > >> > >> We do have more and more instances of the following issues turning up in > >> the kernel requiring toolchain assistance to solve the problem properly. > >> Could you or someone from your team follow this up please? > > > > Hi Nicholas. Sorry for the delay. We'll talk about this at today's > > meeting and I'll follow up to this thread. > > Hi Nicholas. We had a talk about it at the meeting (unfortunately) > two weeks ago. The original request can be split into two bits: > finding the current section name, and changing the assembler state at > runtime. > > The latter is possible but a fair chunk of work. Per section and per > symbol attributes are possible but not implemented. One idea would be > to add a new directive such as '.permitted push neon' to allow NEON > instructions from here on, and '.permitted pop' to restore the > previous state. Sure, however that won't solve the problem at hand. From reading the minutes I have the impression ttwo issues might be mixed up together. > The section name work is trickier. I don't like Dave's suggestion of > adding a new formal argument type which expands to the callers section > name. It works, but isn't really a formal type like 'required' or > 'vaargs'. An alternative is to add a new macro-local variable such as > \_sectionname. That would certainly be perfectly fine. > Do you have a work around? How much smaller would the kernel be with > support for fetching the current section name? We do have a workaround which consists of pulling all the referenced code in the kernel and discarding it at run time instead of simply discarding it at link time. But this feels really awkward because the toolchain is really unhelpful here. The kernel size is not that huge considering that we're talking about some code marked as __exit i.e. module removal cleanup code which is obviously not needed when linking modules in the kernel. But with more runtime patching of the kernel techniques, more of that previously link-time discarded code now has to be moved to the __init section which could be seen as a regression. Nicolas___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
