Re: Debian powerpc binary compatibility?
On Sun, 19 Sep 2010 22:35:27 +0200
Sebastian Andrzej Siewior <firstname.lastname@example.org> 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
> These a few of the options that are paassed to gcc's configure script:
> >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 -
> >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  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
Having the separate target looks inconvenient for me - you have to
"push" the target to all package, so they wouldn't fail on "configure
> >And while we at this: on the , 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
> >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  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  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
> >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
> - 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
> - 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.
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586068