Hi,
is it possible to generate .OBJ from GCC (not using AVR Studio GCC plugin). In other words, is it possible to debug separate GCC project in AVR Studio?
Hi,
is it possible to generate .OBJ from GCC (not using AVR Studio GCC plugin). In other words, is it possible to debug separate GCC project in AVR Studio?
By "debug" I assume you mean "simulate with AVR Simulator" (in AVR Studio)?
If you want to debug something you want an ELF, not an OBJ. An OBJ is an intermediate file that isn't executable in itself, and hence neither is it debuggable by itself. An ELF is the complete binary executable, the combination of one or several OBJs (actually always several, as the run time lib including start-up code comes from OBJs also), with debug information attached.
You can build your ELF on the command line with your own makefile. Recomment using the Mfile utility that comes with WinAVR to create the makefile. (If you are a masochist, or just like to show off in front of your nerd friends you can build the ELF by typing the commands on the command prompt yourself. :wink:)
Once you have your ELF you simply load it in AVR Studio. At this stage Studio will create a project file - you can't do without it. It will be named
Now you can start a debugging session.
Why isn't AVR Studio's build system usable for you?
[EDIT: Ficksed speling misteaks, and bent out some twisted sentenses]
My first choice was ELF (I created it "copy con >prog.elf" ;-) ), but when you open it from file menu AVR Studio open it as an ordinary text file! So, I recalled times when I used OBJ file for that.
But thanks to your answer I realized that I should use the wizard (this is the only way AVRStudio creates a new project based on binary file). Now I can play with ELF but I can see only disassembly view at the moment. :-/
By the way AVR Studio OBJs are not the same as object files generated by C compiler (don't know what are hey really but you can debug having only OBJ).
AVR Studio is not sufficient for me as a development tool, especially editor. I need to play with some Perl files for my project, so it is nice to have tool that supports other programming languages.
I forgot to generate debug info in the right format. Now I can see source code in simulator.
By the way AVR Studio OBJs are not the same as object files generated by C compiler
don't know what are hey really but you can debug having only OBJ
They are object files, just as any object file created by any variant of the GCC compiler.
No, that is just plain wrong. The OBJ files you get in AVR Studio (with the help of the avr-gcc plug in) are actually made with the avr-gcc C compiler
E.g. in BASCOM you can generate OBJ and then use it for debugging
Avr-gcc creates .o files, not .OBJ files.
.o or .OBJ or whatever - they are all object files, in a compiler-linker too chain context, with the conceptual format I described.
I'm not sure an ordinary object file carry source code information.
Quote:E.g. in BASCOM you can generate OBJ and then use it for debugging
What does BASCOM have to do with compiling with avr-gcc?
[/quote="OP"]
I wholeheartedly concur. Maybe Nard can pass by and explain what BASCOM OBJ files are. (And if they are executable code, rather than "yet to be linked and relocated code" but the BASCOM people still chose to name them "object files" then they had an enormous brain-fart, IMO. For 40+ years the term "object file" has been used to denote what I describe..)OP wrote:
not quite sure you're right.
OK. Sorry. You just go ahead and debug the object files generated from avr-gcc then.. :wink:
"C object" ".o" files does not contain code in absolute address space. The code is relocated after linking.
AVR '.OBJ' files seems to use absolute address space - you can open it in Studio and see the right addresses.
The file extension is immaterial surely (it's only a way of giving us humans a clue as to what a file contains). The fact is that all these files are in ELF format possibly with embedded DWARF2 information. The only question is whether the contents have been linked or not so that the relocation entries have been assigned to fixed addresses. You can use all the ELF processing tools (ar, nm, objdump, objcopy, readelf) on a .o file just as you can on the .elf
If you objdump -S a file and all the CALL and JMP destinations show as 0x0000 then the file has not been linked yet.
You can, of course, confuse yourself and:
avr-gcc -mmcu=atmega16 input.o -lm -o output.o
to link an input.o to produce an output.o that is fixed up. Both are ELF files.
Cliff
AVR '.OBJ' files seems to use absolute address space - you can open it in Studio and see the right addresses.
"C object" ".o" files does not contain code in absolute address space.
Several such object files are then combined into a loadable executable by a linker that does the resolution of externals, and relocation of absolute jumps.
Most every such tool chain I have seen over the years (and it is quite a few) has chosen a default file extension that implies that it is an "object file", lie ".o", ".obj" etc. It seems to me that it is BASCOM that is the exception to the rule, choosing the ".OBJ" extension for something that is not an "object file" in the sense most other tool chains use the term, but rather the loadable executable.
Yes, Cliff. I deliberately avoided mentioning that the object files produced by "any GCC -c" has ELF format, as "ELF" is more often used to denote a loadable and executable file (which also holds data that are of the ELF format).
The discussion is confused enough as it is, IMO.
To confuse it even more :), ELF is an /object/ file format. ;-) So strictly
spoken, both the .o as well as the .elf (or whatever you call it) files are
object files.
The "Nordic Object File Format" that is used by the simple Atmel assembler is
a simplicistic format that was probably invented to get AVR Studio and the
accompanying assembler initially going at all. As this assembler is an
absolute assembler only (no linker involved), the resulting files are
non-relocatable object files. The only tool that understands this format is
AVR Studio itself (to the best of my knowledge).
The only tool that understands this format is
AVR Studio itself (to the best of my knowledge).
If you objdump -S a file and all the CALL and JMP destinations show as 0x0000 then the file has not been linked yet.You can, of course, confuse yourself and:
avr-gcc -mmcu=atmega16 input.o -lm -o output.oto link an input.o to produce an output.o that is fixed up. Both are ELF files.
Cliff
What does the -lm mean in this instance?
I've tried to do this but the linker complains of an undefined reference to 'main' when linking it with the crt startup object. This is expected as there is no main in my assembly file. It already contains all the code necessary to run and I don't want to link it with crtm8.o.
Do you know how I can get rid of the all of the jumps/braches/calls to .+0?
Sorry for the double post, but I solved my problem and figured I post the solution.
I realized that it was using the default linker script to link my program, which tries to pull extra startup code, etc.
So I simply created a custom linker script called linker.x
SECTIONS { . = 0x0; .text : { *(.text) } }
I then ran the following to link:
$ avr-ld -mavr4 -Tlinker.x a.out -o output.o
Now, when I disassemble output.o, instead of seeing all the rjmps/calls to .+0, they show up properly!
I've tried to do this but the linker complains of an undefined reference to 'main' when linking it with the crt startup object. This is expected as there is no main in my assembly file. It already contains all the code necessary to run and I don't want to link it with crtm8.o.Do you know how I can get rid of the all of the jumps/braches/calls to .+0?
http://www.nongnu.org/avr-libc/u...
What does the -lm mean in this instance?
Cliff
BTW if you want a linked program without the C preamble then use -nostartfiles or -nodfaultlibs