Basic support for TI Arm Clang toolchain

[mon]

The linker identifies itself with a custom name on stderr when given the --version flag:

fatal error: invalid option:  --version
tiarmclang: error: tiarmlnk command failed with exit code 1 (use -v to see invocation)

And the error for invalid options is different:

fatal error: invalid option:  --allow-shlib-undefined

Note two spaces between the colon and the bad flag.

Compiler successfully identified afterwards as:

C compiler for the host machine: C:/ti/ti-cgt-armllvm_2.1.2.LTS\bin/tiarmclang.exe (clang 2.1.2 "TI Arm Clang Compiler 2.1.2.LTS")
C linker for the host machine: C:/ti/ti-cgt-armllvm_2.1.2.LTS\bin/tiarmclang.exe ld.lld unknown version

As noted in the changelog, b_lundef=false and b_asneeded=false are both needed due to being unsupported flags, not sure if this is fine as-is (Google indexes meson changelogs pretty well) or whether they should be automagically disabled inside the LLD linker class.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.79%. Comparing base (675b47b) to head (82e9dca).

❗ Current head 82e9dca differs from pull request most recent head fd626e3. Consider uploading reports for the commit fd626e3 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11421      +/-   ##
==========================================
- Coverage   70.43%   68.79%   -1.65%     
==========================================
  Files         219      207      -12     
  Lines       48781    45332    -3449     
  Branches    11606     9378    -2228     
==========================================
- Hits        34359    31185    -3174     
+ Misses      11980    11751     -229     
+ Partials     2442     2396      -46     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mon]

Bumping with a rebase against current master. Anything needed from me?

[eli-schwartz]

or whether they should be automagically disabled inside the LLD linker class.

Either that or via a custom subclass. ;)

Is this something that users will need to distinguish between TI arm clang vs regular clang using cc.get_linker_id()?

[mon]

Either that or via a custom subclass. ;)

Is this something that users will need to distinguish between TI arm clang vs regular clang using cc.get_linker_id()?

Have you got any strong leanings toward a custom subclass for a cleaner implementation, or is this OK as is?

I think embedded compilation is specific enough that nobody will really be compiling a piece of code with two different embedded linkers. In the case of tests, I expect people would use meson.is_cross_build() to adjust build logic.

[eli-schwartz]

Have you got any strong leanings toward a custom subclass for a cleaner implementation, or is this OK as is?

Not really. I just mentioned it for the sake of argument. I am not sure whether it matters or doesn't matter.

[mon]

Bah, the more I think about it the more "you must specify these options" feels like a lazy hack fix, especially since I made it work "properly" for the TI CGT compiler. I'll add a TiLLVMDynamicLinker with ID ld.ti and do it right.

[mon]

Although, as I think a little more - is there any worth to making LLVMDynamicLinker have a function such as supports_argument, which is then extended to gate --no-undefined and --as-needed in addition to --allow-shlib-undefined? I initially didn't consider it because I feel like it might secretly hide any silly bugs with flags (eg: misspelled), especially since those flags are usually pretty specific for those that use them.

[mon]

Alright, I'm happy with this flag detection now - no modifications needed to any meson.build files, and supports any future compilers missing these standard flags. As discussed before, I'm fine with not having a special linker ID for TI Arm Clang, so this is ready to merge if you're happy with it!

[tristan957]

@eli-schwartz what's the status on this PR? Seems like it might've just been forgotten.

[mon]

Rebased to latest master, seeing C6000 support got merged I hope this one can as well! (pending test runs)

[mon]

Sorry for the bump, is there anything I can do to help move this along? If there are missing tests that might make it easier from your end, additional documentation etc.

[jpakkane]

Sorry for the delay.

[tristan957]

Thanks for bumping it @mon

[mon]

Thank you so much!