Hello Sebastian,
On Sun, 19 Sep 2010 22:35:27 +0200 Sebastian Andrzej Siewior <sebast...@breakpoint.cc> wrote: > * Sergei Poselenov | 2010-09-18 11:44:01 [+0400]: > > > >Thanks, but I'm looking for specific information - what instruction > >set was used by gcc to build Debian binaries. > > > >It seems to me this information is not readily available... I can > >only guess of gcc configuration - just defaults (-mcpu=powepc > >-msoft-float). > > These a few of the options that are paassed to gcc's configure script: > > --enable-shared > --enable-multiarch > --enable-linker-build-id > --enable-threads=posix > --enable-nls > --enable-clocale=gnu > --enable-libstdcxx-debug > --enable-objc-gc > --enable-secureplt > --disable-softfloat > --enable-targets=powerpc-linux,powerpc64-linux > --with-cpu=default32 > --with-long-double-128 > --build=powerpc-linux-gnu > --host=powerpc-linux-gnu > --target=powerpc-linux-gnu > > >Yes, I'm aware of an attempt to run Debian on e500v2 - it throws > >"Illegal instruction" on "lwsync". I'm sorry I don't have enough > >details - what Debian Distro they tried and what kernel the target > >has been run. > > > >However, speaking about the "lwsync" problem on e500 - I've got an > >impression that the problem should be solved already - > >http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01238.html > > > >Do you know - isn't the fix in the mainline gcc? > > Yes it is. The e500 gcc (that one with target powerpc-linux-gnuspe) > does not throw this opcode. There is however handwritten assembly > code in a few packages using this instruction. Anyway the powerpc > port does use this opcode and it is legal for them to do so. For the > powerpcspe port I have a patch in binutils [0] which replaces a few > opcodes for us. One of the replacements is lwsync with sync. > Ah, right. The main Debian uses just another GCC configuration target. BTW, do you know - why the separate target for e500? Is the instruction set for e500 so fundamentally different it needs a special configuration for GCC? Why GCC cannot switch codegeneration at run-time, conditioning on "-mcpu=e500"? Having the separate target looks inconvenient for me - you have to "push" the target to all package, so they wouldn't fail on "configure --target=powerpc-linux-gnuspe". > >And while we at this: on the [0], the current status of the project > >is "stalled" because of GCC bug in e500 floating point insns. The > >bug is reported against 4.4.4. > > > >Have you tried other Debian GCC version - 4.3? Is the bug there, too? > > Yes I can reproduce it on 4.3. > This is bad. Does this mean the modern GCC cannot be used for e500 currently? > >Yes, I understand this. I guess, for your powerpcspe port you are > >rebuilding Debian packages on the system running the same Debian, > >right? (What Debian are running on your e500, btw? How your overcame > >the "lwsync" problem?) > > Upstream packages which use are fixed / changes. Usually they benefit > from [0] so don't have to send a lot of patches. > Mmm, do you mean that you are running the Debian rebuilt with gnuspe GCC and [0] binutils fix? Have you considered to fix the "lwsync" problem in kernel? I mean to catch the Illegal Instruction exception and switch the faulted lwsync to sync? Regards, Sergei > >Probably, I was not quite clear in my question - we are considering > >the case that there will be no working Debian distribution for > >particular target (like e500 "lwsync" problem I mentioned above), so > >we will have to use some other distribution for native build system, > >with different toolchain version (I'mean the versions of gcc, > >binutils and glibc, which could be different of those in Debian > >toolchain). How could I rebuild Debian on such system? > > If your goal is to come up with a new distribution for a new target > that has no debian support then I got to say that this aint't fun :) > However here are the basic steps from what I remember doing for the > powerpcspe port: > - cross compile a minimal enviroment with gcc, glibc, binutils, bash, > perl and so on. That are packages in the category essential / > build-essential and are required by almost every package. Use > scratchbox or something else. Doing it all by hand is painfull. > - once you have a minimal enviroment hack your new target into dpkg > and build it. > - start compiling debian packages. In the beginning you don't have all > dependencies so you just skip those and hope the package will still > work. Well if you start to build your first package than you can't > fulfill the dependencies at all. So you take a look at the > dependencies, check manually that you have them and force the build > process to continue. Some packages require doxygen to build the > documentation. It i a long way to get doxygen built. So in the > beginning you just skip doxygen and omit the documentation and hope > it builts. If it doesn't because the built script wants to run doxygen > and fails, then you have to tweak the script a little so it will > pass. > - extra fun packages are cyclic dependencies. Those you have to > examine case by case. Maybe you have to compile package A with less > features, compile package B and then compile package A with all > features. > - Once you have a few packages you try to rebuild them with your > native toolchain to ensure yo have none of those packages you cross > compiled around. > > >Apparently, I need first to build the Debian toolchain, and then make > >sure the binaries are linked against the new-built Glibc, not the > >build host one. Also, because of the package dependencies, the order > >of package's build is also important. > > The build order is more or less not impartant. For instance one of the > essential files you need is bash and you want to build it. bash > depends on dash so you try to get dash done. dash itself needs > debianutils so try that one. And so on :) > > >So, the question is - how to build Debian "from scratch"? > I hope I covered your question this time. > > > > >Regards, > >Sergei > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586068 > > Sebastian -- To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100921140924.46b1e...@emcraft.com
