This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARMCC: How to generate assembly

I'd like to generate assembly file for a corresponding .c file and I've tried the following which do not work.


armcc.exe -c test.c -o test.o
fromelf.exe -c test.o -o test.s

The above generates test.s but it does not have assembly code for any of the functions defined in the test.c file. I'm looking something similar to

objdump -d test.o

 

Environment

  • Windows PC
  • ARM_Compiler_5.06u6

Parents
  • Ah, ok - I misunderstood what sort of output you wanted to see.  Yes, fromelf will is the tool you want and it is the "-c" flag that gives you disassembly output. 

    I think the problem for your test case is that compiler is being clever.  It's detected that the two functions are static and not referenced, and has performed redundant code elimination.  As a result you end up with an empty file.  It's something I've hit when creating small test cases before, the compiler optimizes code away if it doesn't do anything.

    For your test, a couple of tweaks should stop the compiler optimizing everything out.  Removing static from the function definitions gives:

    ** Section #1 '.text' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
        Size   : 8 bytes (alignment 4)
        Address: 0x00000000
    
        $a
        .text
        WriteS32
            0x00000000:    e12fff1e    ../.    BX       lr
        ReadS32
            0x00000004:    e12fff1e    ../.    BX       lr

    So now the functions are there.  But the compiler has still worked out that the code is ultimately "redundant" and made reduced them to stubs.

    Modifying the functions to reference a global structure, rather than a local one, and having the read function return something:

    ** Section #1 '.text' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
        Size   : 40 bytes (alignment 4)
        Address: 0x00000000
    
        $a
        .text
        WriteS32
            0x00000000:    e59f201c    . ..    LDR      r2,[pc,#28] ; [0x24] = 0
            0x00000004:    e5820000    ....    STR      r0,[r2,#0]
            0x00000008:    e1c210b4    ....    STRH     r1,[r2,#4]
            0x0000000c:    e12fff1e    ../.    BX       lr
        ReadS32
            0x00000010:    e92d4003    .@-.    PUSH     {r0,r1,lr}
            0x00000014:    e1dd00b4    ....    LDRH     r0,[sp,#4]
            0x00000018:    e59d1000    ....    LDR      r1,[sp,#0]
            0x0000001c:    e0800001    ....    ADD      r0,r0,r1
            0x00000020:    e8bd800c    ....    POP      {r2,r3,pc}
        $d
            0x00000024:    00000000    ....    DCD    0

Reply
  • Ah, ok - I misunderstood what sort of output you wanted to see.  Yes, fromelf will is the tool you want and it is the "-c" flag that gives you disassembly output. 

    I think the problem for your test case is that compiler is being clever.  It's detected that the two functions are static and not referenced, and has performed redundant code elimination.  As a result you end up with an empty file.  It's something I've hit when creating small test cases before, the compiler optimizes code away if it doesn't do anything.

    For your test, a couple of tweaks should stop the compiler optimizing everything out.  Removing static from the function definitions gives:

    ** Section #1 '.text' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
        Size   : 8 bytes (alignment 4)
        Address: 0x00000000
    
        $a
        .text
        WriteS32
            0x00000000:    e12fff1e    ../.    BX       lr
        ReadS32
            0x00000004:    e12fff1e    ../.    BX       lr

    So now the functions are there.  But the compiler has still worked out that the code is ultimately "redundant" and made reduced them to stubs.

    Modifying the functions to reference a global structure, rather than a local one, and having the read function return something:

    ** Section #1 '.text' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]
        Size   : 40 bytes (alignment 4)
        Address: 0x00000000
    
        $a
        .text
        WriteS32
            0x00000000:    e59f201c    . ..    LDR      r2,[pc,#28] ; [0x24] = 0
            0x00000004:    e5820000    ....    STR      r0,[r2,#0]
            0x00000008:    e1c210b4    ....    STRH     r1,[r2,#4]
            0x0000000c:    e12fff1e    ../.    BX       lr
        ReadS32
            0x00000010:    e92d4003    .@-.    PUSH     {r0,r1,lr}
            0x00000014:    e1dd00b4    ....    LDRH     r0,[sp,#4]
            0x00000018:    e59d1000    ....    LDR      r1,[sp,#0]
            0x0000001c:    e0800001    ....    ADD      r0,r0,r1
            0x00000020:    e8bd800c    ....    POP      {r2,r3,pc}
        $d
            0x00000024:    00000000    ....    DCD    0

Children