net: Support no-lto option for the network build.

[13627105546]

Add CONFIG_NET_NO_LTO to allow compiling the network stack with -fno-lto. This is useful for avoiding LTO-related issues in the network layer.

Note: Please adhere to Contributing Guidelines.

Summary

This PR adds a new Kconfig option CONFIG_NET_NO_LTO to control Link Time Optimization (LTO) specifically for the network subsystem. When enabled, it appends -fno-lto to the compilation flags for network files in net/Makefile and net/CMakeLists.txt.

This change is introduced to address the following scenarios:

1. Debugging Support: LTO can heavily inline functions and optimize away symbols, making the debugging of complex network protocol stacks difficult. Disabling LTO locally preserves the code structure for easier analysis.

2. Compiler Compatibility: In certain build environments or with specific toolchain versions, enabling LTO globally may trigger internal compiler errors or produce incorrect code for the network stack state machines.

3. Build Performance: Disabling LTO for the network subsystem can reduce the link time and memory usage during the build process on resource-constrained build machines.

This granular control allows users to keep LTO enabled for the rest of the system to maintain performance while disabling it for the network layer if needed for debugging or stability.

Impact

• Impact on user: Users can now optionally disable LTO for the network stack via menuconfig -> Networking Support -> Support no-lto option for the network Makefile.
• Build process: If CONFIG_NET_NO_LTO=y, the -fno-lto flag is added to the CFLAGS for network sources.
• Compatibility: Backward compatible; default is n (disabled), preserving existing behavior.

Testing

• Verification:
  1. Configured with CONFIG_NET_NO_LTO=y.
  2. Verified via make --dry-run that -fno-lto appears in the compilation commands for files under net/.
  3. Configured with CONFIG_NET_NO_LTO=n.
  4. Verified that -fno-lto is absent.
  5. Passed tools/checkpatch.sh.

[anchao]

This is a rather odd requirement:

symbol visibility problems

Symbol visibility should be resolved via the interfaces provided by syscalls. If certain sockets are not supposed to be subject to LTO, we only need to mark these symbols with special attributes.

stack overflow due to aggressive inlining

Stack overflow caused by excessive inlining should be addressed by determining whether stack adjustments are needed based on compilation options and compiler types. Otherwise, the issue may still occur even with LTO disabled when using compilers with strong optimization capabilities.

[13627105546]

This is a rather odd requirement:

symbol visibility problems

Symbol visibility should be resolved via the interfaces provided by syscalls. If certain sockets are not supposed to be subject to LTO, we only need to mark these symbols with special attributes.

stack overflow due to aggressive inlining

Stack overflow caused by excessive inlining should be addressed by determining whether stack adjustments are needed based on compilation options and compiler types. Otherwise, the issue may still occur even with LTO disabled when using compilers with strong optimization capabilities.

I've removed some inaccurate descriptions. Could you please review them again?

[anchao]

If the purpose of this modification is to facilitate debugging, then I have no objections. Alternatively, could we add a DEBUG flag to this config? Anyway, this is not a big deal.

[xiaoxiang781216]

If the purpose of this modification is to facilitate debugging, then I have no objections. Alternatively, could we add a DEBUG flag to this config? Anyway, this is not a big deal.

not only for debugging, the network stack code may need move into TCM to get the best performance on some platform. but the code layout arrangement is impossible with lto.

fixed

[anchao]

If the purpose of this modification is to facilitate debugging, then I have no objections. Alternatively, could we add a DEBUG flag to this config? Anyway, this is not a big deal.

not only for debugging, the network stack code may need move into TCM to get the best performance on some platform. but the code layout arrangement is impossible with lto.

So why not use .a to specified in the linker script? If LTO is disabled, wouldn’t LTO (O3) and LD optimizations be mutually exclusive in some performance-critical scenarios?

[xiaoxiang781216]

If the purpose of this modification is to facilitate debugging, then I have no objections. Alternatively, could we add a DEBUG flag to this config? Anyway, this is not a big deal.

not only for debugging, the network stack code may need move into TCM to get the best performance on some platform. but the code layout arrangement is impossible with lto.

So why not use .a to specified in the linker script? If LTO is disabled, wouldn’t LTO (O3) and LD optimizations be mutually exclusive in some performance-critical scenarios?

.a doesn't work too, it's the limitation of LTO implementation.

[anchao]

If the purpose of this modification is to facilitate debugging, then I have no objections. Alternatively, could we add a DEBUG flag to this config? Anyway, this is not a big deal.

not only for debugging, the network stack code may need move into TCM to get the best performance on some platform. but the code layout arrangement is impossible with lto.

So why not use .a to specified in the linker script? If LTO is disabled, wouldn’t LTO (O3) and LD optimizations be mutually exclusive in some performance-critical scenarios?

.a doesn't work too, it's the limitation of LTO implementation.

Actually, we use .a static libraries for LTO, with full support from the linker script.