maemo.org - Talk - gcc-4.6 and Fremantle, WIP

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - gcc-4.6 and Fremantle, WIP (https://talk.maemo.org/showthread.php?t=81861)

Re: gcc-4.6 and Fremantle, WIP

Quote:

Originally Posted by Hurrian (Post 1155940)

While we're on the subject, why not upgrade other open components from upstream?

Yes, for example Tracker, PulseAudio, Dbus... some of the components could bring bug fixes or better performance, while others could bring new features (and new bugs!) to play with.

Re: gcc-4.6 and Fremantle, WIP

Quote:

Originally Posted by Hurrian (Post 1155940)

... afaik THUMB is broken on the N900's SoC, and the workaround's overhead > benefit of THUMB

[OT]
Will you be more specific on the above, i.e. which workaround overhead aganst which benefit. I will appreciate any data on the matter.
[/OT]

Re: gcc-4.6 and Fremantle, WIP

Quote:

Originally Posted by freemangordon (Post 1155973)

[OT]
Will you be more specific on the above, i.e. which workaround overhead aganst which benefit. I will appreciate any data on the matter.
[/OT]

The overhead for the 430973 bug against Thumb's purported reduced code size.

Re: gcc-4.6 and Fremantle, WIP

Not all packages can be automatically recompiled with gcc-4.6, there are some stricter rules which needs hand tuning.
---

How much used binutis affects resulting binary (size/speed)? I made test compilation with gcc-4.6.1 and with old binutils and I got bigger and slower binaries (run on N900) than just using old compiler.

What are needed flags for thumb et cetera for compiling most optimized (as speed e.g.) code?

Quote:

Originally Posted by Hurrian (Post 1155940)

While we're on the subject, why not upgrade other open components from upstream?

I have all ready started this, libglib: http://talk.maemo.org/showthread.php?p=1155248

About *programs*: some programs has new features on upstream and we could just take and use them (I would say we should do it). But new versions can be using new version of libraries, so we must upgrade libraries too.

Some libraries we can just upgrade from upstream (so just do it). But some libraries aren't backward compatible and they cause recompilation of packages. And if some of them are closed source, we must drop that package. There are 355 packages waiting for alternatives (or judgement to be dropped entirely): http://wiki.maemo.org/Fremantle_closed_packages

Is there something in non-free extras we should worry?

Re: gcc-4.6 and Fremantle, WIP

Quote:

Originally Posted by Hurrian (Post 1155977)

The overhead for the 430973 bug against Thumb's purported reduced code size.

Well, I am pretty aware of that errata, I was asking for some real data, not what your expectations are.

In short - what is the overhead from workaround for ARM errata 430973.

Because I can give some hard values for thumb2:

from only Qt, gtk, hildon-desktop, hildon-home and hildon-status-menu thumb2 compiled the reduction of code size is exactly 19MB. If you wish I can search on #maemo-ssu for how is memory consumption reduced (for several Qt/QML applications), but it varies between 2 and 6 %. And from my personal experience helium-moble-browser is much faster and less laggy when run on top of thumb2 compiled Qt.

Have in mind that I am not arguing whether it is better to have thumb2 (with errata workaround) or not, I am missing data to do the evaluation, thus my question.

@AapoRantalainen - if you feel this is totally OT, my apologies, I will start a new thread, just say it.

Re: gcc-4.6 and Fremantle, WIP

Can't vouch for Aapo, but as long this is on-topic in regards to optimizations (available/possible in near future) and compiling seems totally fine for me. For on-device compilators this would be an awesome improvement - more space for libs, more memory (less restarts when compiling things that take >700mb of memory).
Having no-clue really about the underlying mechanics, but the few pdfs out there do hint at ~20% more space (or ~6% with speed increase), so would love to see this happen (all the above posts point to this being enormous project though requiring refresh of the whole system). If someone has an idea how to get this done, please share. I am willing to test all the closed packages compatibility with newer libstdc++/gcc, if someone knows how to approach this.

Re: gcc-4.6 and Fremantle, WIP

Here is some results, I hope somebody could give some hint.

--
Binutils.
Seems recent binutils is needed and will not itself has hard dependencies, so I started from it.
Binutils-2.22 from debian packed fine
modifications/configured:
* with_multiarch := no (compiling for i386 will be easier)
* # with_gold = yes (there are bug in gcc-4.2 and it can't compile gold (internal compiler error). "gold = A new, faster, ELF only linker, still in beta test." Seems to be optional).
* using 'tar -c -z' instead of 'tar -c --xz' (Maemo's tar can't handle xz)

Packages can be installed and they seems work, but linking causes warnings:
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.22 assertion fail ../../bfd/elf32-arm.c:11467
which is:

Code:

       /* If the output has no requirement about FP hardware,

         follow the requirement of the input.  */

          if (out_attr[i].i == 0)

        {

11467     BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);

          out_attr[i].i = in_attr[i].i;

          out_attr[Tag_ABI_HardFP_use].i

            = in_attr[Tag_ABI_HardFP_use].i;

          break;

        }

And sometimes I must add "-lm" even sources were compiled earlier without it.

Linked binaries work on device.

-----------
Gcc
gcc-4.6.1-9 from Ubuntu 11.10.
Modifications:
*version's of dependencies dropped (seems ubuntu is over rated them)
dpkg-dev (1.16.0 -> 1.14.15)
gcc (4.4 -> 4.2)
libmpfr (3.0.0 -> 2.4.2)
libgmp-dev 5.0.1 -> libgmp3-dev 4.3.1
libelf0 0.8.12 -> 0.8.10
doxygen (1.7.2 -> 1.5.1)

*multi_arch =no
*uses binutils-2.22)

Packages can be installed, compilation works, but linking NOT. There are many errors like this:

Code:

test.o: In function `gnu_dev_major':

//usr/include/sys/sysmacros.h:43: multiple definition of `gnu_dev_major'

File /usr/include/sys/sysmacros.h is coming from libc6-dev.

---------
Libc
eglibc-2.13-20 from Ubuntu 11.10
Modifications:
* Maemo's patch doesn't understand: " patch: unrecognized option `--reject-format=unified' "
* Some dependencies were too high

Compilation fails with rpcgen. According to the FAQ

Quote:

1.22. `make' fails when running rpcgen the first time, what is going on? How do I fix this?

{CO} The first invocation of rpcgen is also the first use of the recently compiled dynamic loader. If there is any problem with the dynamic loader it will more than likely fail to run rpcgen properly. This could be due to any number of problems.

The only real solution is to debug the loader and determine the problem yourself. Please remember that for each architecture there may be various patches required to get glibc HEAD into a runnable state. The best course of action is to determine if you have all the required patches.

-----------
So do I must compile libc6 also? Doest this cause harm when running on device? Is my compilation order correct?

Re: gcc-4.6 and Fremantle, WIP

can't recall off the top of my head. normally i rebuild them only when creating a toolchain for building distros, not updating an existing one. having said that, i would still use the same order you are using. with respect to bootstrapping, other than comparing builds, it helps remove traces of old gcc from build by compiling itslef with newly generated binary:
1st build: gcc 4.6 built with 4.2
2nd build: 4.6 built with 4.6 built with 4.2
3rd build 4.6 built with 4.6 built with 4.6

are you sure you're making use of the new binutils?

libc6 (provided in glibc) in ubuntu used to depend on libgcc1, might still do, so you might have circular dependancies using current build method. what happens if you try to build+boostrap just gcc c compiler, then come back and do c and c++ without bootstrap after glibc?

make sure libtool using correct paths after gcc build. it might still be hardcoded to old version of gcc.

Re: gcc-4.6 and Fremantle, WIP

I installed new binutils and new gcc and checked gcc-4.6 --version -v

Code:

Using built-in specs.

COLLECT_GCC=gcc-4.6

COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper

gcc-4.6 (Debian 4.6.1-9ubuntu3) 4.6.1



Target: arm-linux-gnueabi

Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi

Thread model: posix

gcc version 4.6.1 (Debian 4.6.1-9ubuntu3) 

COLLECT_GCC_OPTIONS='--version' '-v'

 /usr/lib/gcc/arm-linux-gnueabi/4.6.1/cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabi help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --version -o /tmp/ccl7Wdzd.s

GNU C (Debian 4.6.1-9ubuntu3) version 4.6.1 (arm-linux-gnueabi)

        compiled by GNU C version 4.6.1, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.9

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

COLLECT_GCC_OPTIONS='--version' '-v'

 as -meabi=5 --version -o /tmp/ccc8qQgm.o /tmp/ccl7Wdzd.s

GNU assembler (GNU Binutils for Debian) 2.22



This assembler was configured for a target of `arm-linux-gnueabi'.

COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/

LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/:/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../://lib/://usr/lib/

COLLECT_GCC_OPTIONS='--version' '-v'

 /usr/lib/gcc/arm-linux-gnueabi/4.6.1/collect2 --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi --version /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crti.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../.. -L//lib -L//usr/lib /tmp/ccc8qQgm.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crtn.o

collect2 version 4.6.1 (ARM GNU/Linux with ELF)

/usr/bin/ld --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux.so.3 -X --hash-style=both -m armelf_linux_eabi --version /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crt1.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crti.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -L/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../.. -L//lib -L//usr/lib /tmp/ccc8qQgm.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabi/4.6.1/crtend.o /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../crtn.o

GNU ld (GNU Binutils for Debian) 2.22

if there are anything suspicious (or even not-perfect) in configurations, please comment.

Quote:

Originally Posted by Android_808 (Post 1163070)

it helps remove traces of old gcc from build by compiling itslef with newly generated binary:
1st build: gcc 4.6 built with 4.2
2nd build: 4.6 built with 4.6 built with 4.2
3rd build 4.6 built with 4.6 built with 4.6

Seems I'm doing this already:
compiled by GNU C version 4.6.1, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.9

Quote:

Originally Posted by Android_808 (Post 1163070)

are you sure you're making use of the new binutils?

GNU assembler (GNU Binutils for Debian) 2.22
GNU ld (GNU Binutils for Debian) 2.22

And this gcc-packaging uses 'ld --sysroot', which is not working with old binutils, so I'm sure it is compiled with new binutils.
(It is possible to compile gcc-4.6 with binutils-2.18, just disabling --sysroot. Truly speaking I do not know what this means.)

Quote:

Originally Posted by Android_808 (Post 1163070)

make sure libtool using correct paths after gcc build. it might still be hardcoded to old version of gcc.

libtool is pointing to the gcc. I have /usr/bin/gcc -> gcc-4.6
(and g++ -> g++-4.6)
--
I made more application tests with gcc-4.6 and binutils-2.22
A) multifile complex c-application which is using sin (libm.so)

Code:

/usr/bin/ld: test.a(test.o): undefined reference to symbol 'sinf@@GLIBC_2.4'

/usr/bin/ld: note: 'sinf@@GLIBC_2.4' is defined in DSO /usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../libm.so so try adding it to the linker command line

/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../libm.so: could not read symbols: Invalid operation

collect2: ld returned 1 exit status

B) c-application without sin:
works

c) c++ application without sin:
works

d) naive sin-test: works:

Code:

/*gcc math_test.c -lm*/

#include <stdio.h>

#include <math.h>



#define PI 3.14159265



int main ()

{

  double param, result;

  param = 30.0;

  result = sinf (param*PI/180);

  printf ("The sine of %lf degrees is %lf.\n", param, result );

  return 0;

}

---
So I'm still wondering is there need for compiling libc6?

My fault was start testing new compiler with huge and complex application. It caused lots of warning relating /usr/include/sys/stat.h and libm.so, which come from libc6-dev and libc6. (Same test compiles under Ubuntu with gcc-4.6 so it is not just deprecation of gcc-4.2). Maybe I should just compile everything lying on hard disk with gcc-4.6 and collect similarities from every failing applications.