Debugger disassembly missing most source code using GCC 9.3.1

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

I am using Atmel Studio to develop a project using the SAM D21. I recently downloaded GCC 9.3.1 from the ARM web site because I need C++17 (not supported on GCC 6.3.1 that comes with Atmel Studio). When I'm in the Atmel Studio debugger, I find the live disassembly has large swaths of "No source file". The effect of that is to make it very difficult to step and set breakpoints because the debugger can't find the machine code for a given source line. If I switch back to the older GCC, this issue generally goes away. The disassembly produced by objdump has no gaps in the source code, so the info must still be present in the object file.

Here's a specific snippet, first the from the listing file produced by objdump:

            if (ch >= 'A' && ch <= 'Z')
    134e:   0003        movs    r3, r0
    1350:   3b41        subs    r3, #65 ; 0x41
    1352:   b2db        uxtb    r3, r3
    1354:   2b19        cmp r3, #25
    1356:   d801        bhi.n   135c <main+0x1f8>
                ch += 'a' - 'A';
    1358:   3020        adds    r0, #32
    135a:   b2c0        uxtb    r0, r0
            switch (ch)
    135c:   2877        cmp r0, #119    ; 0x77
    135e:   d106        bne.n   136e <main+0x20a>
            case 'w':
                // Trigger WDT
                DEBUG_PRINT("Triggering WDT\n");
    1360:   4864        ldr r0, [pc, #400]  ; (14f4 <main+0x390>)
    1362:   f000 fbd3   bl  1b0c <puts>
                for (;;);
    1366:   e7fe        b.n 1366 <main+0x202>
        iTmp &= ~ID_Right;
    1368:   2205        movs    r2, #5
    136a:   4393        bics    r3, r2
    136c:   e7ab        b.n 12c6 <main+0x162>

But the disassembly in the debugger looks like this:

            if (ch >= 'A' && ch <= 'Z')
0000134E 03.00                 movs r3, r0       
00001350 41.3b                 subs r3, #65      
--- No source file -------------------------------------------------------------
00001352 db.b2                 uxtb r3, r3       
00001354 19.2b                 cmp  r3, #25      
00001356 01.d8                 bhi  #2       
00001358 20.30                 adds r0, #32      
0000135A c0.b2                 uxtb r0, r0       
0000135C 77.28                 cmp  r0, #119         
0000135E 06.d1                 bne  #12      
00001360 64.48                 ldr  r0, [pc, #400]       
00001362 00.f0.d3.fb           bl   #1958        
00001366 fe.e7                 b    #-4      
00001368 05.22                 movs r2, #5       
0000136A 93.43                 bics r3, r2       
0000136C ab.e7                 b    #-170        

Does anyone know if there's been a change in the debugging info emitted by the compiler?  Might there be a GCC command option that could fix this?  I have built tools that dig into DWARF format, so I could potentially make one that modified the debug info if that's what it took.

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

-g -gdwarf2-strict might help...

:: Morten

 

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

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

I wasn't able to get GCC to accept that exact option.  After looking at the GCC docs I tried -gdwarf-2 -gstrict-dwarf, and it didn't help.

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

I wrote a program to dump raw line number info and saw that GCC 9 outputs quite a few more entries that either duplicate a program address or a source line reference (or both).  I expanded that program to filter out the duplicates and write it back to the .elf file in place. This fixed the problem, restoring the ability set breakpoints in source and step by source lines.

 

I have put the program up on GitHub in case anyone else might find it useful: 

 

https://github.com/TimPaterson/FixDebugInfo-GCC-ARM

 

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

Nice!
.
Could you pm me the elf (and if you want, the source)... I'll get the issue logged on our side...

:: Morten

 

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

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.