Hi, ext Siarhei Siamashka wrote: >>> By the way, do you have any plans for upgrading toolchain? Either I'm >>> extremely unlucky, or current toolchain is really very buggy. >> You can see the known issues from the GCC bugzilla. >> There are a few bugs in C++ support which have been fixed >> in gcc 3.4.6 (Maemo toolchain is 3.4.4) or 4.x. > > But doesn't current maemo toolchain have lots of modifications to > backport EABI support which only officially appeared in gcc 4.x? > These modifications might have introduced some additional instability.
True, but GCC bugzilla might anyway be missing bugs existing in upstream gcc too (especially ones that happen only on less common platforms such as ARM). :-) >>> It does not support -pg option properly (for profiling with gprof), >> Hm. The toolchain might not be built with -pg support. >> As to using gprof, that produces fairly unreliable results. >> I'd recommend building Oprofile kernel and latest oprofile >> user-space tools. > > Maybe Oprofile is good, but gprof is better than nothing and does not require > recompiling kernel. On x86 I prefer valgrind/cachegrind/callgrind/kcachegrind as that way one can browse the source code interactively with the profiling information. Getting to know how the source really works is sometimes more useful than knowing the exact bottleneckedness percentage of some function. This is less useful for more hardware dependent features like video though. :-/ >>> also I encountered at least one internal compiler error and a couple of >>> invalid code generation bugs already. >> C++ code generation? Or C? (GCC bugzilla mentions only C++ >> code generation issues) > > I have encountered the following problems on C code (MPlayer). > > ICE: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22177 > > Definitely invalid code generation in inline asm (but the same bug > apparently shows up in gcc 4.1.1 as well): > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31693 > > Invalid code generation suspected: > https://garage.maemo.org/tracker/index.php?func=detail&aid=254&group_id=54&atid=269 > https://garage.maemo.org/tracker/index.php?func=detail&aid=763&group_id=54&atid=269 > > I did not investigate these two last problems thoroughfully (this might be > probably some bad code in MPlayer with 'undefined behaviour' which works > better on some compilers but breaks on the others), but they disappear when > compiling with gcc 4.1.1 crosscompiler (outside scratchbox using gentoo > crossdev). > >> ICE you can get around by trying another optimization level >> (sometimes -Os or -O3 works where -O2 doesn't). > > Well, I'm worried not about how to workaround ICE but about the overall > quality of the compiler. I wonder how many compiler related bugs are lurking > in maemo software but are not caught yet? But again, maybe I'm just unlucky > to get hit by more bugs than the others :) I know only one issue where a bad code generation was suspected (in C++ code), but it was never really verified. > Did anybody try installing newer toolchains in scratchbox and use them with > maemo SDK? I just don't have much free time for these experiments and > don't want to break my installation of scratchbox which works now (more or > less acceptable) Installing new toolchains for Sbox shouldn't be a problem (if it's already available for it) and you can make a new Sbox target for each toolchain you want to test. > Building packages with new toolchain would probably need to have libstdc++ > linked statically for C++ applications to work on 770/N800, but otherwise > everything should be fine. Actually, you cannot really build static binaries with Glibc. It links some stuff always dynamically (nss for example). I don't know whether this is a problem in practice though. (uClibc is better in this respect and produces significantly smaller binaries too.) >>> One more question is about the kernel, ARM11 seems to support unaligned >>> memory access in hardware, but this feature is not enabled on N800. >> What the "seems", "to support" and "feature enabled" mean in >> the above clause? Seems how? And what is result? Enabled what? > > "seems" is a standard disclaimer which means that I did not work with these > features myself, only read this information from docs and can't be sure if I > understood everything correctly :) > >> ARM CPU is able to trap them? Kernel could SIGBUS the co. processes? >> (as unaligned access has AFAIK undefined results on ARM, is often >> coding error and "fixing" those accesses on kernel side has definitive >> performance penalty) > > http://arm.com/documentation/ARMProcessor_Cores/index.html > 'ARM1136JF-S and ARM1136J-S r1p1 Technical Reference Manual' > Chapter 4 'Unaligned and Mixed-Endian Data Access Support' Did you read the section on "ARMv6 unaligned data access restrictions"? Basically it doesn't work in all cases, the accesses are not atomic and have performance implications. > As ARM11 core used in N800 is little endian, does have floating point unit and > supports unaligned memory access in hardware (which only needs to be enabled). > It probably doesn't have any serious portability issues to be aware of > anymore and vast majority of software initially developed for x86 should be > easy to compile and run on it even without doing any modifications. Compiler aligns everything correctly if your code is correct. I think non-aligned code is bug and performance issue. > Enabling unaligned memory support will make life much easier for developers > unfamiliar with ARM platform. The number of applications for N800 should > grow up, as less newbee developers will be turned away frustrated by the > alignment bugs they have never heared about before. Can you give examples of issues people have with this? > But this will be to some extent a bad thing for Nokia 770, as it will result > in more applications usable on N800, but buggy on 770 - Eero _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
