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?
Generating AVR Studio .OBJ in AVR GCC
Author
Message
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.
Quote:
By the way AVR Studio OBJs are not the same as object files generated by C 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 (guess why it's called the avr-gcc plugin).
Quote:
don't know what are hey really but you can debug having only OBJ
Equally wrong. They are object files, just as any object file created by any variant of the GCC compiler. That is, they hold binary machine code, but with references to externals not yet resolved, and absolute jumps not yet relocated. You cant use anything like that for debugging purposes. If you had only an OBJ file, eg emanating from your main.c, how would the startup code be executed? Eg, where would the stack pointer be set up? What would call your main()? What would copy literal string constants from flash to RAM? Etc etc.
Quote:
They are object files, just as any object file created by any variant of the GCC compiler.
hmmm, not quite sure you're right. E.g. in BASCOM you can generate OBJ and then use it for debugging - you can even see the basic source code. I'm not sure an ordinary object file carry source code information.
Quote:
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
Avr-gcc creates .o files, not .OBJ files.
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?
Steve wrote:
Avr-gcc creates .o files, not .OBJ files.
Oh, come on Steve... OP chose to use the term OBJ (without any dot, mind you) so I continued with that. Just read it as "object files".
.o or .OBJ or whatever - they are all object files, in a compiler-linker too chain context, with the conceptual format I described.
OP wrote:
I'm not sure an ordinary object file carry source code information.
No, it is not sure. But if you compile with debug info generation then it does. (It does not contain the source code - it contains information about the source code. You just build a project and then move the sources somewhere else before starting a debug session. Notice how the debugger now says it can not find the sources. Think about that for a while..)
Quote:
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.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101136 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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
mogor wrote:
AVR '.OBJ' files seems to use absolute address space - you can open it in Studio and see the right addresses.
What's an "AVR '.OBJ'" file? Is it a file produced by BASCOM? If so, then you might well be correct, but I would call them "BASCOM '.OBJ' files".
Quote:
"C object" ".o" files does not contain code in absolute address space.
Most any tool-chain's object files does not contain what you call "code in absolute address space". Be it a C, FORTRAN or COBOL compiler from the 70's, an Ada or Pascal compiler from the 80's, a C++ compiler from the 90's, they generally produce code with non-resolved externals and absolute jumps not relocated.
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.
Last Edited: Tue. Nov 10, 2009 - 09:50 AM
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).
Quote:
The only tool that understands this format is
AVR Studio itself (to the best of my knowledge).
I suspected that :-)
clawson wrote:
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:
Quote:
$ 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!
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101136 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Quote:
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?
Eh?? If there is no main() this is not a complete C program so what would be the point of the .o's being linked to give the CALL/JMPs absolute addresses. That only needs to take place when you finally link the .o's to something providing main(). I assume you are building the .o's to make a .a? In that case you only want to compile the .c's to .o's but there's no point using avr-ld - that will come later when the library you build is finally linked against some main() code that invokes one or more of the .a functions. If you are building libraries then read this:
http://www.nongnu.org/avr-libc/u...
Quote:
What does the -lm mean in this instance?
Once you've read that page it'll hopefully be obvious what -lm means but the bottom line is that whenever you use -l
Cliff
BTW if you want a linked program without the C preamble then use -nostartfiles or -nodfaultlibs