How can I generate an assembler listing when compiling Teensy LP.

Status
Not open for further replies.

Burly

Member
I am switching over my development efforts from TEENSY 2.0 to TEENSY LP.

On TEENSY 2.0 I've been using Atmel Studio 6 IDE as my development platform. In using Atmel Studio 6 I've always had Assembler Code (.LSS) listing files generated. .LSS files can be opened in a text editor and they interleave the lines of C source code with the ASM instructions.

Now I am switching over to TEENSY LP and developing with Arduino/Teensyduino on Visual Micro.
Are there any settings in the gcc arm compiler that I can set to generate similar ASM listings?

If someone can provide the option settings for TEENSY LP that can be employed in the Arduino/Teensyduino IDE...then Tim Leek at Visual Micro said he will help guide me how to get the settings into the Visual Micro IDE.

Thanks!
 
Hopefully others can give you better answers here.

What I do when I wish to see what code is generated is to use the objdump program to disassemble the generated code. On my machine I believe this is located at: c:\arduino-1.6.12\hardware\tools\arm\arm-none-eabi\bin> or the longer program names out of: c:\arduino-1.6.12\hardware\tools\arm\bin>

You might try running the g++ compiler here as well with the --help option and see if you can find an option that works.
 
Hopefully others can give you better answers here.

What I do when I wish to see what code is generated is to use the objdump program to disassemble the generated code. On my machine I believe this is located at: c:\arduino-1.6.12\hardware\tools\arm\arm-none-eabi\bin> or the longer program names out of: c:\arduino-1.6.12\hardware\tools\arm\bin>

You might try running the g++ compiler here as well with the --help option and see if you can find an option that works.

Well there is the compiler option I added years ago (1988?): -save-temps, and updated in 2009: -save-temps=obj.

The original -save-temps option leaves the .s and .ii files in the directory the compiler is run from. The .s file is the assembler input file. The .ii file is the output from the pre-processor before being fed to the C++ compiler proper. The current compiler now does preprocessing combined with compiling, but -save-temps goes back to the old method of having the preprocessor run separately.

The new -save-temps=obj puts the .s and .ii files in the object directory where the compiler is directed to build the executable. This is needed for complex builds (such as a few of the Spec 2006 benchmarks, and the GCC compiler itself) where multiple source files with the same name in different sub-directories are built, and the file would get overwritten with each compile.

If you are doing -save-temps or -save-temps=obj, you probably want to use -fverbose-asm, which adds comments for the various options that are enabled in the assembler source file.

Or as indicated, you can use the ARM specific objdump program to convert the object file back into an assembly listing. I tend to use -dwx (-d is display text sections as text, -w is generate a wide listing, and -x dump all of the ELF headers). I have an emacs hook that runs objdump if I try to open a .o object file.
 
Last edited:
@ Michael
WOW...it sounds like you are a contributor of the GCC code project itself!!!

What you're explaining to me is way over my head...I know nothing about gcc at the command line level. I'm either building in Atmel Studio 6.2(for Teensy 2.0)...or now I'm just starting out in Visual Micro for the Teensy LP. These two IDE's give me more flexibility than the Arduino IDE. I also develop Windows WPF programs using Visual Studio Express 2013, so it's very nice to develop on an common interface.

In Atmel Studio 6.2 IDE, each project creates a Debug and Release directory. The IDE provides a "Properties Window" for each Project. "In the "Properties Window" under the "AVR/GNU Common" tab there is an "Outputfiles" Tab which presents a list of optional output files you can enable and disable with a checkbox. I believe .ELF is a default file that always gets put into the Debug or Release directories. I also have enabled .HEX .MAP .LLS and a few others that I don't use but were enabled by default.

I'd like to do the same thing when developing for Teensy LP (ARM Cortex 0+) in Visual Micro . However the "Properties Window" of Visual Micro is totally different. It looks like the Atmel Studio 6.2 guys created their own properties window in order to present a higher level check box interface to abstract away some of the complexity. Visual Micro looks like a "Pedal to the Metal" interface, where you really have to know your stuff syntactically.

By default, in Visual Micro the [.hex] [.elf] [ino.hex] and [ino.elf] are being generated into the Debug and Release directories. It would be nice to set things up so a [.map] and [C Source/ASM listings file/files] could also be there.

So there must be somewhere in the Visual Micro Project Profile Options where I can type the raw command options to create these output files...and save them to the same Debug or Release directories where .hex and .elf files reside.

With the clues you left above, there is a section in the Project Profile window call "Build Events".
Under "Build Events" there are three sub-options, "Pre-Build Event", "Pre-Link Event", "Post-Build Event":
Each of these has three fields to fill in...
The first I assume is raw text entry of commands to be merged into the applicable command line.
The second is raw text entry where you describe what the options do.
And an on/off switch to enable and disable the merging...

Pre-Build-Event
Command Line: <you enter your text here>
Description: <You enter your description text here>
Use in Build: Choose a Yes or No Switch

Pre-Link-Event
Command Line: <you enter your text here>
Description: <You enter your description text here>
Use in Build: Choose a Yes or No Switch

Post-Build-Event
Command Line: <you enter your text here>
Description: <You enter your description text here>
Use in Build: Choose a Yes or No Switch

Are we on the right track???
 
Last edited:
Or as indicated, you can use the ARM specific objdump program to convert the object file back into an assembly listing.

That's the way I've always done it, when trying to really optimize the C code (mostly for the audio library).
 
Hi Paul,

Yes that would work. But it is kind of nice to have the source lines there so you know where to look. Of course when you turn on high levels of optimization (AVR on Atmel Studio 6) then the code starts jumping all over the place.

So far I've only used ATUSB32U4 on Teensy 2.0 and ATUSB32U2 chips. Now I've got to wrap my mind around the chip on the Teensy LP...and the ARM instruction set.
 
Hi Paul,

My Bad...
I copied the objdump.exe into the directory and ran it against the .obj.
That's just was needed!!!
Thanks!!!
 
@ Michael
WOW...it sounds like you are a contributor of the GCC code project itself!!!
Yes, I've been a contributor to GCC since 1988 or so, almost exclusively on back end support. The ARM port is one I haven't worked on, so I can't help with any related to the Teensy except in general terms.

There are perhaps 2-3 people that were active back in 1988 that are still contributing actively to GCC now that have been working on GCC longer than me.

For the last few years, I've been working at IBM on the PowerPC compiler. At the moment, I'm working on support for the the new power9 chip that is coming soon. Before that I worked for AMD, and various other places before that.

That's the way I've always done it, when trying to really optimize the C code (mostly for the audio library).
It helps if you can add -g even if the target doesn't really support debugging, as objdump has options to show you the lines corresponding to the code that it picks up from the debugging information.
 
Yes, I've been a contributor to GCC since 1988 or so, almost exclusively on back end support. There are perhaps 2-3 people that were active back in 1988 that are still contributing actively to GCC now that have been working on GCC longer than me. For the last few years, I've been working at IBM on the PowerPC compiler. At the moment, I'm working on support for the the new power9 chip that is coming soon..

Neat! I used to follow that PowerPC stuff. Back in the day there was a BeOS Company that was developing a PowerPC OS and maybe got as far as an ATX motherboard. I googled Power 9 and it looks like a beast. With all the future needs of high processing power that wiil be used in "sense and avoid" systems in the air...and self driving cars...we're probably need this type of chip for the video recognition alone. Also need the processor to be designed to tap into the parallel processing of FPGAs.

It's nice to see this forum has some really high power gurus who are willing to help us out...
Reminds me of AVRFreaks.
 
You can get a hint at where the Arduino/Teensyduino architecture-specific objdump program is by enabling "Show verbose output during:" "compilation" in Teensyduino preferences and inspecting the last command line of output where it calls the architecture-specific size program.

For example, from a recent Teensyduino Teensy 3.2 sketch compilation I get:

Code:
/private/var/folders/_s/cmw91gv90cggy7zx6n0452kdb5klj4/T/AppTranslocation/EEA938B5-4C72-40BE-A3C5-34B7DB9DC617/d/Teensyduino.app/Contents/Java/hardware/teensy/../tools/arm/bin/arm-none-eabi-size -A /var/folders/_s/cmw91gv90cggy7zx6n0452kdb5klj4/T/arduino_build_146150/EncoderPolling.ino.elf

If you replace the `-size -A` suffix in`../tools/arm/bin/arm-none-eabi-size -A`with `-objdump -S` you get a command line that should dump your assembly.

The verbose output commands also show your sketch's build directory.
 
Status
Not open for further replies.
Back
Top