avr-objdump ... intermixed source lines disappear

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

I've used avr-objdump as a part of the WinAVR tool chain for a number of projects now and one of my favourite techniques for tricky pieces of code is to have a quick look at the .lss file to see what code the compiler has planted for my questionable 'C'.

But now I'm working on a bootloader project and when I put an absolute base address into the linker to move the text section to the appropriate place ...

LDFLAGS += -Ttext=0x1E000

... the interleaved source lines disappear from the .lss file which makes it a real pain to identify what code is generated by what statement!

The objdump line that the makefile is generating is ...

avr-objdump -h -D -S bootldr.elf > bootldr.lss

I've tried with and without the -D -S options and now I'm stuck.

What I'm trying to do seems reasonable ... so I suspect that I'm missing something.

Has anyone else had this problem?

Mike.

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

You could always just use "make source_file_name.s" to get individual source_file_name.c files converted to their assembler equivalent. As this is done per file before the link the fact that you are relocating .text will have no effect on what you see as a result of this

Cliff

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

Cliff, thanks for the suggestion ... unfortunately "make file.s" seems to generate a fairly naked assembly file without intermixed source lines (there maybe other options that I can invoke to get it to produce something more easy on the brain/eye).

I've got some more information now on the specifics of the avr-objdump problem.

If I set a base address of 0x00000 then everything is fine, just as I would expect, if I increase the base address up the flash everything stays ok until I reach the 0x0FFFF boundary.

Once code goes over that we seem to loose the intermixed source lines ... hence my bootloader section of 0x1E000 is missing the source and becomes far less readable.

I'm wondering if this is a bug that's crept in with the expanding memory present in the larger devices -- in particular the ATmega128 which I'm currently using.

I wonder if anyone else has come across it or knows the details of how avr-objdump handles these devices?

Mike.

Ps. After thinking about it I thought that maybe telling avr-objdump what the processor/architecture was might help so I tried specifying "-m avr5" ... but no joy, it didn't seem to make any difference to the problem :(

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

That's actually a shortcoming of the 16-bit elf/dwarf2 debugging information which is currently emitted by WinAVR's toolchain. You could try switching to the now-deprecated stabs/ext-coff debug format which doesn't seem to suffer from this limitation.

Alternatively, you may prefer to wait for the 32-bit elf/dwarf2 format to come on stream. That needs to be coordinated between the WinAVR maintainer (EW) and the AVR Studio development team to ensure compatibility.

In the mean time, I think I've read somewhere that the AtmanAVR distribution of the AVR toolchain has been patched to emit 32-bit elf/dwarf2 debug information, and it can be installed over top of an existing WinAVR installation. But I don't know if you'll be able to debug code compiled with that toolchain under AVR Studio.

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

lfmorrison wrote:
But I don't know if you'll be able to debug code compiled with that toolchain under AVR Studio.

You won't - that's why I reverted the Atman 4.x stuff back to 3.x on my machine.

Cliff

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

Thanks guys for all the input ... I think I understand now what's going on well enough for me to derive a workaround that will keep me moving forward.

From what you've written it looks as though the problem is not in avr-objdump as I had thought, but rather earlier, in the production of the .elf file. It also looks as though that may well be fixed at some unspecified point in time in the future.

Over the years (and I've been at this game since the late 70's) I've always fought shy of incircuit emulators and debuggers prefering to rely on defensive code and a built in strategy for testing/debugging.

So the main purpose I have for seeing the intermixed source/assembler is to increase the size of my comfort zone when I'm working with any code constructs that I feel uncertain of.

To workaround the present limitations, for those occasions when I want to see the code in detail, I'll just set the base address back to zero, inspect the code and then put it back to what it should be.

Many thanks for all the time/effort and input.

Mike.

Cliff, BTW ... I like the signature, its a few years since I saw that one last.