Listing file step tries to disassemble data

[TommyMurphyTM1234]

Hope it's OK to post this here at least for initial consideration - I'm not sure if it's actually a plugin issue or something to do with objdump - or maybe simply a misunderstanding on my part.

The GNU RISC-V Cross Create Listing build step calls objdump to generate a list file including disassembly etc. By default the command line is:

objdump --source --all-headers --demangle --line-numbers --wide "riscv-systick-blinky.elf"

However this has the effect of trying to disassemble data as well as code sections. In my case I'm compiling for -march=rv32im -mabi=ilp32 and yet I see this in the list file:

C:\Microsemi\SoftConsole_v5.2.0.7\extras\workspace.examples\riscv-systick-blinky\Debug/../main.c:82
            UART_send(&g_uart, &rx_char, 1);
8000171c:   fee40793            addi    a5,s0,-18
80001720:   00100613            li  a2,1
80001724:   00078593            mv  a1,a5
80001728:   800027b7            lui a5,0x80002
8000172c:   95878513            addi    a0,a5,-1704 # 80001958 <__stack_top+0xffffeff8>
80001730:   f10ff0ef            jal ra,80000e40 <UART_send>
C:\Microsemi\SoftConsole_v5.2.0.7\extras\workspace.examples\riscv-systick-blinky\Debug/../main.c:80
        rx_count = UART_get_rx(&g_uart, &rx_char, 1);
80001734:   fc1ff06f            j   800016f4 <main+0x80>
    ...
80001740:   6568                    flw fa0,76(a0)
80001742:   6c6c                    flw fa1,92(s0)
80001744:   0000006f            j   80001744 <main+0xd0>
80001748:   7274                    flw fa3,100(a2)
8000174a:   7061                    0x7061
8000174c:   000a                    0xa
8000174e:   0000                    unimp
80001750:   0a0d                    addi    s4,s4,3
80001752:   74737953            0x74737953
80001756:   6d65                    lui s10,0x19
80001758:   7420                    flw fs0,104(s0)
8000175a:   6d69                    lui s10,0x1a
8000175c:   7265                    lui tp,0xffff9
8000175e:   4220                    lw  s0,64(a2)
80001760:   696c                    flw fa1,84(a0)
80001762:   6b6e                    flw fs6,216(sp)
80001764:   2079                    jal 800017f2 <__sdata_load+0x2>
80001766:   7845                    lui a6,0xffff1
80001768:   6d61                    lui s10,0x18
8000176a:   6c70                    flw fa2,92(s0)
8000176c:   2e65                    jal 80001b24 <__bss_end+0x1c4>
8000176e:   0a20                    addi    s0,sp,280
80001770:   200d                    jal 80001792 <main+0x11e>
80001772:   6573624f            0x6573624f
80001776:   7672                    flw fa2,60(sp)
80001778:   2065                    jal 80001820 <__data_load+0x20>
8000177a:   6874                    flw fa3,84(s0)
8000177c:   2065                    jal 80001824 <__data_load+0x24>
8000177e:   454c                    lw  a1,12(a0)
80001780:   7344                    flw fs1,36(a4)
80001782:   6220                    flw fs0,64(a2)
80001784:   696c                    flw fa1,84(a0)
80001786:   6b6e                    flw fs6,216(sp)
80001788:   6e69                    lui t3,0x1a
8000178a:   6e6f2067            0x6e6f2067
8000178e:   7420                    flw fs0,104(s0)
80001790:   6568                    flw fa0,76(a0)
80001792:   6220                    flw fs0,64(a2)
80001794:   6472616f            jal sp,800285da <__stack_top+0x25c7a>
80001798:   202e                    fld ft0,200(sp)
8000179a:   6854                    flw fa3,20(s0)
8000179c:   2065                    jal 80001844 <__data_load+0x44>
8000179e:   454c                    lw  a1,12(a0)
800017a0:   2044                    fld fs1,128(s0)
800017a2:   6170                    flw fa2,68(a0)
800017a4:   7474                    flw fa3,108(s0)
800017a6:   7265                    lui tp,0xffff9
800017a8:   736e                    flw ft6,248(sp)
800017aa:   6320                    flw fs0,64(a4)
800017ac:   6168                    flw fa0,68(a0)
800017ae:   676e                    flw fa4,216(sp)
800017b0:   7365                    lui t1,0xffff9
800017b2:   2020                    fld fs0,64(s0)
800017b4:   7665                    lui a2,0xffff9
800017b6:   7265                    lui tp,0xffff9
800017b8:   2079                    jal 80001846 <__data_load+0x46>
800017ba:   6974                    flw fa3,84(a0)
800017bc:   656d                    lui a0,0x1b
800017be:   6120                    flw fs0,64(a0)
800017c0:   7320                    flw fs0,96(a4)
800017c2:   7379                    lui t1,0xffffe
800017c4:   6574                    flw fa3,76(a0)
800017c6:   206d                    jal 80001870 <__data_load+0x70>
800017c8:   6974                    flw fa3,84(a0)
800017ca:   656d                    lui a0,0x1b
800017cc:   2072                    fld ft0,280(sp)
800017ce:   6e69                    lui t3,0x1a
800017d0:   6574                    flw fa3,76(a0)
800017d2:   7272                    flw ft4,60(sp)
800017d4:   7075                    0x7075
800017d6:   2074                    fld fa3,192(s0)
800017d8:   7563636f            jal t1,80037f2e <__stack_top+0x355ce>
800017dc:   7372                    flw ft6,60(sp)
800017de:   0a0d                    addi    s4,s4,3
    ...

Note the disassembly of data at the end of the file from address 0x80001740 onwards which appears as if it was compressed code.

Now I'm not sure if this data is actually literal pool data in a code section so objdump may know no better than to try to disassemble it? Or if there are some options that the plugin list file generation build step could/should pass to avoid this happening?

Thanks.

[ilg-ul]

Hope it's OK to post this here

Tommy, please use this tracker only for bugs and enhancements; for questions, unless they are of wide audience, please use the project forum.

Now I'm not sure if this data is actually literal pool data in a code section so objdump may know no better than to try to disassemble it? Or if there are some options that the plugin list file generation build step could/should pass to avoid this happening?

my toolchain release includes the gcc manuals. in binutils.pdf there is a separate chapter for objdump, with lots of options, perhaps that would be a good place to start the search.

[TommyMurphyTM1234]

OK - apologies for that. I'll close this one and raise it on the mailing list or riscv or master binutils pages.