toolchains: Compiler versioning adds --print-memory-usage

[W-M-R]

Summary

1. The "-print-memory-usage" parameter introduced in GNU Link version 2.26

Impact

unnecessary

Testing

unnecessary

[nuttxpr]

[Experimental Bot, please feedback here]

This PR appears not to fully meet the NuttX requirements, specifically in the "Impact" and "Testing" sections. While the summary provides a reasonable explanation of why the change is necessary, it lacks crucial details:

• Missing Details in Summary: The summary explains the problem (lack of --print-memory-usage support) but doesn't explain what the PR changes to fix it (the how). What is the dynamic detection mechanism? How is it implemented? What code is modified?

• Insufficient Impact Assessment: Simply stating "unnecessary" for impact is not acceptable. Even if the user-facing functionality doesn't change, there are potential impacts. For instance:

  • Impact on build: Does the dynamic detection add any build steps or dependencies? Does it change the build output in any way (even if just log messages)?
  • Impact on compatibility: Does this change affect compatibility with any existing tools or scripts that rely on the build process? Does the dynamic detection mechanism work across all supported build environments?
  • Impact on hardware: Even if the intention is no hardware impact, explicitly confirming this is important. Does the change introduce any overhead or code size increases that could affect resource-constrained targets?

• Missing Testing Information: "Unnecessary" is also insufficient for the Testing section. Even if the change seems minor, testing is crucial. At a minimum, you should demonstrate:

  • Build Host: Specify the build host used to validate the change.
  • Target(s): Specify the target platform(s) where the change was tested.
  • Test Procedure: Describe the steps taken to verify the dynamic detection mechanism. Did you test with a toolchain that does support --print-memory-usage and one that doesn't?
  • Test Results: Show some output, even if just a build log snippet demonstrating the dynamic detection working as expected.

In short, the PR description needs to be more comprehensive and provide specific details about the change, its impact, and the testing performed. Even small changes require thorough documentation to ensure code quality and maintainability.