<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/scripts/clang-tools, branch v6.1.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.1.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-03-26T22:20:25+00:00</updated>
<entry>
<title>gen_compile_commands: fix invalid escape sequence warning</title>
<updated>2024-03-26T22:20:25+00:00</updated>
<author>
<name>Andrew Ballance</name>
<email>andrewjballance@gmail.com</email>
</author>
<published>2024-02-14T01:23:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6ce8cc5e6251229d5239d141d0e5102a0ffa1c7f'/>
<id>urn:sha1:6ce8cc5e6251229d5239d141d0e5102a0ffa1c7f</id>
<content type='text'>
[ Upstream commit dae4a0171e25884787da32823b3081b4c2acebb2 ]

With python 3.12, '\#' results in this warning
    SyntaxWarning: invalid escape sequence '\#'

Signed-off-by: Andrew Ballance &lt;andrewjballance@gmail.com&gt;
Reviewed-by: Justin Stitt &lt;justinstitt@google.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts: handle BrokenPipeError for python scripts</title>
<updated>2023-03-17T07:50:31+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2023-01-12T02:30:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=42d9fb70770f07bc98003f2897c7cda9b0ac0372'/>
<id>urn:sha1:42d9fb70770f07bc98003f2897c7cda9b0ac0372</id>
<content type='text'>
[ Upstream commit 87c7ee67deb7fce9951a5f9d80641138694aad17 ]

In the follow-up of commit fb3041d61f68 ("kbuild: fix SIGPIPE error
message for AR=gcc-ar and AR=llvm-ar"), Kees Cook pointed out that
tools should _not_ catch their own SIGPIPEs [1] [2].

Based on his feedback, LLVM was fixed [3].

However, Python's default behavior is to show noisy bracktrace when
SIGPIPE is sent. So, scripts written in Python are basically in the
same situation as the buggy llvm tools.

Example:

  $ make -s allnoconfig
  $ make -s allmodconfig
  $ scripts/diffconfig .config.old .config | head -n1
  -ALIX n
  Traceback (most recent call last):
    File "/home/masahiro/linux/scripts/diffconfig", line 132, in &lt;module&gt;
      main()
    File "/home/masahiro/linux/scripts/diffconfig", line 130, in main
      print_config("+", config, None, b[config])
    File "/home/masahiro/linux/scripts/diffconfig", line 64, in print_config
      print("+%s %s" % (config, new_value))
  BrokenPipeError: [Errno 32] Broken pipe

Python documentation [4] notes how to make scripts die immediately and
silently:

  """
  Piping output of your program to tools like head(1) will cause a
  SIGPIPE signal to be sent to your process when the receiver of its
  standard output closes early. This results in an exception like
  BrokenPipeError: [Errno 32] Broken pipe. To handle this case,
  wrap your entry point to catch this exception as follows:

    import os
    import sys

    def main():
        try:
            # simulate large output (your code replaces this loop)
            for x in range(10000):
                print("y")
            # flush output here to force SIGPIPE to be triggered
            # while inside this try block.
            sys.stdout.flush()
        except BrokenPipeError:
            # Python flushes standard streams on exit; redirect remaining output
            # to devnull to avoid another BrokenPipeError at shutdown
            devnull = os.open(os.devnull, os.O_WRONLY)
            os.dup2(devnull, sys.stdout.fileno())
            sys.exit(1)  # Python exits with error code 1 on EPIPE

    if __name__ == '__main__':
        main()

  Do not set SIGPIPE’s disposition to SIG_DFL in order to avoid
  BrokenPipeError. Doing that would cause your program to exit
  unexpectedly whenever any socket connection is interrupted while
  your program is still writing to it.
  """

Currently, tools/perf/scripts/python/intel-pt-events.py seems to be the
only script that fixes the issue that way.

tools/perf/scripts/python/compaction-times.py uses another approach
signal.signal(signal.SIGPIPE, signal.SIG_DFL) but the Python
documentation clearly says "Don't do it".

I cannot fix all Python scripts since there are so many.
I fixed some in the scripts/ directory.

[1]: https://lore.kernel.org/all/202211161056.1B9611A@keescook/
[2]: https://github.com/llvm/llvm-project/issues/59037
[3]: https://github.com/llvm/llvm-project/commit/4787efa38066adb51e2c049499d25b3610c0877b
[4]: https://docs.python.org/3/library/signal.html#note-on-sigpipe

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Reviewed-by: Nicolas Schier &lt;nicolas@fjasle.eu&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts/clang-tools: Convert clang-tidy args to list</title>
<updated>2022-10-14T13:32:52+00:00</updated>
<author>
<name>Guru Das Srinagesh</name>
<email>quic_gurus@quicinc.com</email>
</author>
<published>2022-10-11T19:06:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04518e4c2edc78bc90b4651d50c4aad48d09ac23'/>
<id>urn:sha1:04518e4c2edc78bc90b4651d50c4aad48d09ac23</id>
<content type='text'>
Convert list of clang-tidy arguments to a list for ease of adding to
them and extending them as required.

Signed-off-by: Guru Das Srinagesh &lt;quic_gurus@quicinc.com&gt;
Suggested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>kbuild: use obj-y instead extra-y for objects placed at the head</title>
<updated>2022-10-02T09:04:05+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2022-09-24T18:19:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3216484550610470013b7ce1c9ed272da0a74589'/>
<id>urn:sha1:3216484550610470013b7ce1c9ed272da0a74589</id>
<content type='text'>
The objects placed at the head of vmlinux need special treatments:

 - arch/$(SRCARCH)/Makefile adds them to head-y in order to place
   them before other archives in the linker command line.

 - arch/$(SRCARCH)/kernel/Makefile adds them to extra-y instead of
   obj-y to avoid them going into built-in.a.

This commit gets rid of the latter.

Create vmlinux.a to collect all the objects that are unconditionally
linked to vmlinux. The objects listed in head-y are moved to the head
of vmlinux.a by using 'ar m'.

With this, arch/$(SRCARCH)/kernel/Makefile can consistently use obj-y
for builtin objects.

There is no *.o that is directly linked to vmlinux. Drop unneeded code
in scripts/clang-tools/gen_compile_commands.py.

$(AR) mPi needs 'T' to workaround the llvm-ar bug. The fix was suggested
by Nathan Chancellor [1].

[1]: https://lore.kernel.org/llvm/YyjjT5gQ2hGMH0ni@dev-arch.thelio-3990X/

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Tested-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Reviewed-by: Nicolas Schier &lt;nicolas@fjasle.eu&gt;
</content>
</entry>
<entry>
<title>scripts/clang-tools: remove unused module</title>
<updated>2022-09-23T19:30:06+00:00</updated>
<author>
<name>yangxingwu</name>
<email>xingwu.yang@gmail.com</email>
</author>
<published>2022-09-13T04:07:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=237fe72749425f2cd3132bf54fa6b98807c27938'/>
<id>urn:sha1:237fe72749425f2cd3132bf54fa6b98807c27938</id>
<content type='text'>
Remove unused imported 'os' module.

Signed-off-by: yangxingwu &lt;xingwu.yang@gmail.com&gt;
Reviewed-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts/clang-tools: Remove DeprecatedOrUnsafeBufferHandling check</title>
<updated>2022-08-20T17:47:49+00:00</updated>
<author>
<name>Guru Das Srinagesh</name>
<email>quic_gurus@quicinc.com</email>
</author>
<published>2022-08-04T17:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4be72c1b9f298b4ad42391322eaddef64b282716'/>
<id>urn:sha1:4be72c1b9f298b4ad42391322eaddef64b282716</id>
<content type='text'>
This `clang-analyzer` check flags the use of memset(), suggesting a more
secure version of the API, such as memset_s(), which does not exist in
the kernel:

  warning: Call to function 'memset' is insecure as it does not provide
  security checks introduced in the C11 standard. Replace with analogous
  functions that support length arguments or provides boundary checks such
  as 'memset_s' in case of C11
  [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]

Signed-off-by: Guru Das Srinagesh &lt;quic_gurus@quicinc.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>gen_compile_commands: handle multiple lines per .mod file</title>
<updated>2022-06-29T02:43:13+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2022-06-28T01:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a4ab14e1d8fe83cc1ed8910b788117ec2ed25179'/>
<id>urn:sha1:a4ab14e1d8fe83cc1ed8910b788117ec2ed25179</id>
<content type='text'>
scripts/clang-tools/gen_compile_commands.py incorrectly assumes that
each .mod file only contains one line. That assumption was correct when
the script was originally created, but commit 9413e7640564 ("kbuild:
split the second line of *.mod into *.usyms") changed the .mod file
format so that there is one entry per line, and potentially many lines.

The problem can be reproduced by using Kbuild to generate
compile_commands.json, like this:

    make CC=clang compile_commands.json

In many cases, the problem might be overlooked because many subsystems
only have one line anyway. However, in some subsystems (Nouveau, with
762 entries, is a notable example) it results in skipping most of the
subsystem.

Fix this by fully processing each .mod file.

Fixes: 9413e7640564 ("kbuild: split the second line of *.mod into *.usyms")
Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>gen_compile_commands: fix missing 'sys' package</title>
<updated>2021-09-19T01:13:03+00:00</updated>
<author>
<name>Kortan</name>
<email>kortanzh@gmail.com</email>
</author>
<published>2021-09-08T03:28:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ec783c7cb2495c5a3b8ca10db8056d43c528f940'/>
<id>urn:sha1:ec783c7cb2495c5a3b8ca10db8056d43c528f940</id>
<content type='text'>
We need to import the 'sys' package since the script has called
sys.exit() method.

Fixes: 6ad7cbc01527 ("Makefile: Add clang-tidy and static analyzer support to makefile")
Signed-off-by: Kortan &lt;kortanzh@gmail.com&gt;
Reviewed-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
</content>
</entry>
<entry>
<title>gen_compile_commands: extract compiler command from a series of commands</title>
<updated>2021-09-02T23:17:20+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2021-08-19T00:57:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=265264b814c2121513eab2e1cffe196502af0961'/>
<id>urn:sha1:265264b814c2121513eab2e1cffe196502af0961</id>
<content type='text'>
The current gen_compile_commands.py assumes that objects are always
built by a single command.

It makes sense to support cases where objects are built by a series of
commands:

  cmd_&lt;object&gt; := &lt;command1&gt; ; &lt;command2&gt;

One use-case is that &lt;command1&gt; is a compiler command, and &lt;command2&gt;
an objtool command.

It allows *.cmd files to contain an objtool command so that any change
in it triggers object rebuilds.

If ; appears after the C source file, take the first command.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
</content>
</entry>
<entry>
<title>gen_compile_commands: prune some directories</title>
<updated>2021-02-16T13:23:56+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2021-02-11T16:11:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=585d32f9b0532ca2407943edec163c23191de488'/>
<id>urn:sha1:585d32f9b0532ca2407943edec163c23191de488</id>
<content type='text'>
If directories are passed to gen_compile_commands.py, os.walk() traverses
all the subdirectories to search for .cmd files, but we know some of them
are not worth traversing.

Use the 'topdown' parameter of os.walk to prune them.

Documentation about the 'topdown' option of os.walk:
  When topdown is True, the caller can modify the dirnames list
  in-place (perhaps using del or slice assignment), and walk() will
  only recurse into the subdirectories whose names remain in dirnames;
  this can be used to prune the search, impose a specific order of
  visiting, or even to inform walk() about directories the caller
  creates or renames before it resumes walk() again. Modifying
  dirnames when topdown is False has no effect on the behavior of
  the walk, because in bottom-up mode the directories in dirnames
  are generated before dirpath itself is generated.

This commit prunes four directories, .git, Documentation, include, and
tools.

The first three do not contain any C files, so skipping them makes this
script work slightly faster. My main motivation is the last one, tools/
directory.

Commit 6ca4c6d25949 ("gen_compile_commands: do not support .cmd files
under tools/ directory") stopped supporting the tools/ directory.
The current code no longer picks up .cmd files from the tools/
directory.

If you run:

  ./scripts/clang-tools/gen_compile_commands.py --log_level=INFO

then, you will see several "File ... not found" log messages.

This is expected, and I do not want to support the tools/ directory.
However, without an explicit comment "do not support tools/", somebody
might try to get it back. Clarify this.

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Acked-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
</content>
</entry>
</feed>
