binutils-apple/contrib/ at master · theoparis.com/binutils-apple · Tangled

theoparis.com / binutils-apple

0

WIP MachO binutils port assisted by AI I may consider upstreaming this in the future.

0

binutils-apple / contrib /

at master 6 files

Kevin Buettner contrib: Make dg-extract-results.py tolerant of unparseable files 2mo ago

contrib: Make dg-extract-results.py tolerant of unparseable files This commit is for the benefit of GDB, but as the binutils-gdb repository shares the contrib/ directory with GCC, this commit must first be applied to GCC and then copied back to binutils-gdb. When running GDB tests in parallel (make check -j$(nproc)), the consolidated gdb.sum and gdb.log files are produced by contrib/dg-extract-results.py, which merges per-test output files. If any single per-test output file is malformed (e.g., due to a DejaGnu EILSEQ crash, which is how I encountered this problem), the script aborts via self.fatal(). Because this script is invoked via a Makefile command using shell redirection, this causes the top-level output files to be left as empty, zero-byte files, discarding valid results from all other tests. Fix by making the script tolerant of unparseable input files. Wrap each file's parsing in a try/except block. When a file cannot be parsed, emit a warning to stderr and continue processing remaining files. This ensures that crashing tests do not destroy the consolidated output for the entire parallel build. Tested on Fedora 44 using the GCC testsuite (make check-gcc -j$(nproc)). The consolidated results are produced correctly with no regressions. This commit fixes this GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34147 contrib/ChangeLog: * dg-extract-results.py: Show warnings instead of erroring out when encountering an unparseable file.

2 months ago

check_GNU_style.py

[pre-commit] Add check-gnu-style I got a review comment [1] because I forgot to do "space before paren". I realized I forgot to run check_GNU_style.py, a script from the GCC repo, which warns about things like this. [ The python script has been around since 2017 (and an earlier version written in shell script since 2010). ] So for this change in gdb/gdb.c: ... - return gdb_main (&args); + return gdb_main(&args); ... we get: ... $ ./contrib/check_GNU_style.py <(git diff) === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === gdb/gdb.c:38:17: return gdb_main(&args); ... Add a pre-commit hook to do this automatically. This copies two files from the GCC repo to root-level contrib, and adds a wrapper script gdb/contrib/check-gnu-style-pre-commit.sh (checked with shellcheck). The wrapper script is setup to not fail on violations, so the messages are informational at this point. I'm not sure all checks are 100% applicable to our coding style. The python script check_GNU_style.py has two dependencies: unidiff and termcolor, which users need to install themselves. The check is added at the pre-commit stage. I also considered post-commit, and I'm still not sure what is the better choice. As with all pre-commit checks, if the check is not to your liking, you can use SKIP=check-gnu-style to skip it. In summary, with the new pre-commit check we get: ... $ git commit -a -m "style error" black...............................................(no files to check)Skipped flake8..............................................(no files to check)Skipped isort...............................................(no files to check)Skipped codespell...........................................(no files to check)Skipped check-include-guards................................(no files to check)Skipped check-gnu-style.........................................................Passed - hook id: check-gnu-style - duration: 0.04s === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === gdb/gdb.c:38:17: return gdb_main(&args); tclint..............................................(no files to check)Skipped black...............................................(no files to check)Skipped flake8..............................................(no files to check)Skipped codespell...........................................(no files to check)Skipped check-include-guards................................(no files to check)Skipped codespell-log...........................................................Passed - hook id: codespell-log - duration: 0.19s tclint...............................................(no files to check)Skipped [master $hex] style error ... Approved-By: Simon Marchi <simon.marchi@efficios.com> [1] https://sourceware.org/pipermail/gdb-patches/2025-September/220983.html

9 months ago

check_GNU_style_lib.py

[contrib] Accept _("") and operator() in check_GNU_style_lib.py Currently contrib/check_GNU_style_lib.py warns about '_("foo")', expecting '_ ("foo")' instead: ... $ cat tmp.patch ... +const char * +foo (void) +{ + return _("foo"); +} $ ./contrib/check_GNU_style.py tmp.patch === ERROR type #1: there should be exactly one space between function name \ and parenthesis (1 error(s)) === test.c:4:10: return _("foo"); $ ... However '_("")' is an exception [1] to the rule, so skip the ERROR in this case. Likewise for 'operator()', which seems common enough: ... $ find gdb* -type f \ | egrep -v '/testsuite/|ChangeLog' \ | xargs grep "::operator()" \ | wc -l 27 ... for example in gdb/dwarf2/read.c: ... dwo_file_hash::operator() (const dwo_file_up &file) const noexcept ... [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Gettext_macro

8 months ago

dg-extract-results.py

contrib: Make dg-extract-results.py tolerant of unparseable files This commit is for the benefit of GDB, but as the binutils-gdb repository shares the contrib/ directory with GCC, this commit must first be applied to GCC and then copied back to binutils-gdb. When running GDB tests in parallel (make check -j$(nproc)), the consolidated gdb.sum and gdb.log files are produced by contrib/dg-extract-results.py, which merges per-test output files. If any single per-test output file is malformed (e.g., due to a DejaGnu EILSEQ crash, which is how I encountered this problem), the script aborts via self.fatal(). Because this script is invoked via a Makefile command using shell redirection, this causes the top-level output files to be left as empty, zero-byte files, discarding valid results from all other tests. Fix by making the script tolerant of unparseable input files. Wrap each file's parsing in a try/except block. When a file cannot be parsed, emit a warning to stderr and continue processing remaining files. This ensures that crashing tests do not destroy the consolidated output for the entire parallel build. Tested on Fedora 44 using the GCC testsuite (make check-gcc -j$(nproc)). The consolidated results are produced correctly with no regressions. This commit fixes this GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34147 contrib/ChangeLog: * dg-extract-results.py: Show warnings instead of erroring out when encountering an unparseable file.

2 months ago

dg-extract-results.sh

contrib: sync dg-extract-results.{sh,py} with GCC Sync the dg-extract-results.{sh,py} scripts with GCC, up to commit 4e9104ae5455a3c02c2a7e07f52e6bc574cc761d. This extends the dg-extract-results scripts to handle GDB's 'unexpected core files' count. contrib/ChangeLog: * dg-extract-results.py: Handle GDB's unexpected core file count. * dg-extract-results.sh: Likewise. Reviewed-By: Keith Seitz <keiths@redhat.com>

1 year ago

Import mklog.py from gcc repo I've been using the mklog utility from the gcc repo for a while to generate skeleton of ChangeLog entries. It recently got a rewrite as a Python script. Unfortunately, to find the repository root, and eventually to find in which ChangeLog file each entry goes, the new script assumes it is located in the same git repository that it generates ChangeLog entries for. This means that if you make a change in the gcc source tree and run mklog.py from that same source tree, it works. But if you make changes in your ~/src/binutils-gdb tree and run ~/src/gcc/contrib/mklog.py, it won't work. IIRC, the old script required that you ran it with the project's root directory as the CWD. The simplest way to fix this is to import the script in binutils-gdb and use it from there. It's also nice because we can use it without having a clone of the gcc repo. I also thought of adding a "--root" switch to the script to override the project's base directory. However: 1) It is more work. 2) If the script still lives in the gcc repo, it's less convenient than having it in binutils-gdb. This patch imports contrib/mklog.py from the gcc repo, revision c560591408440f441b8b327f5b41f9328d20b67b. contrib/ChangeLog: * mklog.py: New file, imported from gcc. Note: the ChangeLog entry above was generated using `git show | ./mklog.py`! Change-Id: I955592ce6397681986dc82a09593c32d8b8de54f

5 years ago