| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I ran codespell on the gdb directory and fixed a number of minor
problems. In a couple cases I replaced a "gdb spelling" (e.g.,
"readin") with an English one ("reading") where it seemed harmless.
I also added "Synopsis" as an accepted spelling.
gdb is nowhere near codespell-clean.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
I noticed a typo in the testsuite, twice: gdbsever. Fix these.
Codespell doesn't detect it, so add a new file
gdb/contrib/codespell-dictionary.txt that contains a gdbsever->gdbserver
entry, and update gdb/contrib/setup.cfg to use it.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While reading through gdb-patches backlog after a return
from PTO, I noticed that a newly added file was licensed
with "MIT", and that license was not listed in Fedora's
gdb.spec file. [Fedora no longer supports "effective"
licenses.]
That lead me to this simple script which generates a list
of all the newly added files between two given commits and
scans these files for licenses.
Example usage:
bash$ cd /path/to/binutils-gdb/gdb
bash$ ./contrib/license-check-new-files.sh -s gdb-15-branchpoint gdb-16-branchpoint
Scanning directories gdb*/...
gdb/contrib/common-misspellings.txt: no longer in repo?
gdb/contrib/spellcheck.sh: no longer in repo?
gdbsupport/unordered_dense.h: MIT
I don't think anything in here is Fedora- or RPM-specific,
so I'd like to submit this for consideration for inclusion
in contrib/. I believe other distros may find it useful.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It would be useful to tell codespell to ignore blocks of code.
A feature ignore-multiline-regex exists, which can be used to implement this:
...
$ codespell --ignore-multiline-regex \
'codespell:ignore-begin.*codespell:ignore-end'
...
Unfortunately there's a bug in codespell where using -w in
combination with --ignore-multiline-regex drops all newlines in the updated
file.
In absence of a fix, commit this solution disabled, to locally document the
current state of this feature.
|
|
Now that we're using codespell to check spelling in gdb files, can we use
codespell to bring this spelling warning:
...
$ echo usuable | codespell -
1: usuable
usuable ==> usable
...
to:
...
$ git commit -a -m "Usuable stuff"
...
?
First, let's look at a straightforward commit-msg hook implementation:
...
- id: codespell
name: codespell-commit-msg
verbose: true
always_run: true
stages: [commit-msg]
...
installed using:
...
$ pre-commit install -t commit-msg
...
When trying the commit, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
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
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
codespell............................................(no files to check)Skipped
codespell-commit-msg.....................................................Failed
- hook id: codespell
- duration: 0.06s
- exit code: 65
.git/COMMIT_EDITMSG:1: Usuable ==> Usable
check-include-guards.................................(no files to check)Skipped
$
...
The commit was aborted, but the commit message is still there:
...
$ cat .git/COMMIT_EDITMSG
Usuable stuff
...
We can retry and edit the commit message to clean up the typo:
...
$ git commit -e -F .git/COMMIT_EDITMSG -a
...
but it's a bit cumbersome.
Furthermore, say we fix a typo and want to document this in the commit log, and
do:
...
$ git commit -m "Fixed typo: useable -> usable" -a
...
This commit cannot succeed, unless we add a codespell ignore tag, which feels
like taking it too far.
Both these problems can be addressed by setting things up in such a way that
the commit always succeeds, and codespell output is shown as a hint.
Ideally, we'd tell to pre-commit to implement this using some setting, but
there doesn't seem to be one.
So we use some indirection. Instead of using native codespell, use a local
hook that calls a script gdb/contrib/codespell-log.sh, which calls pre-commit,
which calls codespell.
Using this approach, we get:
...
$ echo "/* bla */" >> gdb/gdb.c
$ git commit -a -m "Usuable stuff"
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
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.18s
codespell-log-internal...................................................Failed
- hook id: codespell
- exit code: 65
.git/COMMIT_EDITMSG:1: Usuable ==> Usable
[codespell/codespell-log-2 d081bd25a40] Usuable stuff
1 file changed, 1 insertion(+)
$
...
This is obviously convoluted, but it works. Perhaps we can propose a
pre-commit improvement (always_pass) and simplify this eventually.
Checked new script codespell-log.sh with shell-check.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This adds a "-5" flag to cc-with-tweaks, mirroring dwz's "-5" flag,
and also adds a new cc-with-dwz-5 target board.
The "-5" flag tells dwz to use the DWARF 5 .debug_sup section in
multi-file mode.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808
|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
This cleans up the last codespell reports in the Guile directory and
adds gdb/guile to pre-commit.
It also tells codespell to ignore URLs. I think this is warranted
because many URLs don't really contain words per se; and furthermore
if any URL-checking is needed at all, it would be for liveness and not
spelling.
Also I was wondering why the codespell config is in contrib and not
gdb/setup.cfg.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg,
specifically adding files in the skip line.
This allows us to run codespell from the command line on the gdb dir:
...
$ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l
1665
...
without running into warnings in generated files.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and
associated file gdb/contrib/common-misspellings.txt.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add a pre-commit codespell hook for directories gdbsupport and gdbserver,
which are codespell-clean:
...
$ pre-commit run codespell --all-files
codespell................................................................Passed
...
A non-trivial question is where the codespell configuration goes.
Currently we have codespell sections in gdbsupport/setup.cfg and
gdbserver/setup.cfg, but codespell doesn't automatically use those because the
pre-commit hook runs codespell at the root of the repository.
A solution would be to replace those 2 setup.cfg files with a setup.cfg in the
root of the repository. Not ideal because generally we try to avoid adding
files related to subdirectories at the root.
Another solution would be to add two codespell hooks, one using
--config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and
add a third one once we start supporting gdb. Not ideal because it creates
duplication, but certainly possible.
I went with the following solution: a setup.cfg file in gdb/contrib (alongside
codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport.
So, what can this new setup do for us? Let's demonstrate by simulating a typo:
...
$ echo "/* aways */" >> gdbsupport/agent.cc
...
We can check unstaged changes before committing:
...
$ pre-commit run codespell --all-files
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
...
Likewise, staged changes (no need for the --all-files):
...
$ git add gdbsupport/agent.cc
$ pre-commit run codespell
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
...
Or we can try to commit, and run into the codespell failure:
...
$ git commit -a
black................................................(no files to check)Skipped
flake8...............................................(no files to check)Skipped
isort................................................(no files to check)Skipped
codespell................................................................Failed
- hook id: codespell
- exit code: 65
gdbsupport/agent.cc:282: aways ==> always, away
check-include-guards.................................(no files to check)Skipped
...
which makes the commit fail.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Tom Tromey mentioned [1] that the words "invokable" and "useable"
present in codespell-ignore-words.txt should be dropped.
Do so and fix the following typos:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
gdbsupport/common-debug.h:218: invokable ==> invocable
gdbsupport/event-loop.cc:84: useable ==> usable
...
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html
|
|
Ignore the following codespell detection:
...
$ codespell --config gdbserver/setup.cfg gdbserver
gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS
...
by adding SME to codespell-ignore-words.txt.
|
|
In Gentoo, we configure our gdb with `--with-pkgversion=` with
"Gentoo VERSION XXXX" where XXX depends on patching (not that we patch
gdb really these days) or vanilla.
Since 71f193a5c1cb02dcde6ac160cdab88e9725862bb, this goes wrong, yielding
```
/usr/bin/gdb-add-index: 25: Syntax error: "(" unexpected
```
with lines 25-26 being:
```
PKGVERSION=(Gentoo 9999 vanilla)
VERSION=17.0.50.20250319-git
```
Quote both assignments (PKGVERSION by necessity, VERSION for consistency
or symmetry).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
|
|
Update the gdb-add-index script to offer --help and --version options.
The script currently accepts the argument '-dwarf-5' with a single
leading '-'. As two '--' is more common for long options, the
preferred argument form is now '--dwarf-5', the docs have been
updated, and the new help text uses this form.
For backward compatibility, the old '-dwarf-5' form is still
accepted.
The new arguments are '--help' or '-h', but I also accept '-help' for
consistency with '-dwarf-5'. And likewise for the version argument.
Handling of the gdb-add-index script is done basically the same as for
gcore and gstack; we use config.status to create a .in file within the
build directory, which is then processed by the Makefile to create the
final script.
The difference with gdb-add-index is that I left the original script
as gdb/contrib/gdb-add-index.sh rather than renaming it to something
like gdb/contrib/gdb-add-index-1.in, which is how gcore and gstack are
handled (though they are not in the contrib directory).
The reason for this is that the contrib/cc-with-tweaks.sh script looks
for gdb-add-index.sh within the gdb/contrib/ source directory.
As the only reason we process gdb-add-index.sh into the build
directory is to support the PKGVERSION and VERSION variables, allowing
cc-with-tweaks to continue using the unprocessed version seems
harmless, and avoids having to change cc-with-tweaks.sh at all.
I tested that I can still run tests using the cc-with-gdb-index target
board, and that the installed gdb-add-index script correctly shows a
version number when asked.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running codespell on gdbsupport, we get:
...
$ codespell gdbsupport
gdbsupport/common-debug.h:218: invokable ==> invocable
gdbsupport/osabi.h:51: configury ==> configurable
gdbsupport/ChangeLog-2020-2021:344: ro ==> to, row, rob, rod, roe, rot
gdbsupport/ChangeLog-2020-2021:356: contaning ==> containing
gdbsupport/common.m4:19: configury ==> configurable
gdbsupport/Makefile.am:97: configury ==> configurable
gdbsupport/Makefile.in:811: configury ==> configurable
gdbsupport/event-loop.cc:84: useable ==> usable
gdbsupport/configure:15904: assigment ==> assignment
...
Some of these files we want to skip in a spell check, because they're
generated. We also want to skip ChangeLogs, we don't actively maintain those.
Add a file gdbsupport/setup.cfg with a codespell section, that skips those
files. The choice for setup.cfg (rather than say .codespellrc) comes from the
presence of gdb/setup.cfg.
That leaves invokable, configury and useable. I think configury is a common
expression in our context, and for invokable and useable I don't manage to
find out whether they really need rewriting, so I'd rather leave them alone
for now.
Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in
gdbsupport/setup.cfg.
This makes the directory codespell clean:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
$
...
Because codespell seems to interpret filenames relative to the working
directory rather than relative to the config file, and the filename used in
gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple
invocation doesn't work:
...
$ cd gdbsupport
$ codespell
...
because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt.
We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but
likewise that breaks this invocation:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
...
I can't decide which one is worse, so I'm sticking with
gdb/contrib/codespell-ignore-words.txt for now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
While reviewing changes generated by spellcheck.sh for directory sim, I
noticed two more misspellings:
...
arrithemetic->arithmetic
electricaly->electrically
...
Add them to common-misspellings.txt, and fix them in directory sim.
Tested by rebuilding on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Eli mentioned [1] that given that we use US English spelling in our
documentation, we should use "behavior" instead of "behaviour".
In wikipedia-common-misspellings.txt there's a rule:
...
behavour->behavior, behaviour
...
which leaves this as a choice.
Add an overriding rule to hardcode the choice to common-misspellings.txt:
...
behavour->behavior
...
and add a rule to rewrite behaviour into behavior:
...
behaviour->behavior
...
and re-run spellcheck.sh on gdb*.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
|
|
Fix shellcheck warnings in spellcheck.sh, found using shellcheck v0.10.0.
Ran shellcheck v0.10.0 (on a system with shellcheck version 0.8.0) using this
command from an RFC patch [1]:
...
$ ./gdb/contrib/pre-commit-shellcheck.sh ./gdb/contrib/spellcheck.sh
...
Tested on x86_64-linux
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html
|
|
Since commit 5cb0406bb64 ("[gdb/contrib] Handle capitalized words in
spellcheck.sh"), spellcheck.sh uses '${pat@u}' which is available starting
bash 5.1, and consequently the script breaks with bash 4.4.
Fix this by checking for the bash version, and using an alternative
implementation for bash < 5.1.
Tested on x86_64-linux.
|
|
Add an option --print-dictionary to spellcheck.sh that allows us to inspect
the effective dictionary.
Verified with shellcheck.
|
|
Eli mentioned that "thru" is a widely-accepted shorthand [1].
Skip the "thru->through" rule by adding an overriding identity rule
"thru->thru".
Verified with shellcheck.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213380.html
|
|
The dictionary contains a few entries with capital letters:
...
$ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l
143
...
but they don't look too interesting in the gdb context (for instance,
Habsbourg->Habsburg), so filter them out.
That leaves us with entries looking only like "foobat->foobar", so add
handling of capitalized words, such that we also rewrite "Foobat" to "Foobar".
Tested on aarch64-linux. Verified with shellcheck.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run
gdb/contrib/spellcheck.sh to fix this in a few files.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the
following typos:
...
inheritence -> inheritance
psuedo -> pseudo
succeded -> succeeded
...
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Currently, text adjacent to parentheses is not spell-checked:
...
$ cat tmp.txt
(upto)
$ ./gdb/contrib/spellcheck.sh tmp.txt
$
...
Add handling of parentheses, such that we get:
...
$ ./gdb/contrib/spellcheck.sh tmp.txt
upto -> up to
$
...
Rerun spellcheck.sh, resulting in a few "thru->through" replacements.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Add handling of '.' in gdb/contrib/spellcheck.sh.
While we're at, simplify the sed invocation by using a single s command
instead of 3 s commands.
Also introduce sed_join and grep_join.
Fix the following common misspellings:
...
bandwith -> bandwidth
emmitted -> emitted
immediatly -> immediately
suprize -> surprise
thru -> through
transfered -> transferred
...
Verified with shellcheck.
|
|
Speed up gdb/contrib/shellcheck.sh by caching the grep pattern.
Without cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m2,750s
user 0m0,013s
sys 0m0,032s
...
and with cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m0,192s
user 0m0,022s
sys 0m0,024s
...
Tested on aarch64-linux.
|
|
Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell
check and bail out ASAP with an exit code of 1 if misspelled words were
found, or 0 otherwise.
Verified with shellcheck.
|
|
I forgot to follow up on a review comment and fix the "sofar->so far"
misspelling [1].
Fix this by adding it to gdb/contrib/common-misspellings.txt.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-September/211894.html
|
|
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
|
|
While trying to add more separators here:
...
# Separators: space, slash, tab.
grep_separator=" |/| "
sed_separator=" \|/\|\t"
...
I mistakingly used "|" instead of "\|" in sed_separator.
Factor out new variables grep_or and sed_or, and construct the grep_separator
and sed_separator variables by joining the elements of a list using grep_or
and sed_or.
Verified with shellcheck, and tested by rerunning on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
Fix the following common misspellings:
...
accidently -> accidentally
additonal -> additional
addresing -> addressing
adress -> address
agaisnt -> against
albiet -> albeit
arbitary -> arbitrary
artifical -> artificial
auxillary -> auxiliary
auxilliary -> auxiliary
bcak -> back
begining -> beginning
cannonical -> canonical
compatiblity -> compatibility
completetion -> completion
diferent -> different
emited -> emitted
emiting -> emitting
emmitted -> emitted
everytime -> every time
excercise -> exercise
existance -> existence
fucntion -> function
funtion -> function
guarentee -> guarantee
htis -> this
immediatly -> immediately
layed -> laid
noone -> no one
occurances -> occurrences
occured -> occurred
originaly -> originally
preceeded -> preceded
preceeds -> precedes
propogate -> propagate
publically -> publicly
refering -> referring
substract -> subtract
substracting -> subtracting
substraction -> subtraction
taht -> that
targetting -> targeting
teh -> the
thier -> their
thru -> through
transfered -> transferred
transfering -> transferring
upto -> up to
vincinity -> vicinity
whcih -> which
whereever -> wherever
wierd -> weird
withing -> within
writen -> written
wtih -> with
doesnt -> doesn't
...
Tested on x86_64-linux.
|
|
I came across a table containing common misspellings [1], and wrote a script to
detect and correct these misspellings.
The table also contains entries that have alternatives, like this:
...
addres->address, adders
...
and for those the script prints a TODO instead.
The script downloads the webpage containing the table, extracts the table and
caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
over and over again.
Example usage:
...
$ gdb/contrib/spellcheck.sh gdb*
...
ChangeLog files are silently skipped.
Checked with shellcheck.
Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
test run.
The results of running it are in the two following patches.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
|
|
When the filename quoting change was merged into the AdaCore tree, we
saw a regression in a test setup that uses the DWARF 5 index (that is
running gdb-add-index), and a filename with a space in it.
Initially I thought this was a change in the 'file' command -- but
looking again, I found out that 'file' has worked this way for a
while, and our immediate error was caused by the (documented) change
to "save gdb-index".
While I'm not sure why this test was working previously, it seems to
me that gdb-add-index.sh requires a change to quote the arguments to
"file" and "save gdb-index".
While working on this, though, it seemed to me that multiple other
spots needed quoting for the script to work correctly. And, I was
unable to get quoting working correctly in the objcopy calls, so I
split it into multiple different invocations.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
In emacs, on gdb/contrib/cc-with-tweaks.sh, do:
- M-x whitespace-cleanup,
- M-x mark-whole-buffer and M-x indent-region, and
- and undo the unwanted changes in the header comment.
Only whitespace changes.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Clean up script gdb/contrib/expect-read1.sh by:
- fixing shellcheck warnings,
- using mktemp (which takes TMPDIR into account) instead of a hardcoded
"/tmp/expect-read1.$$.so",
- adding comments, and
- adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh).
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
We have a target board cc-with-gdb-index that uses the gdb-add-index script to
add a .gdb_index index to an exec.
There is however an alternative way of adding a .gdb_index: the index-cache.
Add a new target board cc-with-index-cache.
This is not superfluous for two reasons:
- there is functionality that gdb-add-index doesn't support, but the
index-cache does: the index-cache can add an index to an exec with a
.gnu_debugaltlink (note that when using the cc-with-gdb-index board this
case is quietly ignored), and
- using the index-cache is excercised in only a few test-cases, and having
this target board extends the test coverage to the entire test suite. This
is for instance relevant because the index-cache is written by a worker
thread in the background, so we can check more thoroughly for data races
(see PR symtab/30837).
Tested on x86_64-linux.
Shell script changes checked with shellcheck.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build
from current trunk, but the pathname to the build dir changed and I forgot to
update my test scripts, so the test scripts reverted to using system dwz,
version 0.12.
Consequently, I ran into:
...
(gdb) p ZERO^M
No symbol "ZERO" in current context.^M
(gdb) FAIL: gdb.base/enumval.exp: p ZERO
...
which is due to PR dwz/24468, which was fixed in version 0.13.
Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such
that this situation is detected and we get instead:
...
gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \
0.13 or higher required
...
Tested on x86_64-linux, verified with shellcheck.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to
--strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily
reproduce the PR29277 assert using:
...
$ export STRIP_ARGS_STRIP_DEBUG=--strip-all
$ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
--target_board cc-with-gnu-debuglink"
...
For completeness sake and to avoid confusion about which of the two used strip
invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG,
defaulting to --only-keep-debug.
Script checked with shellcheck, no new warnings added.
Tested on x86_64-linux.
|
|
I noticed that the $want_gnu_debuglink code in gdb/contrib/cc-with-tweaks.sh
uses objcopy instead of $OBJCOPY. Fix this.
Script checked with shellcheck, no new warnings added.
Tested on x86_64-linux.
|
|
I noticed that these files failed to format with Black, because they use
print without parenthesis (which isn't Python 3 compatible).
I don't know if these files are still relevant, but the change is
trivial, so here it is.
Change-Id: I116445c2b463486016f824d32effffc915b60766
|
|
gdb-add-index may trigger debuginfod's first-use notice. The notice
is misleading in this case. It instructs the user to modify .gdbinit
in order to permanently enable/disable debuginfod but gdb-add-index
invokes gdb with -nx which ignores .gdbinit.
Additionally debuginfod is not needed for gdb-add-index since the
symbol file is given as an argument and should already be present
locally.
Fix this by disabling debuginfod when gdb-add-index invokes gdb.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
When running with target board cc-with-gdb-index, we run into:
...
gdb compile failed, warning: Could not find DWO CU \
fission-relative-dwo.dwo(0x1234) referenced by CU at offset 0xc7 \
[in module outputs/gdb.dwarf2/fission-relative-dwo/.tmp/fission-relative-dwo]
UNTESTED: gdb.dwarf2/fission-relative-dwo.exp: fission-relative-dwo.exp
ERROR: failed to compile fission-relative-dwo
...
The problem is that:
- the .dwo file is found relative to the executable, and
- cc-with-tweaks.sh moves the executable to a temp dir, but not
the .dwo file.
Fix this by copying the .dwo file alongside the executable in the temp dir.
Verified changes using shellcheck.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-08-02 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh: Copy .dwo files alongside executable.
|
|
Add target board cc-with-gnu-debuglink.exp that splits off debuginfo into a
seperate .debug file and links to it using .gnu_debuglink.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* contrib/cc-with-tweaks.sh: Handle -l.
gdb/testsuite/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR testsuite/25047
* boards/cc-with-gnu-debuglink.exp: New file.
|
|
PR 27614 shows that gdb-add-index fails to generate the index when its
argument is a symlink.
The following one liner illustrates the reported problem:
$ echo 'int main(){}'|gcc -g -x c -;ln -s a.out symlink;gdb-add-index symlink
gdb-add-index: No index was created for symlink
gdb-add-index: [Was there no debuginfo? Was there already an index?]
$ ls -l
-rwxr-xr-x 1 25712 Mar 19 23:05 a.out*
-rw------- 1 8277 Mar 19 23:05 a.out.gdb-index
lrwxrwxrwx 1 5 Mar 19 23:05 symlink -> a.out*
GDB generates the .gdb-index file with a name that matches the name of
the actual program (a.out.gdb-index here), not the symlink that
references it. The remaining of the script is looking for a file named
after the provided argument (would be 'symlink.gdb-index' in our
example).
gdb/ChangeLog:
PR gdb/27614
* contrib/gdb-add-index.sh: Fix when called with a symlink as an
argument.
gdb/testsuite/ChangeLog:
PR gdb/27614
* gdb.dwarf2/gdb-add-index-symlink.exp: New test.
|
