|Making the GCC compiled code work with another Debugger email@example.com (2005-05-09)|
|Re: Making the GCC compiled code work with another Debugger firstname.lastname@example.org (George Neuner) (2005-05-13)|
|From:||George Neuner <email@example.com>|
|Date:||13 May 2005 17:57:14 -0400|
|Posted-Date:||13 May 2005 17:57:14 EDT|
On 9 May 2005 22:31:50 -0400, firstname.lastname@example.org wrote:
>I am using the cross compiler of gcc version 2.95.3 to compile code for
>ARM9 target. Unfortunately, I dont have the simulator on linux (the
>machine which I use to run gcc). I do have a simulator on windows - AXD
>that comes with codewarrior ARM developer suite. I would like to to run
>the executable generated by gcc on this simulator.
>The problem is that when I run the code in AXD debugger, it encounters
>invalid instructions and simply doesnt work. I feel this is because of
>the fact that:
>1) There is debug info inserted by GCC which is not understood by AXD
>2) The glibc is being used which is not liked by AXD. The documentation
>of compiler of codewarrior has following comment: "If you write an
>application in C, you must link it with the C library even if it makes
>no direct use of C library functions. The C library contains compiler
>helper functions and initialization code."
>Does this mean that there is no way of running the gcc compiled code on
>If someone has tried anything similar, please let me know.
I'm not familiar with ARM9 so I can offer only generalities. The
folks in comp.arch.embedded can probably give you more specific
Couple of possibilities spring to mind.
First, in general you cannot use glibc (or any all-up C/C++ runtime)
for embedded development. The runtime library tries to initialize a
heap and the standard I/O files/streams and in general makes all sorts
of assumptions about the environment which may not be true for your
system. Compilers for embedded systems normally provide an "exploded"
library in which the functions are available individually (or in
related packages) and in source form so that you can pick and choose
exactly what you need and, if necessary, tweak them for your platform.
If you have such a library, you should use it instead of the standard
library ... if not you should give serious thought to acquiring one.
[ Btw: the source for glibc is available, and you could port it to
your platform, but you should really not try to pick out and use
individual functions - the code, in general, was not written to stand
alone or be mixed and matched. Trying to use it piecewise will just
cause you aggravation. ]
However, just linking glibc should not cause invalid instructions to
be executed ... your program won't work, but you should get invalid
memory or I/O references - not invalid instructions. This suggests
that the simulation target is not configured properly. Minimally you
need to verify the processor and locations and widths of all memory
and I/O - there may also be other target specific settings like serial
access, timing, etc.
It could also be as simple as specifying the wrong load address when
linking the program or a messed up boot loader putting your code in
the wrong place.
If your compiler's debug info is not compatible with the simulator ...
you're out of luck as far as symbolic debugging (you can still debug
the hard way). Compile your application without debug info and see if
you can run it - that will tell you for sure. Debuggers are usually
targeted to a particular release of a compiler - you might need to
downgrade the compiler or upgrade the simulator.
One last thought - you might try running the simulator under WINE or
whatever Windows emulation you have on Linux. If it works, it will
let you compile and debug on the same platform.
Return to the
Search the comp.compilers archives again.