Re: Making the GCC compiled code work with another Debugger

George Neuner <>
13 May 2005 17:57:14 -0400

          From comp.compilers

Related articles
Making the GCC compiled code work with another Debugger (2005-05-09)
Re: Making the GCC compiled code work with another Debugger (George Neuner) (2005-05-13)
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers,
Date: 13 May 2005 17:57:14 -0400
Organization: Compilers Central
References: 05-05-052
Keywords: GCC, debug
Posted-Date: 13 May 2005 17:57:14 EDT

On 9 May 2005 22:31:50 -0400, 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.

Good luck.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.