The compunit symtab backlink of a symtab is never null (the constructor
asserts it), so make symtab::compunit return a reference instead of a
pointer, and have the symtab constructor take the compunit_symtab as a
reference too. Update all callers accordingly.
This came up earlier in review, where a caller would check the result of
`symtab->compunit ()` for nullptr, and I pointed out that it was
unnecessary. Returning a reference makes this clear.
Change-Id: Idf3a6b5fb07a10cd161826ae8a7b826d95bd96c6
Reviewed-By: Tom de Vries <tdevries@suse.de>
Replace all occurrences of:
strcmp (...) == 0
strcmp (...) != 0
!strcmp (...)
0 == strcmp (...)
strcmp (...) directly used as a boolean predicate
with the equivalent expression using streq.
This is for consistency (we already use streq as some places in the
testsuite) but also for clarity. I think that streq is clearer on the
intent than strcmp. It's also a bit shorter.
Change-Id: Ibbf5261b1872c240bc0c982c147f6a5477275a91
Approved-By: Andrew Burgess <aburgess@redhat.com>
I noticed that last_symtab_line is defined as returning an int, but if
the file associated with the symtab cannot be read then the function
returns false!
This commit updates last_symtab_line to return std::optional<int> and
replaces 'return false' with 'return {}'.
I then realised that last_symtab_line isn't actually used very often,
but we do use source_cache::get_line_charpos to perform the same job.
So I went through all uses of ::get_line_charpos and replaced them
with last_symtab_line where appropriate. I think this makes it
clearer what we're actually trying to do.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
This changes the have_*_symbols functions to be methods of
program_space. This version also renames the methods to use "has_"
rather than "have_".
Approved-By: Simon Marchi <simon.marchi@efficios.com>
We have many times the pattern:
current_source_location *loc
= current_source_key.get (pspace);
if (loc == nullptr)
loc = current_source_key.emplace (pspace);
return loc;
I thought it would be nice to have it directly part of registry::key.
Add a try_emplace method, which is like emplace, except that it returns
the existing data, if any. The try_emplace name comes from similar
methods in std::map or gdb::unordered_map
(ankerl::unordered_dense::map).
Replace as many callers as I could find to use it.
Change-Id: I21f922ca065a354f041caaf70484d6cfbcbb76ed
Approved-By: Tom Tromey <tom@tromey.com>
Since we use C++ and not C, I think that we should gradually move to
using references for things that can never be nullptr. One example of
this is the return value of the emplace method.
Change it to return a reference, and (to keep the patch straightforward)
update all callers to take the address. More patches could follow to
propagate the use of references further.
Change-Id: I725539694cf496f8288918cc29d7aaae9aca2292
Approved-By: Tom Tromey <tom@tromey.com>
This replaces a number of uses of 'ptr.reset (xstrdup ())'
with 'ptr = make_unique_xstrdup ()'.
The main motivation for this is that, IMO, it's better to avoid the
reset method when possible.
Approved-By: Andrew Burgess <aburgess@redhat.com>
This updates the copyright headers to include 2026. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Convert symtab to use obstack_new, and have a real constructor. The
filename, filename_for_id and m_compunit, members should really not
change once the symtab has been created, so make these members private
(m_compunit was already private) and set them just once from the
constructor. The set_compunit function has been deleted, and new
getter functions for filename and filename_for_id have been added.
The language is also set at construction time, but can be updated
later, so set the language in the constructor, but retain
symtab::set_language for when the language needs to be updated.
Prior to this patch the symtab was allocated with OBSTACK_ZALLOC which
would zero out the symtab object. With the call to objstack_new
fields in the symtab would no longer be initialised, so I've added
default member initialisation for everything not set in the
constructor.
The interesting changes are in symtab.h, and symfile.c. Everything
else is just updating to handle symfile::filename and
symfile::filename_for_id becoming methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add gdb_rl_tilde_expand, a wrapper around readline's tilde_expand that
returns a gdb::unique_xmalloc_ptr<char>. Change all callers of
tilde_expand to use gdb_rl_tilde_expand (even the couple of spots that
release it immediatly, for consistency). This simplifies a few callers.
The name gdb_tilde_expand is already taken by a home-made implementation
in gdbsupport/gdb_tilde_expand.{h.cc}. I wonder if we could just use
that one instead of readline's tilde_expand, but that's an orthogonal
question. I don't know how they differ, and I don't want to introduce
behavior changes in this patch.
Change-Id: I6d34eef19f86473226df4ae56d07dc01912e3131
Approved-By: Tom Tromey <tom@tromey.com>
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
This changes the compunit_symtab iterator to return references rather
than pointers, following the style of some other recent changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit continues the theme of the previous commit, restoring the
behaviour of forward-search and reverse-search to what it was before
GDB 10, but adds tests to guard the behaviour. I believe this
restored behaviour is inline with the documentation of the two search
commands.
This time, I'm looking at what happens when no source lines end up
being printed. This can happen for two reasons, a request is made to
list a line number outside the file, or, a request is made to list a
reverse series of lines (e.g. line 100 to line 50).
Before GDB 10, a 'list' command that resulted in no lines being
printed would not change the notion of the last line listed. As a
result a future forward or reverse search would continue from the
previous last line. As an example, here's current master branch
behaviour:
(gdb) list 50
45 /* Line 45 */
46 /* Line 46 */
47 /* Line 47 */
48 /* Line 48 */
49 /* Line 49 */
50 /* Line 50 */
51 /* Line 51 */
52 /* Line 52 */
53 /* Line 53 */
54 /* Line 54 */
(gdb) list 1000
Line number 995 out of range; long-file.c has 101 lines.
(gdb) forward-search Line
Expression not found
(gdb)
But on GDB 9, the forward-search instead acts like this:
(gdb) forward-search Line
55 /* Line 55 */
(gdb)
Similarly, reverse-search reports "Expression not found" on master,
but would return line 53 on GDB 9.
The reverse-search result for master might be a little surprising,
surely, if we tried to list line 1000, then every line before that
should be searched.
The problem is that last_line_listed ends up being set to 995 (which
is 1000 minus half the listsize). Then, when the reverse-search kicks
in GDB tried to read line 994, fails, and abandons the search.
This problem was introduced with commit:
commit 8b7fcda274
Date: Sun Dec 22 14:58:22 2019 +0100
Fix search in TUI
This commit wants last_line_listed updated so that the search
functions would work correctly (see notes below) when GDB is in TUI
mode. Without this commit last_line_listed would never be updated in
TUI mode, and so every search would effectively start from the
beginning of the file.
The fix I propose is to delay updating the current_source_location
until the source code has been printed successfully. That is, just
before we leave print_source_lines_base, after a successful print.
This update happens inside the 'if (noprint)' block, a the return here
isn't really considered an error condition, this is a specific choice
_not_ to print the source code.
However, in the 'if (stopline <= line)' block, the
current_source_location is not updated, that's because this 'if'
represents an error condition.
The last_line_listed is also updated at the end of the function still,
which is the path taken in CLI mode when source lines are actually
printed.
I've added some CLI tests to confirm the forward/reverse search
behaviour. And I've also added some TUI tests to check search works
within the TUI. The TUI tests cover more than just the fix for this
issue.
There is one slight issue with the TUI. At this point you should
definitively go read the previous commit. OK, so, the forward and
reverse searches are supposed to search from the last line listed.
The previous commit fixed this for CLI mode, but for the TUI the
last_line_listed is _still_ being set to the first line displayed.
The problem is that print_source_lines_base doesn't know the size of
the TUI src window, and so, doesn't know what the last line listed
will be, and so cannot set last_line_listed correctly.
This indicates to me that setting last_line_listed from the core GDB
code is likely the wrong approach, or, at least, the way it is done
now is the wrong approach.
Currently the 'list' command converts the arguments into a set of
lines to be printed based on the CLI environment, e.g. using the
'listsize' if necessary. But the 'listsize' doesn't make sense for
the TUI, where the src window height really overrides the 'listsize'.
The list command then calls the core GDB print_source_lines
function to do the printing, but for the TUI we don't actually print
anything, we just update the internal state (including
last_line_listed) and are done.
I think that the current interpreter, CLI or TUI, needs to get
involved in the 'list' command implementation much sooner. This would
allow, for example, the CLI to use 'listsize' and the TUI to use the
src window height. It might then be up to the interpreter to track
the last line listed maybe?
I mention all this only to acknowledge this issue. The problem
existed before this commit, and continues to exist after this commit.
I'm not proposing to fix this problem right now.
The TUI forward/reverse search continue to work as well as they have
since commit 8b7fcda274.
Approved-By: Tom Tromey <tom@tromey.com>
The forward-search and reverse-search commands were broken by this
commit:
commit a75cd9a2c1
Date: Thu Nov 14 16:11:15 2019 -0700
Add observable to watch current source symtab
while builds on the work in this commit:
commit 1dd5885077
Date: Thu Aug 1 09:34:40 2019 -0600
Make current_source_* per-program-space
both of these commits went into GDB 10.
The documentation for these commands is pretty clear:
'forward-search REGEXP'
'search REGEXP'
The command 'forward-search REGEXP' checks each line, starting with
the one following the last line listed, for a match for REGEXP. It
lists the line that is found. You can use the synonym 'search
REGEXP' or abbreviate the command name as 'fo'.
'reverse-search REGEXP'
The command 'reverse-search REGEXP' checks each line, starting with
the one before the last line listed and going backward, for a match
for REGEXP. It lists the line that is found. You can abbreviate
this command as 'rev'.
Both searches should start searching based on the last line listed.
But currently:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) forward-search Line
4 /* Line 4 */
(gdb)
This should have found line 11. And for reverse-search:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) reverse-search Line
Expression not found
(gdb)
The reverse-search should have returned line 9.
This new behaviour started with the above commits in GDB 10. On GDB 9
we see behaviour that matches the documentation.
Where the forward and reverse searches start from is controlled by a
global, last_line_listed, found in source.c.
Before commit 1dd5885077, in print_source_lines_base, the
last_line_listed variable was updated as each source line was printed,
and it was updated with the current line being printed.
After commit 1dd5885077, the current symtab and line are moved into
a current_source_location object, but the symtab and line member
variables are public. The last_line_listed is still set based on the
value held in the current_source_location object, and this object is
updated each time around the source printing loop. So despite the
restructure, the logic, and behaviour, is unchanged.
After commit a75cd9a2c1, the member variables of
current_source_location are now private. The source printing loop in
print_source_lines_base uses a local variable, new_lineno, to track
the current source line number, and updates the
current_source_location at the end of print_source_lines_base.
However, last_line_listed is still updated inside the loop, using the
original line value within current_source_location, which is no longer
being updated each time around the loop.
As a result, last_line_listed is now just the first line listed!
This didn't show up in testing because, as far as I can tell, the
last_line_listed is _only_ used for forward and reverse searching, and
the testing for these commands is minimal.
In this commit I move the setting of last_line_listed outside of the
source printing loop, this only needs to be updated once, when we have
finished printing the source lines.
I've also done a couple of other cleanups in the same area, I moved
'buf' a local variable into the most inner scope where it is required,
and I converted the 'while' loop into a 'for' loop, moving the
increment out of the loop body.
There's now a test which does some more detailed checks of the forward
and reverse search commands.
Approved-By: Tom Tromey <tom@tromey.com>
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
void _initialize_something ();
void
_initialize_something ()
{
...
}
... now you would write:
INIT_GDB_FILE (something)
{
...
}
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
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>
I think there is no need to have a prefix command that simply calls
help_list. Instead, add_basic_prefix_cmd can be used. This patch
changes the relevant instances. In one spot, add_setshow_prefix_cmd
is used instead.
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
This simplifies things a little bit, removing some `find_if` when
inserting or removing objfiles, and the whole
unwrapping_objfile_iterator thing.
Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba
Creating a registry key using emplace calls new:
...
DATA *result = new DATA (std::forward<Args> (args)...);
...
which can throw a bad alloc, which will terminate gdb if called from a
destructor.
Fix this in a few places.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
This patch adds a cwd paramter to openp, so that the current directory
can be passed in by the caller. This is useful when background
threads call this function -- they can then avoid using the global and
thus avoid races with the user using "cd".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
While looking at the recent line number styling commit I noticed a few
places where we could add more file name styling. So lets do that.
Approved-By: Tom Tromey <tom@tromey.com>
This patch adds separate styling for line numbers. That is, whenever
gdb prints a source line number, it uses this style.
v2 includes a change to ensure that %ps works in query.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
Following on from the previous commit, this commit marks the old
unquoted filename completion related functions as deprecated.
The aim of doing this is to make it more obvious to someone adding a
new command that they should not be using the older unquoted style
filename argument handling.
I split this change from the previous to make for an easier review.
This commit touches more files, but is _just_ function renaming.
Check out gdb/completer.{c,h} for what has been renamed. All the
other files have just been updated to use the new names.
There should be no user visible changes after this commit.
The 'list' command prints around the 'main' function if the current
source location is not set. The prologue of 'main' is skipped and the
first real line of 'main' is offset by 'lines_to_print - 1'. This is
incorrect, the location should be defaulted to main's prologue without
applying offsets (similar to 'list main'). Printing around the selected
line is then done in 'list_around_line'.
The patch also fixes an issue if the list command is used before the
program is started. For example, with the following code:
26 static void attribute ((used)) ambiguous_fun (void) {}
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
37
38 int
39 main (void)
40 {
41 return 0;
42 }
GDB offsets the relevant line by 'lines_to_print - 1' and then by another
'lines_to_print / 2' and prints:
(gdb) list
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
With this patch, GDB correctly prints:
37
38 int
39 main (void)
40 {
41 return 0;
42 }
Approved-By: Andrew Burgess <aburgess@redhat.com>
Make the current program space reference bubble up one level.
Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
The other day on irc, we were discussing the "m_line" hack in
tui-out.c, and I mentioned that it would be nice to replace this with
a new ui_out_flag.
Later, I looked at ui_out_flag and found:
ui_source_list = (1 << 0),
... and sure enough, this is tested already.
This patch removes tui-out.[ch] and changes the TUI to use an ordinary
cli-out object without this flag set.
As far as I can tell, this doesn't affect behavior at all -- the TUI
tests all pass, and interactively I tried switching stack frames,
"list", etc, and it all seems to work.
New in v2: fixed the problem pointed out by Keith, and added a test
case for that scenario.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.
Note that this introduces some new constants to Python and Guile. I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.
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.
This started with me running into this comment in symfile.c:
/* FIXME, should use print_sys_errmsg but it's not filtered. */
gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"),
styled_string (file_name_style.style (), filename));
In this particular case I think I disagree with the comment; I think
the output should be a warning rather than just a message printed to
gdb_stdout, I think when the executable, or some other objfile that is
currently being debugged, disappears from disk, this is likely an
unexpected situation, and worth warning the user about.
So, in theory, I could just call print_sys_errmsg and remove the
comment, but that would mean loosing the filename styling in the
output... so in the end I remove the comment and updated the code to
call warning.
But that got me looking at print_sys_errmsg and how it's used.
Currently the function takes a string and an errno, and prints, to
stderr, the string followed by the result of calling strerror on the
errno.
In some places the string passed to print_sys_errmsg is just a
filename, and this is used when something goes wrong. In these cases,
I think calling warning rather than gdb_printf to gdb_stderr, would be
better, and in fact, in a couple of places we manually print a
"warning" prefix, and then call print_sys_errmsg. And so, for these
users I have added a new function warning_filename_and_errno, which
takes a filename, which is printed with styling, and an errno, which
is passed through strerror and the resulting string printed. This new
function calls warning to print its output. I then updated some of
the print_sys_errmsg users to use this new function.
Some other users of print_sys_errmsg are also emitting what is clearly
a warning, however, the string being passed in is more than just a
filename, so the new warning_filename_and_errno function can't be
used, it would style the whole string. For these users I have
switched to calling warning directly, this allows me to style the
warning message correctly.
Finally, in inflow.c there is one last call to print_sys_errmsg, in
this case I just inlined the definition of print_sys_errmsg. This is
a really weird case, as after printing this message GDB just does a
hard exit. This is pretty old code, dating back to the initial GDB
import, I guess it should be updated to call error() maybe, but I'm
reluctant to make this change as part of this commit, just in case
there's some reason why we can't throw an error at this point.
With that done there are now no users of print_sys_errmsg, and so the
old function can be removed.
While I was doing all of the above I added some additional filename
styling in soure.c, this is in an else block where the if contained
the print_sys_errmsg call, so these felt related.
And finally, while I was updating the uses of print_sys_errmsg in
procfs.c, I noticed that we used a static errmsg buffer to format some
error strings. As the above changes got rid of one of the users of
errmsg I also removed the other two users, and the static buffer.
There were a couple of tests that depended on the existing output
message format that needed updating. In one case we gained an extra
'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ',
I think in both cases the new output is an improvement.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When using "list" with no arguments, GDB will first print the lines
around where the inferior is stopped, then print the next N lines until
reaching the end of file, at which point it warns the user "Line X out
of range, file Y only has X-1 lines.". This is usually desirable, but
if the user can no longer see the original line, they may have forgotten
the current line or that a list command was used at all, making GDB's
error message look cryptic. It was reported in bugzilla as PR cli/30497.
This commit improves the user experience by changing the behavior of
"list" slightly when a user passes no arguments. It now prints that the
end of the file has been reached and recommends that the user use the
command "list ." instead.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that select_source_symtab is only ever called with nullptr
as an argument, so this patch removes the parameter and associated
logic.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
