GNU Arm Embedded Toolchain

LTO and Code placement

Asked by Mahavir

Hi All,

ARM-GCC-4.9.3

When LTO is enabled, code placement in specific linker sections (specific RAM/FLASH region/range) does not work. E.g. Using __attribute__((section(".mysection"))) for specific function calls is not honoured when LTO is enabled. To workaround this using __attribute__((used, section(".mysection"))) solves the problem. Is that the suggested solution here?

Also, above workaround is not feasible when we have something of below sort in linker script,

.mysection:
 {
              *foobar.o (.text .text.* .rodata .rodata.*)
               *libfoobar.a: (.text .text.* .rodata .rodata.*)
 } > MYREGION

Do we any proposed solutions here?

Thanks.

Question information

Language:
English Edit question
Status:
Answered
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Terry Guo (terry.guo) said : 		#1

Seems it is similar to https://bugs.launchpad.net/gcc-arm-embedded/+bug/1418073. I am trying to reproduce the issue.

Revision history for this message
Terry Guo (terry.guo) said : 		#2

One interesting finding is that if all functions specified to .mysection get inlined, .mysection won't be kept. Is this your case?

Revision history for this message
Mahavir (mahavirpj) said : 		#3

Yes it seems like LTO does in-lining. But isn't that a issue, that a linker attribute is not honoured in the process.

Also, in another case where we might need to put entire library into specific linker section/area (*libfoobar.a: (.text .text.* .rodata .rodata.*)) then that will not work with LTO? Is this known behaviour or something that can be investigated?

Revision history for this message
Terry Guo (terry.guo) said : 		#4

Please see my answer to above bug, with or without lto, here gcc doesn't honor the section attribute. But for other attribute, I have no idea yet.

For your second question, there are several cases that your section/data will be discarded:
1) If the input library isn't lto-enabled and nothing from that library will be used, the normal linker garbage collection can discard unused stuffes. This has nothing to do with lto.

2). If the input library is lto-enabled and nothing from that library will be used, or all used functions are inlined, the lto can discard them. This doesn't impact the correctness of final code. Whether it is an expected behavor is an arguable thing.

If want to keep those unused stuff, better to ask gcc to provide an option. Some other people may want gcc to discard unused stuff to save space.

Revision history for this message
Gabriel Jacobo (gabomdq) said : 		#5

I'm facing a similar issue, without LTO I can do per file placement (by just writing somefile.o in a section in the linker script) just fine. However, when LTO is enabled, the object file names are mangled (they become something like cMapQnB.ltrans537.ltrans.o by the time the reach the linker script processing stage) so there appears to be no effective way to do per file (or per library) placement in this case...is this a known issue? Can it be fixed or worked around?

Revision history for this message
Andre Vieira (andre-simoesdiasvieira) said : 		#6

Hi Gabriel,

Out of the top of my head, --save-temps might lend ya hand here. With --save-temps I think the name of the lto object file will mirror that of the original file and you might be able to use wildcards to work around the ltransNNN issue.

This is just a work around though, I'd need to look further into this for a proper answer.

Cheers,
Andre

Can you help with this problem?

Provide an answer of your own, or ask Mahavir for more information if necessary.

To post a message you must log in.