Author Topic: Looking for example of "Post-build steps"  (Read 42470 times)

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Looking for example of "Post-build steps"
« Reply #15 on: December 04, 2016, 12:09:03 pm »
Codeblocks is a IDE, not a compiler nor a compiler framework. The compiler shipped with the installer is only for convenient and it is only a mingw-tdm compiler for windows applications. But you can use Codeblocks with a dozens other compilers. If you want develop ARM code you need an arm compiler provided by your microprocessor manufacture. There are hundreds of different compilers for arm cores out there. Codeblocks can not provide executables for any of this. The same thing is with the linker script. The path you posted is the path to the template of the new project wizard. This is only provided for convenience. Every processor needs his own linker script and your manufacturer provides you with the appropriate linker script. You have to replace the linker script found in your project directory with the right linker script. The Codeblocks dev can not provide any support on this because the environment is simply to large (count alone the endless manufacturer like Atmel TI...).

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #16 on: December 04, 2016, 12:36:31 pm »
I've tried your suggestion. It works ! Thanks.
Two errors disappeared, only one remains (probably I should try with another linker script, where Reset_Handler is defined):

-------------- Build: default in proj1 (compiler: GNU GCC Compiler for ARM)---------------

arm-none-eabi-g++.exe -L"C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\lib\gcc\arm-none-eabi\5.4.1" -o default\proj1.elf default\src\main.o default\src\main1.o  -s -Wl,-Map,map.txt -mtune=arm7tdmi -T ld/gcc.ld 
c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol Reset_Handler; defaulting to 00000000
c:/program files (x86)/gnu tools arm embedded/5.4 2016q3/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/lib\libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x2c): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
3 error(s), 0 warning(s) (0 minute(s), 0 second(s))

 
Concerning linker script / compiler interdependence issue (i.e. my previous question), can you confirm that following statement is correct:
The linker scripts provided in "C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arm\files\{ARM_platform_name}\ld\" are compatible with at least one of the "hundreds of different compilers for arm cores" (or none at all and should be edited to use with a particular compiler).

Thanks

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Looking for example of "Post-build steps"
« Reply #17 on: December 04, 2016, 01:14:01 pm »
The linker scripts provided in "C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arm\files\{ARM_platform_name}\ld\" are compatible with at least one of the "hundreds of different compilers for arm cores" (or none at all and should be edited to use with a particular compiler).
The linker script is mainly processor dependent, not compile/linker dependent (in the form that 90% of the arm compiler/linker out there are based on the gnu environment). Learn what the linker script do and you will answer this question by your own... The main purpose of the linker script is to tell the linker where the ram/ flash, interrupt handler are located in the processor, and this has nothing to do with the compiler but all with the processor....


Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #18 on: December 04, 2016, 01:34:58 pm »
Sure, linker script is related to mcu memory management.
But the set of execution startup routines (crt0.o) from a particular toolchain use symbol names proper to this particular toolchain that may (or may not) coincide with theirs counterparts from another toolchain. As these symbols are declared in linker script, there must an accord between a particular linker script and a particular toolchain. Isn't it ?

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #19 on: December 04, 2016, 05:28:48 pm »
Finally it works.
Employing some tricks, I've get project built.
Probably the boot code (.elf file) is nonoperational, but at least project is built that allows to check the post-build concept.
Here is post-build command that generates disassembly file in the project target src sub-directory:



And here is build log:

-------------- Build: default in proj1 (compiler: GNU GCC Compiler for ARM)---------------

Target is up to date.
Running project post-build steps
cmd /C arm-none-eabi-objdump -d default\src\main.o > default\src\main_asm.txt
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 0 warning(s) (0 minute(s), 0 second(s))


One question remains: if there are multiple .o files in TARGET\src, how to modify the post-build command in order to take into account all .o files ?
Thanks.


Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Looking for example of "Post-build steps"
« Reply #20 on: December 04, 2016, 07:06:05 pm »
One question remains: if there are multiple .o files in TARGET\src, how to modify the post-build command in order to take into account all .o files ?

You can use squirrel scripting for this: http://wiki.codeblocks.org/index.php/Scripting_Code::Blocks

http://wiki.codeblocks.org/index.php/Variable_expansion#Script_expansion

greetings

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #21 on: December 04, 2016, 07:48:27 pm »
One question remains: if there are multiple .o files in TARGET\src, how to modify the post-build command in order to take into account all .o files ?

You can use squirrel scripting for this: http://wiki.codeblocks.org/index.php/Scripting_Code::Blocks

http://wiki.codeblocks.org/index.php/Variable_expansion#Script_expansion

greetings


That wouldn't be my preferred solution.
If you want assembly files for all compiled modules, just use the GCC compiler switch -save-temps and get rid of the post-build step.

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #22 on: December 04, 2016, 08:38:34 pm »
One question remains: if there are multiple .o files in TARGET\src, how to modify the post-build command in order to take into account all .o files ?

You can use squirrel scripting for this: http://wiki.codeblocks.org/index.php/Scripting_Code::Blocks

http://wiki.codeblocks.org/index.php/Variable_expansion#Script_expansion

greetings

Thanks. Quite tricky solution. Nevertheless I've made some attempts.
I didn't find a way how to integrate such script as a file and tried it "inline".
To see how it works I've just integrated a piece of code into pre-build section that prints all files in project.
It works fine, but for my task I need to access to target directory (i.e. default) to process .o files.
For the moment I didn't find a corresponding function from the list:

http://wiki.codeblocks.org/index.php/Scripting_commands




Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: Looking for example of "Post-build steps"
« Reply #23 on: December 04, 2016, 11:14:16 pm »
it would be much more readable if you post the code and the log in code tags... Also it would save loading time/ data and space on the server

Quote
I didn't find a way how to integrate such script as a file and tried it "inline".
you can try the dofile command: http://squirrel-lang.org/squirreldoc/stdlib/stdiolib.html#global-symbols But i am not sure if this is embedded in codeblocks

Quote
t works fine, but for my task I need to access to target directory (i.e. default) to process .o files.
Can't you use hard coded paths? If you use standard templates from codeblocks the o files are always at the same sub direcotry... Or what exact information do you need?

hope this helps
greetings

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #24 on: December 05, 2016, 12:14:27 pm »
Can't you use hard coded paths? If you use standard templates from codeblocks the o files are always at the same sub direcotry... Or what exact information do you need?

I didn't find any function that accept some kind of "coded path" as input parameter.
Otherwise how to iterate (i.e. execute for loop) trough the content of the target sub-directory where .o files are located ?
What information I need ...
Well, I need to get access to the target sub-directory and process all .o files that are located there with objdump command.
I see that script allows such kind of things. The problem is to obtain the handle to target sub-directory.
Actually, using GetProjectManager(), GetActiveProject(), I can obtain the handle to the project source files (.c, .S, .h), but not the obj (.o) ones.

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #25 on: December 05, 2016, 02:09:35 pm »
That wouldn't be my preferred solution.
If you want assembly files for all compiled modules, just use the GCC compiler switch -save-temps and get rid of the post-build step.

I've tried -save-temps for a quite simple source file (please see the code below)
Code
short checksum_v1(int *data);
int main (void) {
    int data[64];
    int checksum = checksum_v1(data);
return 0;
}

short checksum_v1(int *data)
{
    unsigned int i;
    int sum = 0;
    for (i = 0; i < 64; i++)
    {
        sum += *(data++);
    }
    return (short)sum;
}


#ifndef __NO_SYSTEM_INIT
void SystemInit()
{}
#endif

void _exit(int status)
{
}


Here is output of arm-none-eabi-objdump command (file main.asm, 616 bytes):
Code
default\src\main.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <checksum_v1>:
   0: e3a03000 mov r3, #0
   4: e2801c01 add r1, r0, #256 ; 0x100
   8: e4902004 ldr r2, [r0], #4
   c: e1510000 cmp r1, r0
  10: e0833002 add r3, r3, r2
  14: 1afffffb bne 8 <checksum_v1+0x8>
  18: e1a00803 lsl r0, r3, #16
  1c: e1a00840 asr r0, r0, #16
  20: e12fff1e bx lr

00000024 <SystemInit>:
  24: e12fff1e bx lr

00000028 <_exit>:
  28: e12fff1e bx lr

Disassembly of section .text.startup:

00000000 <main>:
   0: e3a00000 mov r0, #0
   4: e12fff1e bx lr

And here is the result of adding of -save-temps compiler option (file main.s 9645 bytes).
Code
	.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.arm
.syntax divided
.file "main.c"
.text
.Ltext0:
.cfi_sections .debug_frame
.section .text.startup,"ax",%progbits
.align 2
.global main
.type main, %function
main:
.LFB0:
.file 1 "src\\main.c"
.loc 1 2 0
.cfi_startproc
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
.LVL0:
.loc 1 6 0
mov r0, #0
bx lr
.cfi_endproc
.LFE0:
.size main, .-main
.text
.align 2
.global checksum_v1
.type checksum_v1, %function
checksum_v1:
.LFB1:
.loc 1 9 0
.cfi_startproc
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
.LVL1:
.loc 1 11 0
mov r3, #0
add r1, r0, #256
.LVL2:
.L3:
.loc 1 14 0 discriminator 3
ldr r2, [r0], #4
.LVL3:
.loc 1 12 0 discriminator 3
cmp r1, r0
.loc 1 14 0 discriminator 3
add r3, r3, r2
.LVL4:
.loc 1 12 0 discriminator 3
bne .L3
.loc 1 16 0
mov r0, r3, asl #16
.LVL5:
.loc 1 17 0
mov r0, r0, asr #16
bx lr
.cfi_endproc
.LFE1:
.size checksum_v1, .-checksum_v1
.align 2
.global SystemInit
.type SystemInit, %function
SystemInit:
.LFB2:
.loc 1 22 0
.cfi_startproc
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
bx lr
.cfi_endproc
.LFE2:
.size SystemInit, .-SystemInit
.align 2
.global _exit
.type _exit, %function
_exit:
.LFB3:
.loc 1 26 0
.cfi_startproc
@ Function supports interworking.
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
.LVL6:
.loc 1 27 0
bx lr
.cfi_endproc
.LFE3:
.size _exit, .-_exit
.Letext0:
.section .debug_info,"",%progbits
.Ldebug_info0:
.4byte 0x114
.2byte 0x4
.4byte .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.4byte .LASF4
.byte 0xc
.4byte .LASF5
.4byte .LASF6
.4byte .Ldebug_ranges0+0
.4byte 0
.4byte .Ldebug_line0
.uleb128 0x2
.4byte .LASF7
.byte 0x1
.byte 0x8
.4byte 0x55
.byte 0x1
.4byte 0x55
.uleb128 0x3
.4byte .LASF2
.byte 0x1
.byte 0x8
.4byte 0x5c
.uleb128 0x4
.ascii "i\000"
.byte 0x1
.byte 0xa
.4byte 0x69
.uleb128 0x4
.ascii "sum\000"
.byte 0x1
.byte 0xb
.4byte 0x62
.byte 0
.uleb128 0x5
.byte 0x2
.byte 0x5
.4byte .LASF0
.uleb128 0x6
.byte 0x4
.4byte 0x62
.uleb128 0x7
.byte 0x4
.byte 0x5
.ascii "int\000"
.uleb128 0x5
.byte 0x4
.byte 0x7
.4byte .LASF1
.uleb128 0x8
.4byte .LASF8
.byte 0x1
.byte 0x2
.4byte 0x62
.4byte .LFB0
.4byte .LFE0-.LFB0
.uleb128 0x1
.byte 0x9c
.4byte 0xa1
.uleb128 0x9
.4byte .LASF2
.byte 0x1
.byte 0x3
.4byte 0xa1
.uleb128 0xa
.4byte .LASF9
.byte 0x1
.byte 0x4
.4byte 0x62
.byte 0
.byte 0
.uleb128 0xb
.4byte 0x62
.4byte 0xb1
.uleb128 0xc
.4byte 0xb1
.byte 0x3f
.byte 0
.uleb128 0x5
.byte 0x4
.byte 0x7
.4byte .LASF3
.uleb128 0xd
.4byte 0x25
.4byte .LFB1
.4byte .LFE1-.LFB1
.uleb128 0x1
.byte 0x9c
.4byte 0xe7
.uleb128 0xe
.4byte 0x35
.4byte .LLST0
.uleb128 0xf
.4byte 0x40
.4byte .LLST1
.uleb128 0xf
.4byte 0x49
.4byte .LLST2
.byte 0
.uleb128 0x10
.4byte .LASF10
.byte 0x1
.byte 0x15
.4byte .LFB2
.4byte .LFE2-.LFB2
.uleb128 0x1
.byte 0x9c
.uleb128 0x11
.4byte .LASF11
.byte 0x1
.byte 0x19
.4byte .LFB3
.4byte .LFE3-.LFB3
.uleb128 0x1
.byte 0x9c
.uleb128 0x12
.4byte .LASF12
.byte 0x1
.byte 0x19
.4byte 0x62
.uleb128 0x1
.byte 0x50
.byte 0
.byte 0
.section .debug_abbrev,"",%progbits
.Ldebug_abbrev0:
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x55
.uleb128 0x17
.uleb128 0x11
.uleb128 0x1
.uleb128 0x10
.uleb128 0x17
.byte 0
.byte 0
.uleb128 0x2
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0x19
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0x19
.uleb128 0x49
.uleb128 0x13
.uleb128 0x20
.uleb128 0xb
.uleb128 0x1
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0x3
.uleb128 0x5
.byte 0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0x4
.uleb128 0x34
.byte 0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0x5
.uleb128 0x24
.byte 0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.byte 0
.byte 0
.uleb128 0x6
.uleb128 0xf
.byte 0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0x7
.uleb128 0x24
.byte 0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0
.byte 0
.uleb128 0x8
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0x19
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0x19
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x40
.uleb128 0x18
.uleb128 0x2117
.uleb128 0x19
.uleb128 0x1
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0x9
.uleb128 0x34
.byte 0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0xa
.uleb128 0x34
.byte 0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x1c
.uleb128 0xb
.byte 0
.byte 0
.uleb128 0xb
.uleb128 0x1
.byte 0x1
.uleb128 0x49
.uleb128 0x13
.uleb128 0x1
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0xc
.uleb128 0x21
.byte 0
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2f
.uleb128 0xb
.byte 0
.byte 0
.uleb128 0xd
.uleb128 0x2e
.byte 0x1
.uleb128 0x31
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x40
.uleb128 0x18
.uleb128 0x2117
.uleb128 0x19
.uleb128 0x1
.uleb128 0x13
.byte 0
.byte 0
.uleb128 0xe
.uleb128 0x5
.byte 0
.uleb128 0x31
.uleb128 0x13
.uleb128 0x2
.uleb128 0x17
.byte 0
.byte 0
.uleb128 0xf
.uleb128 0x34
.byte 0
.uleb128 0x31
.uleb128 0x13
.uleb128 0x2
.uleb128 0x17
.byte 0
.byte 0
.uleb128 0x10
.uleb128 0x2e
.byte 0
.uleb128 0x3f
.uleb128 0x19
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x40
.uleb128 0x18
.uleb128 0x2117
.uleb128 0x19
.byte 0
.byte 0
.uleb128 0x11
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0x19
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0x19
.uleb128 0x87
.uleb128 0x19
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x6
.uleb128 0x40
.uleb128 0x18
.uleb128 0x2117
.uleb128 0x19
.byte 0
.byte 0
.uleb128 0x12
.uleb128 0x5
.byte 0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0x18
.byte 0
.byte 0
.byte 0
.section .debug_loc,"",%progbits
.Ldebug_loc0:
.LLST0:
.4byte .LVL1
.4byte .LVL3
.2byte 0x1
.byte 0x50
.4byte .LVL3
.4byte .LVL4
.2byte 0x3
.byte 0x70
.sleb128 -4
.byte 0x9f
.4byte .LVL4
.4byte .LVL5
.2byte 0x1
.byte 0x50
.4byte 0
.4byte 0
.LLST1:
.4byte .LVL1
.4byte .LVL2
.2byte 0x2
.byte 0x30
.byte 0x9f
.4byte 0
.4byte 0
.LLST2:
.4byte .LVL1
.4byte .LVL2
.2byte 0x2
.byte 0x30
.byte 0x9f
.4byte .LVL2
.4byte .LFE1
.2byte 0x1
.byte 0x53
.4byte 0
.4byte 0
.section .debug_aranges,"",%progbits
.4byte 0x24
.2byte 0x2
.4byte .Ldebug_info0
.byte 0x4
.byte 0
.2byte 0
.2byte 0
.4byte .Ltext0
.4byte .Letext0-.Ltext0
.4byte .LFB0
.4byte .LFE0-.LFB0
.4byte 0
.4byte 0
.section .debug_ranges,"",%progbits
.Ldebug_ranges0:
.4byte .Ltext0
.4byte .Letext0
.4byte .LFB0
.4byte .LFE0
.4byte 0
.4byte 0
.section .debug_line,"",%progbits
.Ldebug_line0:
.section .debug_str,"MS",%progbits,1
.LASF11:
.ascii "_exit\000"
.LASF1:
.ascii "unsigned int\000"
.LASF7:
.ascii "checksum_v1\000"
.LASF12:
.ascii "status\000"
.LASF10:
.ascii "SystemInit\000"
.LASF0:
.ascii "short int\000"
.LASF9:
.ascii "checksum\000"
.LASF3:
.ascii "sizetype\000"
.LASF8:
.ascii "main\000"
.LASF5:
.ascii "src\\main.c\000"
.LASF2:
.ascii "data\000"
.LASF6:
.ascii "C:\\\\Users\\\\Pavel\\\\Documents\\\\proj_ARM\\\\pr"
.ascii "oj1\000"
.LASF4:
.ascii "GNU C11 5.4.1 20160919 (release) [ARM/embedded-5-br"
.ascii "anch revision 240496] -mcpu=arm7tdmi -g -g -O2 -fno"
.ascii "-common\000"
.ident "GCC: (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]"

While the content of main.asm (output of arm-none-eabi-objdump) is clear and comprehensible, the content of main.s (generated by compiler after adding -save-temps option) is bulky, intricate, difficult to discern the code, related to functions in source file.

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #26 on: December 05, 2016, 02:30:12 pm »
main.s is the interim assembly file that has been generated by the compiler. It contains a lot of information needed by the assembler (e.g. that there is a global symbol named "main", which is a function that has a 2 Byte alignment requirement).
main.asm is just a disassembly file that has been derived from the object file (generated by the assembler).

If you want a full disassembly of your application, maybe you can disassemble the elf file with objdump instead of each object file on it's own?

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #27 on: December 05, 2016, 02:43:21 pm »
main.s is the interim assembly file that has been generated by the compiler. It contains a lot of information needed by the assembler (e.g. that there is a global symbol named "main", which is a function that has a 2 Byte alignment requirement).
main.asm is just a disassembly file that has been derived from the object file (generated by the assembler).

If you want a full disassembly of your application, maybe you can disassemble the elf file with objdump instead of each object file on it's own?
For the moment I don't need to disassembly application, but rather file by file ... to estimate the efficiency of compiled code.
For this purposes the objdump matches perfectly what I need.
The only problem to resolve (before closing this thread) is to find a solution how to process multiple files using objdump.
BlueHazzard suggested interesting approach (based on squirrel scripting), but there are still issues to resolve.


Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #28 on: December 05, 2016, 04:57:52 pm »
Strange "sticky" issue in post-build step is suddenly revealed.
Here is my post-build command (note that input file is main.o):

Code
cmd /C arm-none-eabi-objdump -d $(TARGET_OUTPUT_DIR)src\main.o > $(TARGET_OUTPUT_DIR)src\main.asm

And here is Build log:
Code
Running project pre-build steps
cmd /C echo h\evaluator7t.hld\target.ldsrc\main.csrc\startup_ARMCM7.Ssrc\vectors.S
h\evaluator7t.hld\target.ldsrc\main.csrc\startup_ARMCM7.Ssrc\vectors.S

-------------- Build: default in proj1 (compiler: GNU GCC Compiler for ARM)---------------

arm-none-eabi-gcc.exe -mcpu=arm7tdmi -O2 -Wall -g -fno-common -save-temps -DARM_EVAL7T -D__NO_CTOR_DTOR_SUPPORT__ -g -Isrc -Ih -c src\main.c -o default\src\main.o
src\main.c: In function 'main':
src\main.c:3:11: warning: unused variable 'a' [-Wunused-variable]
     short a = add_v1(3, 4);
           ^
src\main.c: In function '_exit':
src\main.c:20:1: warning: 'noreturn' function does return
 }
 ^
arm-none-eabi-g++.exe -mcpu=arm7tdmi -O2 -Wall -g -fno-common -save-temps -DARM_EVAL7T -D__NO_CTOR_DTOR_SUPPORT__ -g -Isrc -Ih -c src\startup_ARMCM7.S -o default\src\startup_ARMCM7.o
src\startup_ARMCM7.S:7:1: warning: "/*" within comment [-Wcomment]
 /* Copyright (c) 2011 - 2014 ARM LIMITED
 ^
arm-none-eabi-g++.exe -L"C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\lib\gcc\arm-none-eabi\5.4.1" -o default\proj1.elf default\src\main.o default\src\startup_ARMCM7.o  -s -Wl,-Map,map.txt -mtune=arm7tdmi -T ld/gcc.ld 
Output file is default\proj1.elf with size 132.65 KB
Running target post-build steps
arm-none-eabi-objdump -d main1.o > main1.asm
arm-none-eabi-objdump: 'main1.o': No such file
arm-none-eabi-objdump: Warning: '>' is not an ordinary file
arm-none-eabi-objdump: 'main1.asm': No such file
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 4 warning(s) (0 minute(s), 0 second(s))

As you can state from the log, the input file for arm-none-eabi-objdump is no more main.o, but main1.o.
Quite strange ... Ok, I used also main1.o in post-build in the past, but now the input is main.o, not main1.o ... moreover main1.c was removed from project and project was cleaned.

Any comments ?

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #29 on: December 05, 2016, 05:06:47 pm »
Open the project file (.cbp) with a text editor and search for "main1". I guess there are some "remnants" of your tests in the post-build step configuration.