### About Linaro binutils
Linaro binutils is a release of the GNU binutils with bug fixes and
enhancements for ARM platforms. GNU binutils is a collection of tools
including the ld linker and as assembler.
### Linaro binutils 2.24 2013.12
The Linaro Toolchain Working Group is pleased to announce the 2013.12
release of Linaro binutils 2.24.
This release is based on the latest GNU binutils 2.24 stable branch, but
with additional features and bug fixes.
### Additional Features
* Support for GNU indirect functions
### Bug Fixes
* Fixed miscalculation of GOTPLT offset for ifunc syms
* Handle static links with ifunc correctly
* Fixup IFUNC tests to work on all targets
### Source
### Release Tarball
* https://releases.linaro.org/13.12/components/toolchain/binutils-linaro
### Development Tree
* git://git.linaro.org/toolchain/binutils-gdb.git
This release was built from the linaro_binutils-2_24-2013_12_release tag.
### Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
* Linaro Toolchain Development [mailing
list](http://lists.linaro.org/mailman/listinfo/linaro-toolchain)
* Linaro Toolchain IRC channel on irc.freenode.net at `#linaro-tcwg`
* Questions? [ask Linaro](http://ask.linaro.org/).
* Interested in commercial support? inquire at [Linaro
support](mailto:support@linaro.org)
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (8/10)
- Validated and committed a fix from Vladimir for Thumb1 issues.
- iWMMXT issue : Tried a fix without success, continue working on it.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Various meetings. (2/10)
== Next ==
* Vacation
== Progress ==
* Debugged and Fixed process record memory corruption problem.
[TCWG-315][TCWG-317][8/10]
* Sick Time off [2/10]
== Plan ==
* Send patches for bug fixes and look into remaining arm-native gdb issues.
* Respond to maintainer's suggestion on process record patches.
* Public Holiday on 25th
* Time off for setting up new office space.
== Progress ==
* Libssp GCC patch
Replied to Marcus comments on libssp machine description support for
stack protect and test. Analyzed other ports implementations on
clearing register that loaded canary value. Waiting for his feedback.
* Pointer mangling Aarch64 glibc.
Investigated mangling support and implemented a patch. Testing glibc
test suites in V8 Foundation model is in progress.
* Attend Linaro Tool chain status meeting.
* Attend 1-1 with Christophe (Linaro).
* Attend 1-1 with Matt (Linaro) .
== Plan ==
- Pointer Guard support in Aarch64 glibc
- Continue tesing Cbuildv2
== Issues ==
* None.
== Progress ==
* Rebase aarch64 build scripts to crosstool-ng upstream, test and send
out the patch for community review (2/10).
* Investigate https://ci.linaro.org/jenkins/job/openembedded-armv8b-rootfs/gcc_version=4.….
It seams build configure issue. Some MICRO is not correctly defined.
Can not follow-up it due to no access to the build system.
* Continue on "uninit warning testsuite failures" (CARD 304 7/10)
- Identify another reason why uninit-pred-8_b.c FAIL: The control
flow is too complex, it can not normalize the condition at line 22 to
( n < 10 || m > 100 || r < 10 ).
- Work on patch to fix PHI issue to make uninit-pred-9_b.c PASS.
* Test builds for backporting "ftruncate() and truncate() stubs"
related patches in Linaro newlib.
== Plan ==
* Linaro toolchain binaries 2013.12 release.
== Progress ==
- Integrate benchmarking into Cbuildv2 (TCWG-360 7/10)
- Implementation mostly complete
- Started testing to ensure compatible with cbuild1
- Code available for comments at
https://git.linaro.org/toolchain/cbuild2.git/shortlog/refs/heads/benchmarki…
- Binutils Bug 16340 (1/10)
- Posted the patch after regression testing and analysing the results
- Mics (2/10)
- Read relocation handling of tls and its implementation for aarch64
== Plan ==
- Complete Integrate benchmarking into Cbuildv2
- Address comments for Binutils Bug 16340 and look to come up with a
simple testcase
== Progress ==
* Android LLVM
- Discussions on progress, trying to line up kernel+AOSP together
- Google has bailed Clang/LLVM for L release, will consider for next one
* Vectorizer
- Progressing on the implementation of the pragma parser
- http://llvm.org/PR18086
- Discussions about introduction of generic function vectorizer (ARM)
* Release 3.4
- Tested RC3, no regressions on tests or benchmarks
- http://people.linaro.org/~rengolin/llvm/
- http://llvm.org/pre-releases/3.4/rc3/
- Looked at a bug on the vectorizer for pentium3/freebsd
- Work around found, not easy enough to get them to RC4
* Background
- Many discussions, many support requests, many patch reviews
- Adding BOF notes to dev meeting site
- Booking train and hotel for FOSDEM 14
* Time
- CARD-862 8/10
- Others 2/10
* Happy Holidays! And see you in January!
== Issues ==
* Running benchmarks on my Chromebook is very unstable.
- Even though the standard deviation is small in two different moments,
the two results are statistically incompatible.
- The wireless network on the Chromebook, as widely known,
is unstable and unpredictable.
- I need a graphical interface, so I can do stuff during Connects,
or to see Phoronix results and that is probably the responsible
for all instability
- Next release, I'll use an ODroid (or Arndale) for benchmarks
== Plan ==
* Holidays!
== Progress ==
- 2013.12 releases (4/10)
* Handover to Michael
* Committed remaining backports/branch merges
* Unexpected regression in 4.7 branch narrowed to a linker bug, now fixed.
- cross validations (2/10)
* stabilized armeb+qemu validations
- misc (4/10): misc conf-calls and meetings; internal meetings
== Next ==
Next 2 weeks off (Dec 23rd Jan 3rd)
Merry Christmas and happy new year to all of you.
Hello,
I am using the pre-built toolchain gcc-arm-none-eabi-4_6-2012q2 from linaro
to compile u-boot (u-boot-linaro-stable) and to compile my standalone
applications to run on target(PandaBoard ES rev b2)
hello_world standalone application which comes with u-boot is executing
fine on target when I disable CONFIG_SYS_THUMB_BUILD, but when I enable it,
target gets reset with following information
Panda # go 82000000 hello
## Starting application at 0x82000000 ...
undefined instruction
pc : [<8200000c>] lr : [<bff83147>]
sp : bfeffe40 ip : bfeffc10 fp : 00000000
r10: 00000003 r9 : bffac954 r8 : bfefff68
r7 : bff01d88 r6 : 82000000 r5 : bff01d8c r4 : 00000003
r3 : 82000000 r2 : bff01d8c r1 : bff01d8c r0 : 00000002
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.01.-rc1-g0f45941 (Dec 17 2013 - 14:23:41)
OMAP4460 <http://www.ti.com/product/OMAP4460> ES1.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.bin
reading u-boot.bin
......
Can anyone please help me why thumb mode build is failing?
On 18/12/13 05:06, Jonathan S. Shapiro wrote:
> At the risk of sticking my nose in, this isn't a startup code issue.
> It's a contract issue.
>
> First, I don't buy Richard's argument about memcpy() startup costs and
> hard-to-predict branches. We do those tests on essentially every
> *other* RISC platform without complaint, and it's very easy to order
> those branches so that the currently efficient cases run well. Perhaps
> more to the point, I haven't seen anybody put forward quantitative
> data that using the MMU for unaligned references is any better than
> executing those branches. Speaking as a recovering processor
> architect, that assumption needs to be validated quantitatively. My
> guess is that the branches are faster if properly arranged.
>
> Second, this is a contract issue. If newlib intends to support
> embedded platforms, then it needs to implement algorithms that are
> functionally correct without relying on an MMU. By all means use
> simpler or smarter algorithms when an MMU can be assumed to be
> available in a given configuration, but provide an algorithm that is
> functionally correct when no MMU is available. "Good overall
> performance in memcpy" is a fine thing, but it is subject to the
> requirement of meeting functional specifications. As Jochen Liedtke
> famously put it (read this in a heavy German accent): "Fast, ya. But
> correct? (shrug) Eh!"
>
> So: we need a normative statement saying what the contract is. The
> rest of the answer will fall out from that.
>
> I do agree with Richard that startup code is special. I've built
> deeply embedded runtimes of one form or another for 25 years now, and
> I have yet to see a system where optimizing a simplistic byte-wise
> memcpy during bootstrap would have made any difference in anything
> overall. That said, if the specification of memcpy requires it to
> handle incompatibly aligned pointers (and it does), and the contract
> for newlib requires it to operate in MMU-less scenarios in a given
> configuration (which, at least in some cases, it does), it's
> completely legitimate to expect that bootstrap code can call memcpy()
> and expect behavior that meets specifications.
>
> So what's the contract?
>
I disagree with your assertion that newlib *requires* it to operate in
an MMU-less scenario for all targets; it only does so when the target
can reasonably be expected to not have an MMU.
The only contract that exists is the one written in the C standard:
7.23.2.1#2 The memcpy function copies n characters from the object
pointed to by s2 into the object pointed to by s1. If copying takes
place between objects that overlap, the behavior is undefined.
But that is written on the assumption that we're in a normal execution
environment, not in some special case.
What you're missing is that AArch64 is (in ARM ARM terms) an A-profile
only environment where an MMU is mandated in the system. Furthermore,
processors implementing the architecture will *expect* that the MMU be
turned on as soon as possible after boot, since without this the caches
cannot be used and without those the performance will be truly horrible.
Once the caches are enabled, it's perfectly reasonable to assume that
memcpy will only be used for copies to and from NORMAL memory, since
other types of memory have potential side effects, which means that use
of memcpy would be unsafe.
If you want to write an MMU-less memcpy, then feel free to write one;
but please install it with a different interface -- something like
__memcpy_nommu(). Don't penalise the standard case for the non-standard
exceptional one.
R.
