• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 54 subscribers
  • Views 760 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Trampolines root for slow linker?

Dave Smith62
Intellectual 405 points


Hello,

We define –b and then even --symdebug:none. There is little improvement in speed, and we saw warnings like

“relocation from function "xxx" to symbol overflowed; the 31-bit relocated address 0xdff96810 is too large to encode in the 25-bit signed PC-Relative field”

appear many times (for ARMv5).

With symdebug:none, it is not evident that the relocations might cause the long link time. It is likely that the linker needed to insert trampolines many times, which at each time entails somewhat a reshuffle of the data structure, and probably the debugging information maintained alongside, so the speed is that slow.

  • Q1: at compiling time, is there a way to force generating trampoline calls instead of PC-relative call? I searched and didn’t find that in the document for ARM compiler.
  • Q2: I tried partial(incremental) linking but this helped little. Any other ways to speed up linker?
  • Q3: TI has many different lines of processors. The compiler at grammar level follow http://processors.wiki.ti.com/index.php/TI_Compilers_and_Industry_Standards, and I believe they at binary level follow IA-64 conventions.  Could you list any open-source tools that could like the object files? Do they handle details like trampolines, and do they have proven quality?

Dave

  • 0
    TI__Guru* 84285 points
    relocation overflow warnings/errors have nothing to do with the speed of the linker. It could possibly be caused by a bug in the linker, or a problem with the linker command file; either way, it's probably more urgent to deal with that issue before the linker speed.

    To get a better handle on your issue, please tell us which version of the compiler your are using for which target. The compiler version is not the same as the CCS version. I gather you are using ARM, are you also using C6000 and C2000? When you say it is slow, how long exactly does it take, and how big is the target footprint? Could you post your linker map file?

    Q1: I don't think there is a way to force trampoline generation. Trampolines are more of a last-resort thing. Using trampolines allows the linker to be optimistic when placing text sections. I don't think the linker will thrash while generating trampolines; for the most part, placement is once-and-done before trampolines start.

    Q2: partial/incremental linking will definitely not help with speed for ELF/EABI. If you are aleady compiling with --symdebug:none, there's not much you can do to improve DWARF speed.

    Q3: Sure, the ELF format, as well as the EABI, for each target is published. Indeed, our implementation of EABI follows IA-64 to a great degree, as does the ARM AEABI. Please see processors.wiki.ti.com/.../EABI and follow the link labeled "C6000 EABI Specification." You'll also need to get your hands on the ELF specification, which is publicly available. You should be able to use any generic ELF utility to read TI ELF files; for instance readelf or objdump. I'll refrain from comment on open-source tools, as my knowledge of TI-compatible offerings is a bit dated.