Re: Debian powerpc binary compatibility?
Hello Sebastian,
On Sun, 19 Sep 2010 22:35:27 +0200
Sebastian Andrzej Siewior <sebastian@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
Reply to: