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

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Looking for example of "Post-build steps"
« on: November 30, 2016, 07:09:00 pm »
Hello,

I want to integrate arm-elf-objdump tool in Code::Blocks, that disassemble an object file.
I want it to runs immediately after build is terminated.
So I considered that "Post-build steps" option is the best location to integrate arm-elf-objdump into processing flow.
But unfortunately I didn't find any document that would help me to resolve the problem.

Anyway I've just tried command-line case for arm-elf-objdump (this way this command is executed from command line).
Without surprises it didn't work ... none disassembly file was generated.
Certainly, the Post-build step command have a particular syntax that probably uses placeholders for input/output and flags.
Is someone aware of such kind of things ?
Thanks.



Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #1 on: November 30, 2016, 08:02:52 pm »
Small correction: the correct name of the command is arm-none-eabi-objdump, the name I used in previous message is from old version of "GNU Tools ARM Embedded"

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #2 on: December 01, 2016, 08:11:38 am »
I'm not sure, if output redirection works directly from the post-build steps.
You probably can call objdump within it's own cmd instance like:

Code: [Select]
cmd /C "arm-elf-objdump ... "
but then you have to set the paths to the compiler executable and the object files. You can use Code::Blocks variables for this (cf. http://wiki.codeblocks.org/index.php/Variable_expansion).
Alternatively, you can put the whole command in a batch file and start it from the post-build steps (again, with the full path to the compiler and object files).

The result of the post-build step execution is shown in the Build Log. Just check the messages there if anything doesn't work as expected.

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #3 on: December 01, 2016, 12:41:28 pm »
Thanks Christobal,

I've tried your suggestion. For the moment it doesn't work.
But I think it's a right way to explore.
At least I've found a conformation of your idea (please, see the screenshot from Block::Code help).
But in order to accelerate workaround, indeed it would be nice to consult with build log.
But I couldn't find it. Have you en idea where it's located ?


Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #4 on: December 01, 2016, 02:54:30 pm »
Post-build messages are displayed in the "Build log" tab or in the generated Build Log html file.

Right at the end of the Build log, you should see something like:

Code: [Select]
Output file is ..\result\Core0.elf with size 406.01 KB
[100.0%] Running target post-build steps
tricore-objcopy -O ihex  ..\result\Core0.elf ..\result\Core0.hex
Process terminated with status 0 (0 minute(s), 9 second(s))
0 error(s), 0 warning(s) (0 minute(s), 9 second(s))
Build log saved as:

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #5 on: December 01, 2016, 03:33:43 pm »
Here is Build log for simplest .c file.
Note, that I introduced deliberately erroneous post-build command, but its action wasn't reflected in Build log.
Any comments ?

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #6 on: December 01, 2016, 04:36:06 pm »
You have to build the project. Not just the file ...

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #7 on: December 01, 2016, 04:57:17 pm »
For the moment I can't build entire projects.
Build generates errors for reasons that I don't understand for the moment.
Without doubt the GNU Tools ARM Embedded tool-chain isn't properly integrated into Code::Blocks ... but it's the subject of my other post published earlier.
I searched for a solution on the forums dedicated to ARM and GCC, but still have no solution.
Here below is the screenshot of project build log.
There is no messages concerned with "post-build", but certainly it's due to the fact that build failed.



Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1463
Re: Looking for example of "Post-build steps"
« Reply #8 on: December 01, 2016, 10:36:52 pm »
There is no messages concerned with "post-build", but certainly it's due to the fact that build failed.
exactly. Post build steps are only executed if the build succeeds. You can create a tool with the tools+ plugin for now, so you can execute the objdump command from the menu with the current file...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10186
Re: Looking for example of "Post-build steps"
« Reply #9 on: December 02, 2016, 09:24:35 am »
Pavel_47: Have you seen this page http://wiki.codeblocks.org/index.php/Adding_support_for_non_C/C%2B%2B_files_to_the_build_system it might be useful for your case.
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #10 on: December 02, 2016, 09:44:05 am »
For the moment I can't build entire projects.
Build generates errors for reasons that I don't understand for the moment.
Without doubt the GNU Tools ARM Embedded tool-chain isn't properly integrated into Code::Blocks ... but it's the subject of my other post published earlier.
It's not an issue with the ARM GCC integration into Code::Blocks. I assume that you are new to Embedded programming...
Compared to PC applications, you have to do some extra work that cannot be provided by the Compiler toolchain, as it is dependent on the device that the code is intended to run. Additionally, on embedded targets there is a startup - code, which provides basically the functionality of an OS Loader. The startup code sets up the environment for your application and requires information from the linker script.
This means (if you want to start from scratch) that you have to provide some low-level routines and settings.

Your problem(s) seem to be:
The linker script doesn't seem to export the boundary addresses for the .bss section (check "target.ld"; it probably needs some adaption according to the processor derivate you want to use). The linker script should also define memory for stack and heap.
The boundary addresses are used by the startup code (crt0.o) to determine all variables that shall be cleared before main is entered. The startup code does also initialize the .data sections with pre-defined values. If you don't know about .bss and .data sections, the GCC linker (LD) manual and google can help you.
You should also check the crt0.S source to get a grasp about what is happening there. Maybe yo need/want to do some adaptions there as well, so you can provide your own crt0.S and pass the -nocrt0 option to the linker.

Your interrupt vector table is missing. It probably needs to be located at a certain position in memory, as the processor will jump to this location on any interrupt or trap event. From there the table should forward jump to your interrupt service routines. Some processors allow to have the interrupt table at an arbitrary (aligned) memory location. For this they provide a special register to set up the interrupt vector base address. The processors user manual can give you more information about the requirements for the interrupt system.
Keep in mind, that the Toolchain doesn't provide you with anything interrupt related (maybe except for example files). It is your job to initialize the Interrupt system if you want to use interrupts.

The _exit function is a stub routine that gives you the possibility to execute target dependent code before the processor halts. For now, it will suffice if you provide an empty routine, which does nothing. In embedded programming it is common that your main routine doesn't return anyway...

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #11 on: December 03, 2016, 02:44:00 pm »
Thanks,

Yes, the problem is in divergence of names used in linker scripts from Code::Blocks and GNU Tools ARM Embedded.
I pointed my compiler executables to GNU Tools ARM Embedded bin directory. So, the linker uses libraries (e.g. crt0.o) also from GNU Tools ARM Embedded.
The crt0.o uses symbols __bss_start__ and __bss_end__, that are properly defined in
C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\share\gcc-arm-none-eabi\samples\ldscripts\gcc.ld

Whereas linker script is called from
C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arm\files\ARM-eval7t\ld\target.ld, where the similar symbols are __bss_start and __bss_end
Its location is defined here (highlighted in yellow):



I've tried to point to "custom" makefile from C:\Program Files (x86)\GNU Tools ARM Embedded\5.4 2016q3\share\gcc-arm-none-eabi\samples\src\cpp that calls gcc.ld script with correct symbols, but build failed:



 

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #12 on: December 03, 2016, 04:47:15 pm »
Here I've just tried to build with toolchain executables from Code::Blocks bin.
I'm not sure if I correctly restituted the initial settings (i.e. executables for compiler, linker, etc.).
Anyway, errors occur:


Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1463
Re: Looking for example of "Post-build steps"
« Reply #13 on: December 03, 2016, 07:11:46 pm »
Quote
Here I've just tried to build with toolchain executables from Code::Blocks bin.
this is bul****  you can't compile arm code with a x86 compiler (you can but you will get errors)
Also x86 don't need linker scripts...

Quote
Whereas linker script is called from
C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arm\files\ARM-eval7t\ld\target.ld, where the similar symbols are __bss_start and __bss_end
Its location is defined here (highlighted in yellow):
No, it calls the linker script:
Code: [Select]
-T ld/targetit calls the linker script from a sub folder of your project. Replace this script file with your appropriate linker file or fix the path in the linker settings

then, if you still get errors don't post screenshots. They waste space. Post the build log (from the build log tap) in code tags (the # symbol in the new post editor)

hope this helps

greetings

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #14 on: December 04, 2016, 10:58:03 am »
Quote
Here I've just tried to build with toolchain executables from Code::Blocks bin.
this is bul****  you can't compile arm code with a x86 compiler (you can but you will get errors)
Also x86 don't need linker scripts...

If I properly understood you, none executable, located in "C:\Program Files (x86)\CodeBlocks\MinGW\bin", can properly process (i.e. compile, link) ARM code. Correct ?
If this is correct in order to work with ARM targets, it's necessary to install "GNU Tools ARM Embedded" toolchain.
If these 2 above statements are correct, one question arises:
What could be the usage of the link scripts, located in  "C:\Program Files (x86)\CodeBlocks\share\CodeBlocks\templates\wizard\arm\files\{ARM_platform_name}\ld\" directories if:
  • these scripts are not compatible with crt0.o library, located in "GNU Tools ARM Embedded" toolchain
  • there is no any linker, located in "C:\Program Files (x86)\CodeBlocks\MinGW\bin", capable to correctly process them
Thanks.

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1463
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

  • Lives here!
  • ****
  • Posts: 1463
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

  • Lives here!
  • ****
  • Posts: 1463
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

  • Lives here!
  • ****
  • Posts: 1463
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: [Select]
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: [Select]
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: [Select]
.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: [Select]
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: [Select]
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.

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #30 on: December 05, 2016, 07:31:29 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.

Yes, it was exactly the case. It was a strange <ExtraCommands> section that obfuscated the execution of the post-build command.
Once it's commented the post-build works. Is it a bug of Code::Blocks ?
Code: [Select]
<Build>
<Target title="default">
<Option output="default/proj1.elf" prefix_auto="0" extension_auto="0" />
<Option object_output="default" />
<Option type="1" />
<Option compiler="arm-elf-gcc" />
<Compiler>
<Add option="-g" />
</Compiler>
<Linker>
<Add directory="C:/Program Files (x86)/GNU Tools ARM Embedded/5.4 2016q3/lib/gcc/arm-none-eabi/5.4.1" />
</Linker>
<!-- <ExtraCommands>
<Add after="arm-none-eabi-objdump -d main1.o &gt; main1.asm" />
</ExtraCommands> -->
</Target>
</Build>

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #31 on: December 05, 2016, 07:55:26 pm »

Yes, it was exactly the case. It was a strange <ExtraCommands> section that obfuscated the execution of the post-build command.
Once it's commented the post-build works. Is it a bug of Code::Blocks ?

The <ExtraCommands> IS the post-build command. You can set it project-global or target specific. If both have a build command set, you can choose whether the target commands shell be appended to the project commands, or if they shall overwrite the project commands.

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #32 on: December 05, 2016, 08:20:51 pm »
The <ExtraCommands> IS the post-build command. You can set it project-global or target specific. If both have a build command set, you can choose whether the target commands shell be appended to the project commands, or if they shall overwrite the project commands.

... project-global or target specific. They both can be set via user interface ?
I see only project post-build.

Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #33 on: December 06, 2016, 07:54:43 am »
According to one of your screenshots, if you select "proj1" in the "Project build options", you can select the project-global build options. These apply usually to all build targets. In your case "default" is the build target. If you select it you can set the target build options. You can also choose how the target options are combined with the project options: They can be appended, prepended, they can replace the project options or they can be ignored (project options only).

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #34 on: December 06, 2016, 11:03:04 am »
Quote
According to one of your screenshots, if you select "proj1" in the "Project build options", you can select the project-global build options. These apply usually to all build targets. In your case "default" is the build target. If you select it you can set the target build options. You can also choose how the target options are combined with the project options: They can be appended, prepended, they can replace the project options or they can be ignored (project options only).

Can you confirm (from the screenshot which follows), that project-global build options and target build options are specified in these locations (blue arrows show how these options can be called).
If this is the case, how to explain why main1.o file suffocated the "project-global" post-build processing if the post-build field in the "target" options is empty.


Offline christobal

  • Multiple posting newcomer
  • *
  • Posts: 41
Re: Looking for example of "Post-build steps"
« Reply #35 on: December 06, 2016, 11:18:02 am »
You can also choose how the target options are combined with the project options: They can be appended, prepended, they can replace the project options or they can be ignored (project options only).
Apparently, I was mistaken. The policies can be applied for e.g. Compiler Settings, Linker Settings etc., but not for the Pre/Post build steps. It seems that the target post-build steps are always executed before the project post-build steps.
Hence, if the target post-build fails, the project post-build will not be executed...

BTW: you can switch between project and target settings by selecting the appropriate entry in the tree on the left-hand side...

Offline Pavel_47

  • Multiple posting newcomer
  • *
  • Posts: 66
Re: Looking for example of "Post-build steps"
« Reply #36 on: December 06, 2016, 12:07:16 pm »
Quote
BTW: you can switch between project and target settings by selecting the appropriate entry in the tree on the left-hand side...
Useful remark. Thanks.

Quote
Apparently, I was mistaken. The policies can be applied for e.g. Compiler Settings, Linker Settings etc., but not for the Pre/Post build steps. It seems that the target post-build steps are always executed before the project post-build steps. Hence, if the target post-build fails, the project post-build will not be executed...
Yes it's the case ... whatever policy I set, both post-builds commands ("project" and "target") are executed, so if one of them is out of date, it must be removed in order to "up-to-date" version runs.

I suppose, that the issue with main1.o occured because I didn't save the project (proj1.cbp) file. That's why even "target post-build" was empty (after my eventual modification), its trace persisted in .cbp file and obfuscated the execution of "project post-build". Isn't it ?
« Last Edit: December 06, 2016, 12:16:25 pm by Pavel_47 »