Atmel Studio 7.0 - edit Disassembly view

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

Hello Together,

 

I am new here, but i hope you can help me.

 

I´d like to debug an .elf File without having the any source files.

So far it´s no Problem, but the Disassembly i get out of this is very ugly looking.

 

At least i would like to have some indication, when a new function starts.

With the Atmel Studio 4.18 they are always displayed inside the disassembly

 

Yes i know that i could use something like the Online Disassembler to navigate and the

Atmel Disassembly to Debug. But its inconvenient...

 

Is there a possibility read the functions from the .elf File and display them inside the Debug able Disassembly?

 

Thank You!

 

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

The disassembler is clever but it's not THAT clever. It can't really know where functions actually start/end. I guess it could have a stab at anything beyond "RET" but that's not necessarily the boundary for all functions. Because of a thing called "tail optimization" they might end in JMP in fact.

 

I guess a higher level question in this is do you have the legal right to be doing this if you don't have the source?

 

BTW the studio disassembler is very unpleasant indeed. I personally would prefer the output of avr-objdump that will disassemble ELF (.elf or .o files) or even plain Intel hex (.hex)

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

clawson wrote:
The disassembler is clever but it's not THAT clever.

Especially as the AVR itself (i.e. the machine language) has no concept of "function".  If you or the toolchain that is producing the set of machine language instructions decides to implement an abstract concept of "function", then indeed there might be sequences that could be scanned for. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I´d like to debug an .elf File without having the any source files.

And how did this happen? Did you lose the source files?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

"The dog ate my homework" ;-)

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

js wrote:
And how did this happen? Did you lose the source files?

We have our suspicions, but I guess OP >>could<< be trying to troubleshoot a field device with unknown firmware version?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Hello there,

and Sorry for my late reply.

 

To be precise, i do have all the Source and Header Files myself and created this .elf Files with extra debug Information (-g3/g2) and no Optimization(-O0).

I want to create my own Embedded Challenge, to introduce Programmer to Buffer Overflows on a little at90can128.

 

To get them as close to the Hardware as possible I´m not willing on giving them their precious C-Files. ;)

But Id like to give them an easy time on Stepping through the Disassembled Code.

 

I do know that my raw Machine Code is not that clever and i would not expect much, when i disassemble an Hex File.

But the fact that i get more information like my function names etc. from an the onlinedisassembler-Website and even in an older AVR Studio Version,

i th8 it might be possible in the new Versions as well. 

(Not Using the 4.18 anymore because there were a lot of Bluescreens and Bugs getting it work on Win10)

 

Thanks for all the Replies.

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

MrPesti wrote:
But the fact that i get more information like my function names etc. from an the onlinedisassembler-Website and even in an older AVR Studio Version, i th8 it might be possible in the new Versions as well.
But the Studio debugger should be doing that too if it has been built with -g. It can read DWARF2.

 

Remember that the way DWARF2 works is that the -g embeds links back to .c source files and line numbers so if you give them the ELF without the source you lose all the debug info but not the function names:

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>

__attribute__((noinline)) void toggle_output(void) {
                        PORTB = 0xAA;
                        PORTB = 0x55;
}

int main(void) {
                DDRB = 0xFF;
                while (1) {
                        toggle_output();
                }
}
C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -Os -g avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 30

0000006c <toggle_output>:
#include <avr/io.h>

__attribute__((noinline)) void toggle_output(void) {
                        PORTB = 0xAA;
  6c:   8a ea           ldi     r24, 0xAA       ; 170
  6e:   88 bb           out     0x18, r24       ; 24
                        PORTB = 0x55;
  70:   85 e5           ldi     r24, 0x55       ; 85
  72:   88 bb           out     0x18, r24       ; 24
  74:   08 95           ret

00000076 <main>:
}

int main(void) {
                DDRB = 0xFF;
  76:   8f ef           ldi     r24, 0xFF       ; 255
  78:   87 bb           out     0x17, r24       ; 23
                while (1) {
                        toggle_output();
  7a:   0e 94 36 00     call    0x6c    ; 0x6c <toggle_output>
  7e:   fd cf           rjmp    .-6             ; 0x7a <main+0x4>

00000080 <_exit>:
  80:   f8 94           cli

00000082 <__stop_program>:
  82:   ff cf           rjmp    .-2             ; 0x82 <__stop_program>

C:\SysGCC\avr\bin>ren avr.c avr.c.notfound

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 20
  68:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

0000006c <toggle_output>:
  6c:   8a ea           ldi     r24, 0xAA       ; 170
  6e:   88 bb           out     0x18, r24       ; 24
  70:   85 e5           ldi     r24, 0x55       ; 85
  72:   88 bb           out     0x18, r24       ; 24
  74:   08 95           ret

00000076 <main>:
  76:   8f ef           ldi     r24, 0xFF       ; 255
  78:   87 bb           out     0x17, r24       ; 23
  7a:   0e 94 36 00     call    0x6c    ; 0x6c <toggle_output>
  7e:   fd cf           rjmp    .-6             ; 0x7a <main+0x4>

00000080 <_exit>:
  80:   f8 94           cli

00000082 <__stop_program>:
  82:   ff cf           rjmp    .-2             ; 0x82 <__stop_program>

You should find the same behaviour in the AS7 debugger/disassembler.

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

That´s what i expected as well,

 

And when i use the avr-objdump i get a good result:

  

 

But when i Start the debug session in AS7 the same Code looks like this:

 

 

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

Right click the disasm in AS7. If it's like AS4 there will be options to control what is seen/unseen. Perhaps they are just hidden?

 

But seriously, why encourage your students to use the Studio Disasm view anyway? The objdump (which gets piped to LSS files during the build) is always a "better" disassembly anyway.

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

clawson wrote:
why encourage your students to use the Studio Disasm view anyway?

Hey -- why not, if you are going to do -O0 anyway?  What lessons are to be learned about a "good" compiler with that?  No wonder people say "you can only do that in ASM".

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Also, there's a plugin to Atmel Studio called Annotated Assembly File Debugger which allows you to use any file with the debugger. The user guide for it is here.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)