avr-objdump not mixing source code

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

I have cases where avr-objdump -S is not mixing source code with disassembly. Some procedures in a source file are shown properly mixed, while others list the source code in one place and the disassembly in another.

It appears that this may be happening when the order of procedures in the object file is different from the source. I am using C++ and these are class methods. They seem to be in the object file in random order.

I am using the latest AVR Studio with the GCC plug-in and the latest WinAVR. Is this a known problem? Is there a work-around or plan to fix it?

BTW, is there any way to add the -C switch to avr-objdump in the makefile built by the GCC plug-in?

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

Try building wihtout optimisation - the re-ordering is because it's being optimised.

Cliff

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

Turning off optimizations would not be helpful. I want to look at the disassembly to check the quality of the optimized code.

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

Then make the .i files - don't rely on objdump of the ELF that is several layers away from the Asm the c compiler generated.

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

I don't know what ".i files" are. I reviewed GCC options and didn't find one that adds mixed assembly/source output.

Currently I usually find what I'm looking for in the avr-objdump disassembly, but if I have trouble I load it into the AVR Studio debugger which always seems to get the source in the right place.

Except for the bug in avr-objdump, it makes perfect sense to rely on the fully linked object code that the processor will actually execute. If I could find the source for avr-objdump I might try to fix it myself.

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

> I don't know what ".i files" are.

I think Cliff meant .s files -- the compiler-generated assembly code.

.i files would refer to preprocessed C source code, something that's
sometimes also useful to find hidden gotchas, but not in this case.

> Except for the bug in avr-objdump, it makes perfect sense to rely on
> the fully linked object code that the processor will actually
> execute. If I could find the source for avr-objdump I might try to
> fix it myself.

The source code to objdump is part of the GNU binutils.

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

Needless to say Jörg is spot on. I did indeed mean .s and not .i (though both can be created using an Mfile generated Makefile and both are very illuminating - but for different reasons)

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

I've looked at the source for objdump, and I understand the problem (which affects all targets) and how to fix it. However, learning the build process and setting it up is more than I'm willing to take on. If there's someone else interested in helping fix this who is already set up to build, I can provide a proposed (untested) fix.

I solved the problem for myself by writing a filter (in C++ using MS Visual Studio) that inserts the source, using source line info from avr-objdump -l.

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

Can you describe the problem and your suggested fix? You could
also attach the fix (as the output from diff -u).

I don't see what's so complicated about compiling it though. It's
nothing more but

./configure --target=avr [--prefix=/wherever/it/should/go/into]
make all install

Jörg Wunsch

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