This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: gcc/gdb for mpc860
>>>>> "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