diff --git a/scripts/Kconfig.toolchain b/scripts/Kconfig.toolchain
index 01b49fa5d6be..a99d875489ee 100644
--- a/scripts/Kconfig.toolchain
+++ b/scripts/Kconfig.toolchain
@@ -144,6 +144,25 @@ config CC_HAS_ASSUME
 config CC_HAS_NO_PROFILE_FN_ATTR
 	def_bool $(success,echo '__attribute__((no_profile_instrument_function)) int x();' | $(CC) -x c - -c -o /dev/null -Werror)
 
+# Beware of two problems when using cc-option in Kconfig compared to Kbuild
+#
+# 1. cc-option in Kbuild tests the provided flags with all previously added
+#    CFLAGS, whereas cc-option in Kconfig only tests the provided flags with a
+#    small, constant set of additional flags.  If a flag (e.g., '-mfoo')
+#    depends on another (e.g, '-fbar') to function properly, the dependency
+#    must be included in the cc-option call (e.g, '-fbar -mfoo').
+#
+# 2. Bit and endianness flags ('-m32', '-m64', '-mbig-endian', and
+#    '-mlittle-endian') are not present in Kconfig cc-option checks because
+#    they may be included in KBUILD_CFLAGS / KBUILD_CPPFLAGS based on the
+#    finalized configuration result. This can result in inconsistent results
+#    when probing toolchains that support either option, as the toolchain's
+#    configured default tested in Kconfig may not support the tested flag but
+#    the post-configuration result in Kbuild would.
+#
+#    In general, prefer adding truly generic compiler flags to avoid this
+#    pitfall.
+
 config CC_OPT_ZERO_INIT_PADDING_BITS
 	def_string "$(cc-option-str,-fzero-init-padding-bits=all)"