LPCXpresso 8.1.4 garbles disassembly file when using "Binary Utilities->Disassemble" for a .o file

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPCXpresso 8.1.4 garbles disassembly file when using "Binary Utilities->Disassemble" for a .o file

550 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by dariy on Mon May 02 07:51:57 MST 2016
When using GUI Disassembling objects and executables, for a single .o file with including source information, the resulted disassembly file is garbled. Disassembling the .axf file seems to generatr correct .dis file
0 Kudos
6 Replies

452 Views
lpcware
NXP Employee
NXP Employee
bump
0 Kudos

452 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Fri May 06 03:03:03 MST 2016
The actual disassembly of instructions appears to be OK. What you appear to be reporting is the incorrect interleaving of source statements within the disassembly of an object file, when you add the "-S" option to the disassembly command (objdump). Correct?

As far as I can tell from experiments here, this is down to the objdump from the GCC5 package that we ship in LPCXpresso 8.1 having an issue with the handling of debug information when the source file contains forced inlined functions.

If using the other methods of generating an interleaved disassembly don't provide what you need. then if you have an LPCXpresso IDE v8.0 installed on your system, you should be able to workaround this issue in the short term by using the objdump from that installation. To do this, copy the file:

C:\nxp\LPCXpresso_8.0.0_526\lpcxpresso\tools\bin\arm-none-eabi-objdump.exe


to

C:\nxp\LPCXpresso_8.1.4_606\lpcxpresso\tools\bin


I would suggest taking a backup of the original v8.1.4 arm-none-eabi-objdump.exe first.

Regards,
LPCXpresso Support
0 Kudos

452 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by dariy on Wed May 04 11:40:53 MST 2016
My Optimization Level is -O0 (None) for all files.
If you would look into the examples I gave you, you could see the same assembler lines (optimized or not) in all three disassembled files but the source lines are garbled in systick.dis.

Focusing on the source line 73 from systick.c
SysTick_Config(SystemCoreClock / TICKRATE_HZ1);

we can see it in systick.asm at line 1958 in systick.asm as

  73:../example/src/systick.c **** SysTick_Config(SystemCoreClock / TICKRATE_HZ1);
204              .loc 2 73 0
205 000c 054B     ldrr3, .L15
206 000e 1B68     ldrr3, [r3]
207 0010 054A     ldrr2, .L15+4
208 0012 A2FB0323 umullr2, r3, r2, r3
209 0016 DB08     lsrsr3, r3, #3
210 0018 1846     movr0, r3
211 001a FFF7FEFF blSysTick_Config

or at line 879 in periph_blinky.dis as

SysTick_Config(SystemCoreClock / TICKRATE_HZ1);
     350:4b05      ldrr3, [pc, #20]; (368 <main+0x24>)
     352:681b      ldrr3, [r3, #0]
     354:4a05      ldrr2, [pc, #20]; (36c <main+0x28>)
     356:fba2 2303 umullr2, r3, r2, r3
     35a:08db      lsrsr3, r3, #3
     35c:4618      movr0, r3
     35e:f7ff ffc7 bl2f0 <SysTick_Config>

but in systick.dis at line 569 it looks like

  if(IRQn < 0) {
   c:4b05      ldrr3, [pc, #20]; (24 <main+0x24>)
   e:681b      ldrr3, [r3, #0]
  10:4a05      ldrr2, [pc, #20]; (28 <main+0x28>)
  12:fba2 2303 umullr2, r3, r2, r3
    SCB->SHP[((uint32_t)(IRQn) & 0xF)-4] = ((priority << (8 - __NVIC_PRIO_BITS)) & 0xff); } /* set Priority for Cortex-M  System Interrupts */
  16:08db      lsrsr3, r3, #3
  18:4618      movr0, r3
  1a:f7ff fffe bl0 <main>
:exmark:

This is happening only since downloading v8.1.4
0 Kudos

452 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by vtw.433e on Wed May 04 09:58:48 MST 2016
Your files are not garbled. The disassembly of the .o and .axf files seems to produce identical results.

What level of compiler optimization do you have set? If you have anything other than -o0 I would expect there to be a discrepancy, and it getting worse the higher the optimization level, as the compiler is free to move, reorder and remove (unused) code. This is exactly the same as when debugging code with higher levels of optiimization - there is no longer a 1-to-1 relationship between a line of code and what is generated.

These FAQs give a bit more information:
https://www.lpcware.com/content/faq/lpcxpresso/compiler-optimization
https://www.lpcware.com/content/faq/lpcxpresso/optimize-for-debug

I am sure if you try again with -o0 optimization the relationship between the disassembled output and the source lines will be much closer to what you expect.
0 Kudos

452 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by dariy on Wed May 04 09:27:44 MST 2016
Using periph_blinky as an example, you can disassemble the .axf file into periph_blinky.dis or with the global option Wa,-ahlnds get the systick.asm. When you try the Binary Utility to disassemble the systick.o file you get a garbled systick.dis file with Assembler Lines equal to the other files but the  source lines are totally out of whack.
0 Kudos

452 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by vtw.433e on Tue May 03 03:35:51 MST 2016
Works for me. Can you post your .o file and the garbled .dis file?
0 Kudos