Hello to all,
I am trying to port the old arm project written in C language and partly in assembly that was compiled with the armcc version 4.1. And I must mention I am not an expert on this, still learning, reading the arm documentation.
The selected new compiler is armclang v6.16. For the assembly code I am still using the armasm.
I have read the migration document and the difference between the old arm v5 and new arm v6 compiler and adapted the compiler/linker flags accordingly.
Everything is ok with the build, but the linking is failing with the error:
Error: L6291E: Cannot assign Fixed Execution Region ... Load Address:0x000179b4. Load Address must be greater than or equal to next available Load Address:0x00017f7c.
and what I could see from the map file, using fromelf for specific object file is that the build output from the armclang is bigger than when I used the older compiler. I did some basic test to compile empty functions and found out the following:
- Using old compiler: building the empty function void and non-void creates function of size 2 bytes when I look in the object file using fromelf or in the map file (Memory map of the image)
- Using the new compiler:
- building the empty function void creates function size of 2 bytes
- building the empty non void function creates function size of 4 bytes. (Very strange why additional 2 bytes).
For the code optimization I am using flag -oz as we are not using LTO in the project.
For the moment I am still trying to find out the reason, also checking if I misses any specific compiler flags.
Thank you for any useful information that could help me solve this mystery, Iknerf
Hi again,
A colleague suggested this article in case you haven't seen it already:https://developer.arm.com/documentation/ka002170/
Regards, Ronan
Hi,
Thanks for this link. I already read it and do all the optimizations there for C, but they don't help. The only thing I have not done is using -Omax and using the LTO as we dont support LTO.
I will now focus into scatter if maybe I can get more free memory for the code.
Have also an idea to use this disassembly and pass it to the armasm, maybe it can do further optimizations.
Best regards and thanks again for all the support, Iknerf
Hello,
From my side I could not do any additional optimization. As I can see it, the armclang produces around 20% bigger code than if I use old compiler armcc. So must now think how to solve this issue, the last resort is to stick with the old, good compiler.
Best regards, Frenk
Hello Ronan,
In addition I also see other errors that did not occur before. In the project for example I see that one parameter is set in 2 different sections and in 2 different files:
file1.c:
Scatter file has both section defined.
If I compile with the old compiler everything is fine, but with the new compiler I get error:
Error: L6200E: Symbol gTableLen multiply defined (by SysTest.o and PatchTable.o).
Should I maybe for this create a new post?
With regards, Frenk
That seems like a reasonable linker error. I'm surprised the older tools do not catch it?
So this is actually not possible? Or is there any way to do it like that?
I thought that because they are different sections, its something like having:
void func(void) {
int dummy = 0;
if (<condition>) {
// and here we are now using this local dummy and there is no problem with build.
}
No, the symbol will exist across the entire image.
Does it link if you declare them as static?
Hi Ronan,
Sadly its not working, but still have few ideas to try.
Did you get any additional news regarding the code optimization if I use armclang?
Thanks for your time and support, Iknerf
I removed some unused code, just to at least build and prepare the image. I hope that later we found some solution how I can decrease the code using the armclang.
I did not change the scatter file and when build is completed a post processing is being done, just to verify that everything is ok. But apparently linker puts the XO section on wrong place. As I see first 2 sections are placed ok and then the 3rd one is placed too far away. I tried manually to set the address using ABSOLUTE in the scatter file and the got following address:
Error: L6244E: Exec region ER_FLASH_LIB address (0x00200228) not aligned on a 256 byte boundary.I then added ALIGN 4 parameter, but the error is still there.Sadly as I found out I cant use the parameter --no_legacyalign as it seems its deprecated.
I am now going through armlink user guide if maybe I missed something. I really hope that the new armlink does not have this fixed inside for the XO sectionScatter file is as following:
FLASH 0x00200000 0x30000{FLASH_FUNC_TABLE +0 FIXED { *(FLASH_FUNC_TABLE_LENGTH, +First) *(FLASH_FUNC_TABLE_PAYLOAD) *(FLASH_FUNC_TABLE_CRC, +Last) }
ER_FLASH_PATCH +0 FIXED { *(FLASH_PATCH_LENGTH, +First) *(FLASH_PATCH_PAYLOAD) *(FLASH_PATCH_CRC, +Last) }
FLASH_CODE +0 FIXED{ *(FLASH_CODE_LENGTH, +First) .ANY (+RO) *(FLASH_CODE_CRC, +Last) }
...
Thanks for any advice, Iknerf
Hi Frenk
This is probably beyond the scope of what I can provide here - we would likely need reproducible examples to advise further.
Can you raise an official support case from the support menu above?
At the moment the armlink alignment is solved by using the deprecated flag --legacyalign and change in the scatter file: ER_FLASH_LIB AlignExpr(+0, 4) FIXED
Best regards, Iknerf
I solved the problem by using the deprecated armlink flag --legacyalign and adapting the line in the scatter file: ER_FLASH_LIB AlignExpr(+0, 4) FIXED :-)Now build is failing as there I have some old embedded assembly functions defined as __asm and using PRESERVE8, ... So I need to check if armclang has some flag to support the old syntax so that I dont have to change everything.
I solved the positioning problem by passing deprecated flag --legacyalign to the armlink and change the line in scatter file to the :ER_FLASH_LIB AlignExpr(+0, 4) FIXED
Now I am getting syntax errors for embedded assembly functions in the C. Like __asm is not recognized, PRESERVE8 invalid. So I hope there is a flag I can use that armclang will support old syntax as otherwise I would need to correct all the embedded assembly functions :(
VERY STRANGE, Lot of my replies are gone. What is happening to the forum?
This is the last reply I had saved.
Hey just to answer the first question. One of our moderation tools looks for repetitive text within content as a spam prevention tool. Sometimes this means content with code blocks gets flagged.
I have approved the post if you want to keep it in this thread.
Thanks
Oli
Arm Community Manager
Hello Oliver,
Thank you very much for information and very quick response
Yes keep it in thread, Iknerf