View Single Post
Old 09-22-2012, 09:19 PM   #696
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,477
Karma: 26012492
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
@Kai771:

The isoc99 stuff should be gone with a GNU_SOURCE define (usually adding -D_GNU_SOURCE to CPPFLAGS is enough, although some crappy buildsystems may not honor CPPFLAGS, so, to the CFLAGS soup if it's not enough), or a tweak of the -std CFLAG, although it's been a while since I've run into those with my TC, so I may be a bit rusty (and I'd go with defining GNU_SOURCE over tweaking the standard).

The __aeabi_atexit was why I'm putting -fno-use-cxa-atexit in CXXFLAGS in the Makekfile (although it may have some ties to how my TC is built) .

Basically, look at the KINDLE_TC case switch near the top fn my x-compile script, after the TC setup, that's where I setup the env. (Granted, I'm a Gentoo user, so I'm used to setting this up in profiles & co).

A big dumb recursive grep on the whole tree should light up the object files pulling the troublesome symbols, that may help pinpoint which buildsystem was naughty.

And, since we're talking about TC, for those of us using GCC 4.7.2 or Linaro GCC 4.6/4.7:

Code:
## NOTE: See http://gcc.gnu.org/gcc-4.7/changes.html & http://comments.gmane.org/gmane.linux.linaro.devel/12115 & http://comments.gmane.org/gmane.linux.ports.arm.kernel/117863
## But, basically, if you want to build a Kernel, backport https://github.com/mirrors/linux/commit/8428e84d42179c2a00f5f6450866e70d802d1d05 [it's not in FW 2.5.8/3.4/4.1.0/5.1.2],
## or build your Kernel with -mno-unaligned-access
## You might also want to backport https://github.com/mirrors/linux/commit/088c01f1e39dbe93a13e0b00f4532ed8b79d35f4 if you intend to roll your own Kernel.
## For those interested, basically, if your kernel has this: https://github.com/mirrors/linux/commit/baa745a3378046ca1c5477495df6ccbec7690428 then you're safe in userland.
## (That's the commit merged in 2.6.28 that the GCC docs refer to).
## It's in FW 3.x/4.x/5.x, so we're good on *some* Kindles. However, it's *NOT* in FW 2.x, and the trap handler defaults to ignoring unaligned access faults.
## I haven't seen any *actual* issues yet, but the counter does increment...
## So, to be on the safe side, let's use -mno-unaligned-access on the K3 TC, to avoid going kablooey in weird & interesting ways on FW 2.x... ;)
ARM_NO_UNALIGNED_ACCESS="-mno-unaligned-access"
Basically: If you intend to build a Kernel, backport the commit mentioned earlier or build it with -mno-unaligned-access (there shouldn't be any issues in userland, it's properly set up by the kernel later on >= ARMv6 (cf. arch/arm/mm/alignment.c)).

Also, if you target something running on FW 2.x, use -mno-unaligned-access for userland stuff too, it might not be safe in every cases otherwise.

Last edited by NiLuJe; 09-23-2012 at 04:45 PM. Reason: Ammended (again) my whole unaligned access investigation, always better to double check things in the morning ;)
NiLuJe is offline   Reply With Quote