Generating AVR Studio .OBJ in AVR GCC

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 _elf.aps.

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]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I forgot to generate debug info in the right format. Now I can see source code in simulator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Nov 10, 2009 - 09:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The only tool that understands this format is
AVR Studio itself (to the best of my knowledge).

I suspected that :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.o

to 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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 then the linker will look for a file called "lib.a" and attempt to link with it. In this example ="m" so the linker will attempt to link with libm.a which is the AVR specific maths library (it doesn't hurt to always specify this because if no maths are used nothing gets linked but on the occasion that maths are used this ensures that the hand engineered AVR specific maths functions in libm.a are used rather than the generic crap in libgcc.a)

Cliff

BTW if you want a linked program without the C preamble then use -nostartfiles or -nodfaultlibs