[ECOS] Re: gcc/gdb for mpc860

Bart Veer bartv@redhat.com
Thu Jan 27 06:07:00 GMT 2000

>>>>> "Michael" == Crowe, Michael E <michael.e.crowe@lmco.com> writes:

    Michael> I realize this is not the proper group for this question
    Michael> but I have had no luck with the people in the
    Michael> gnu.gcc.help newsgroup, and everyone here seems more
    Michael> knowledgable anyway. I'm trying to port gcc and gdb
    Michael> (along with binutils and newlib) to target the MPC860 on
    Michael> a PLX Board. The board should not matter (should it??), I
    Michael> beleive that it is solely processor dependant. My host is
    Michael> Redhat Linux 6.0 with the gcc compiler. SO, has anyone
    Michael> successfully built a cross-compiler under linux that
    Michael> targets the mpc860. I am trying to port eCos to this
    Michael> board, but without a compiler, it's VERY difficult :-)

For the compiler side things are pretty easy. The best place to start
right now is with the complete toolchain sources you can download from
http://sourceware.cygnus.com/ecos/getstart.html , following the
"Installing eCos under Linux" link. Download
ecosSWtools-990319-src.tar.bz2 and then just follow the instructions,
selecting powerpc-eabi as your target triplet. You should end up with
a complete functional toolchain.

Please note that these are not the very latest versions of the tools,
but they should be adequate for the time being. It is possible to
build a working toolchain by combining the latest release of gcc, a
recent snapshot of binutils (the last official release was quite some
time ago and did not have certain functionality required by eCos), and
so on. All of these are available by visiting
http://sourceware.cygnus.com .

gdb is more complicated. The compiler, assembler, linker etc. have no
specific dependencies on the target board: issues such as memory
layout are handled at link-time by providing a suitable linker script,
which is part of the eCos porting process. However gdb needs to
interact directly with the hardware. This may involve talking with
some sort of ROM monitor via a serial line, or it may involve special
debugging hardware such as JTAG, or whatever. If a serial line/ROM
monitor combination is used then there may be further problems,
because different ROM monitors use different protocols and gdb may not
know the protocol for your particular one. Within Red Hat, to make our
life easier we generally replace any existing ROM monitor with our own
gdb stubs. That way we know what is going on and we can implement
additional functionality such as thread-aware debugging.

There is documentation available on the gdb internals, which you will
find in the gdb sources. If you are running on Linux then you may have
the info pages already installed.

Bart Veer // eCos net maintainer

More information about the Ecos-discuss mailing list