Forum: ARM programming with GCC/GNU tools embedding C source in the disassembler window

von Alan R. (rousea)

Rate this post
0 useful
not useful
Anglia Electronics kindly sent me an Eclipse version of the STM32demo 
project. It includes a custom makefile, so it doesn't use any outside 
resource such as Solaris to create the makefile.

I am trying to create my own project to emulate this with good success 
so far. In my project I am using Solaris to create the makefile for me, 
so I can add or delete modules at will without having to modify the 
makefile each time.

However, when I compile the Anglia version of the project the Eclipse 
disassembly window shows each line of source code, followed by the 
assembler code generated. When I step through the code the source window 
and the disassembly window track logically.

My project does not include the relevant source code line in the 
disassembly. Furthermore, if I step through the code the 'cursor' in the 
source code window follows approximately where it should be, but may 
jump backwards or forward several lines each time I step.

Examining my disassemby explains the jumping, since the code is not 
totally logical. For example, if I have a sequence of lines setting 
variables to specific values the code is likely to load each value in 
turn to different r registers, then write each r register in turn to the 
relevant memory address. The same code in the Anglia version would load 
the first value into an r register, then copy it to the relevant memory 
address, then proceed to the next variable.

Can anyone help in identifying how to configure the compiler to create 
logical code, and embed source code into the disassembly listing? I 
suspect the difference must be within the makefile, since this invokes 
gcc, but all my switches are the same as those in the original. From 
searching the web I suspect I need to invoke objdump somewhere.


von Andreas S. (andreas) (Admin) Flattr this

Rate this post
0 useful
not useful
The reason for the reordering of the code is the compiler optimization. 
You are probably using -O2 or -O3, try a lower optimization level (-O1) 
or disable optimization completely (-O0) if the reordering bothers you 
and you can live with (slightly) slower/bigger code.

You can generate an assembler listing with embedded C source code by 
running objdump with the options -dS. Not sure if that's the way to do 
it so that Eclipse understands it, but can't you just compare your 
Makefile to the Anglia Makefile to see how it calls gcc/objdump/...?

von M.Bubestinger (Guest)

Rate this post
0 useful
not useful
Hi rousea ,

I don't have an answer to you question, but is it possible for you to 
upload the project template from anglia? At the moment I'm evaluating 
Crossworks, but i'm not very happy with it. My Problem is I can't get 
Eclipse working for me :(.I would be happy to see some samples for 
organizing a project with eclipse


von Alan R. (rousea)

Attached files:

Rate this post
0 useful
not useful

Thanks for the reply.

Both my project and the original Anglia project invoke the gcc compile 
with the flag -Os, so that can't explain the difference between the two 
resultant disassembly listings.

I have attached the Anglia makefile in case you can decipher how it is 
using objdump.  In Eclipse I have configured Project\Properties\C/C++ 
Build\Settings\Tool Settings to add the required flags to the Solaris 
compiler and linker. After compiler each project I have looked in the 
console window to see the command strings invoked and confirmed that the 
gcc flags are virtually the same.  There are differences, but they 
relate to the different folder structure I use to store the .c and .h 

I originally had the text "objcopy -O srec Mega_Link.elf Mega_Link.s19" 
in the Build Steps\Post Build Steps\Command window (Mega_Link being the 
name of my project).  I tried changing this to "objcopy -O srec 
Mega_Link.elf Mega_Link.s19; objdump -dS Mega_Link.elf".  During 
compilation streams of disassembly code scroll through the console 
window, but when it has finished and I launch the project, the contents 
of the Disassembly window are the same as before.

I am obviously not using objdump correctly, Can you give any further 


von Martin T. (mthomas) (Moderator)

Rate this post
0 useful
not useful
I do not fully understand what you mean with "Solaris compiler and 
linker" but did you double-check that -g is in your "Tool Settings" 
command-line options?

von Alan R. (rousea)

Rate this post
0 useful
not useful
Thanks for your comments.

I myself am very confused about the build variant I am using.  It took 
an exceptionally long time for me to get the IDE, compiler and debugger 
to work.  I initially downloaded Eclipse Gannymede, but was unable to 
compile of debug the project.  I followed instructions on numerous 
websites to try to fix this.  As far as I remember I downloaded Zylin, 
Cygwin, gdb, CodeSourcery and Solaris.  Some of these are build variants 
of gcc, some are add-ons for Eclipse.  Eventually I got a combination 
that works.  Ideally I would like to start again with a build that just 
includes the add-ons I need to do the job, but I am afraid that I will 
have difficulty unless someone can give be concise instructions of how 
to build Eclipse and gcc to develop and debug software for an Arm Cortex 

The console window shows that the commands used to build each module are 

gcc -nostdinc -DLCD_ILI9320 -DSTM32F103x8B 
-IC:/Software/Mega_Link/Mega_Link/Include -Os -g3 -Wall -c -mthumb 
-march=armv7-m -ffunction-sections -fdata-sections -Wno-pointer-sign -o 
Source\usb_endp.o ..\Source\usb_endp.c

and the linker command is:

gcc -nostartfiles -LC:\cygwin\lib\gcc\arm-eabi\4.2.3\thumb -mthumb 
-march=armv7-m -Tstm32rom.ld 
-Wl,-Map=obj\Mega_Link.map,-cref,--gc-sections -ggdb -oMega_Link.elf 
usb\src\usb_regs.o .... Source\IO.o

You will see that the compiler includes -g3 and -Os, which I believe 
together define the output format.  However, I have tried all 
combinations of these flags without success.  The above setting produce 
code that works, but is not easy to follow against the source.


von mthomas (Guest)

Rate this post
0 useful
not useful
No out-of-the-box solution but some suggestions/remarks:

The command lines just show gcc, the CS cross-toolchain uses the prefix 
arm-non-eabi so arm-none-eabi-gcc should be there. Are there any 
symbolic- or hard-links set? But maybe you are still using the toolchain 
from the Anglia package, IRC they do not use a prefix.

I usually use -gdwarf-2 but have to admit that I have never played with 
the -g options. So you may try -gdwarf-2 or just -g instead of -g3 and 

The optimization setting (-O) should not have any influence on the 
generation for debug-information.

You should not use or need to use absolute pathes like ...\thumb when 
using the frontend (arm-none-eabi-gcc) for linking and a rahter new 
build of the toolchain.

Remove the options -ffunction-sections, -fdata-sections and 
--gc-sections for now; can be added later once everything else is 

I still not not get what you mean with "Solaris". If it's the OS from 
SUN I don't see how this is related to the problem.

"cross-gdb" is included in the CS package (arm-none-eabi-gdb), no extra 
download needed. The CDT GDB hardware debugging plugin can be used 
instead of the Zylin plugin. But in the OpenOCD mailing-list there have 
been reports about problems with the gdb in current version of CS G++ 
lite for ARM. Not sure, please search the OpenOCD mailing-list archive.

Like M.Bubestinger I'm interested in the package that has been sent from 
Anglia. Please ask them for permission so you may attach it to a 
message. (S. "ntfreak" O.: do you read?)

von Alan R. (rousea)

Rate this post
0 useful
not useful
Thanks for your response.  I have asked Anglia for permission to forward 
you their project.  I obviously can't respond to you until I have their 
reply and I have had time to digest all your comments.  Since it is now 
Friday evening it will take a few days, but I will reply.


von Alan R. (rousea)

Attached files:

Rate this post
0 useful
not useful

I have attached the Eclipse configuration sent by Anglia. However, I 
must have changed something on my system, because it now fails at the 
end of compilation with the message 'cannot open map file 

I am now getting extremely frustrated with Eclipse.  I want to use it as 
a tool for developing a project to run on embedded hardware, but I am 
spending more time trying to fix the tool than I am spending developing 
the project!

I sincerely hope that someone somewhere can come up with a foolproof 
method of building Eclipse with all the necessary plug-ins so it can be 
used to develop projects running on ARM Cortex targets.

Incidentally, at some stage I stumbled across Solaris as a tool for 
constructing the compilation.  The attachment includes some screeshots 
that show the options presented for the compiler and linker.  I have not 
found any other means of easily configuring the project properties.

von mthomas (Guest)

Rate this post
0 useful
not useful
I don't think the "Solaris C Compiler support" is the best solution. 
There is a arm-gcc plugin for Eclipse available at sf.net but since I'm 
using Eclipse with a self-made makefile I can not provide additional 
information on this plugin. I suggest that you use a makefile too. There 
are tutorials from Jim Lynch (google for them) which explain the setup 
with an external makefile. Once you have the building working you can 
turn to the debugging with a gdb-server (i.e. OpenOCD). Another option 
might be to buy a commercial solution. AFIAK Codesourcery offers 
Eclipse-support in the "non-lite" versions for CS G++ for ARM. Sorry, I 
can not offer a foolproof solution. I'm using Eclipse as Editor and 
Debugger (with OpenOCD) but did not have the time to write a "guide". 
Anyway my setup for building (not debugging) is very similar to the one 
described by Jim Lynch.

von Alan R. (rousea)

Rate this post
0 useful
not useful

I am extremely appreciative of the effort you have taken to give a 
comprehensive response, and would like to thank you for it.

I have found the articles published by Jim Lynch.  In fact I had seen 
them some time ago, but I had discounted them because they don't 
encompass ARM Cortex. They were written around 2005, before the release 
of Cortex.  The same applies to YAGARTO, but their website specifically 
states that it does not cover Cortex.  I assume from this that 
incorporating Cortex is not a trivial task.

I guess my objective of implementing a variant of Eclipse that 
automatically creates the makefile should not be regarded as essential. 
However, the work I have done to date with the Solaris add-on proves to 
be a great benefit where new modules are added as the project evolves. 
It saves time when I don't have to keep modifying the makefile to 
accommodate the changes.

The implementation of Eclipse that I now have is compatible with Cortex 
and allows me to download a debug the software on my target.  However, 
the shortcomings are:

1) It does not step through code logically, and doesn't embed the C 
source within the disassembler

2) It doesn't include library functions (e.g. ctype.h)

3) After all my abortive efforts I don't know how I eventually built it, 
so can't replicate it on another computer.



Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]

Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.