Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
The scopes under this "if" are over-indented, fix that.
gdb/ChangeLog:
* arm-tdep.c (arm_record_data_proc_misc_ld_str): Fix
indentation.
Change-Id: I84a551793207ca95d0bc4f122e336555c8179c0e
The test-case gdb.base/watch_thread_num.exp contains an infrun regexp:
...
-re "infrun:" {
...
which doesn't trigger because:
- the test-case doesn't contain "set debug infrun 1", and
- if we hack the test-case to add this, the regexp doesn't match
because "[infrun] " is printed instead.
Make the test pass with "set debug infrun 1" and add the setting commented
out.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-11 Tom de Vries <tdevries@suse.de>
* gdb.base/watch_thread_num.exp: Fix "set debug infrun 1" FAILs.
Add "set debug infrun 1" commented out.
When running check-read1, I run into a timeout in test-case
gdb.base/gdb-sigterm.exp:
...
[infrun] handle_inferior_event: status->kind = stopped, \
signal = GDB_SIGNAL_TRAP^M
[infrun] start_step_over: enter^M
[infrun] start_step_overFAIL: gdb.base/gdb-sigterm.exp: \
expect eof #0 (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 0 times
FAIL: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes
...
The corresponding gdb_test_multiple has an exp_continue clause, but it doesn't
trigger because the regexp greps for 'infrun: ' instead of '[infrun] '.
Fix the timeout by fixing the infrun regexp.
Tested on x86_64-linux, with check and check-read1.
gdb/testsuite/ChangeLog:
2021-05-11 Tom de Vries <tdevries@suse.de>
* gdb.base/gdb-sigterm.exp: Fix exp_continue regexp.
Breakpoint location is modified to "return" statement which is
outside the DO loop. Because the label 100 of DO loop should get
executed for each iteration as shared in this external link:
http://www-pnp.physics.ox.ac.uk/~gronbech/intfor/node18.html.
flang compiler is following this fortran standard, whereas gfortran
compiler is not following, hence the test case is passing with
gfortran and failing with flang. but to correct this gfortran
behavior, bug has been filed in bugzilla
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99816). As reported in
the bug, with gfortran, label 100 of DO loop is reached only after
the completion of the entire DO loop. Hence at label 100, all the
array elements are set and printing of array element a(2) succeeds.
whereas with flang, when we are at label 100 for first time, array
element a(2) is not yet set, only a(1) is set, hence moving the
breakpoint location to outside the DO loop, so that once we are
outside the DO loop, we can print any of the array elements. This
change in test case is done irrespective of any fortran compiler.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-element.exp: Breakpoint location is modified.
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.
In this commit:
commit 1845e25464
Date: Wed May 5 16:50:17 2021 +0100
gdb/guile: perform tilde expansion when sourcing guile scripts
A test was added that tries to source a guile script from the users
HOME directory. In order to achieve this the test (temporarily)
modifies $HOME to point into the binutils-gdb source tree.
The problem with this is that sourcing a guile script can cause the
guile script to be byte compiled and written into a .cache/ directory,
which is stored .... in the $HOME directory.
The result was that the test added in the above commit would cause a
.cache/ directory to be added into the binutils-gdb source tree.
In this commit the test is updated to create a new directory in the
build tree, the file we want to source is copied over, and $HOME is
set to point at the location in the build tree. Now when the test is
run the .cache/ directory is created in the build tree, leaving the
source tree untouched.
gdb/testsuite/ChangeLog:
* gdb.guile/guile.exp: Don't use the source directory as a
temporary HOME directory.
This test has a little oversight: the test procedure doesn't actually
use its parameters, the commands and expected patterns are hard-coded,
so we always test with i386:x86-64, instead of with the three arches.
Fix that.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-osabi.exp (test_osabi_none): Use the
parameters.
Change-Id: Iee2c32963d09e502ae791d5df2b6c04a1f49a57a
I was looking at some "set debug lin-lwp" logs, and saw that a thread
received the "Child exited" signal. It took me a moment to realize that
this was SIGCHLD. I then thought that it would be nice for
status_to_str to show the signal name (SIGCHLD) in addition to the
description "Child exited", since people are much more used to referring
to signals using their names.
Fortunately, libiberty contains a handy function to get the signal name
from the signal number, strsigno, use that.
The output of "set debug lin-lwp" now looks like:
[linux-nat] linux_nat_wait_1: waitpid 1209631 received SIGTRAP - Trace/breakpoint trap (stopped)
gdb/ChangeLog:
* nat/linux-waitpid.c (status_to_str): Show signal name.
Change-Id: I8ad9b1e744dd64461fd87b08d5c29f9ef97c4691
Change this:
The available watchpoint types represented by constants are defined
in the gdb module:
to this:
The available watchpoint types are represented by constants defined
in the gdb module:
The new version matches a similar line a few lines up the document
which reads:
The available types are represented by constants defined in the gdb
module:
gdb/doc/ChangeLog:
* guile.texinfo (Breakpoints In Guile): Reword sentence.
* python.texinfo (Breakpoints In Python): Reword sentence.
When the 'set debug py-unwind' flag was added, it was never documented
in the manual. This commit adds some text for this command to the
manual.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Document 'set debug
py-unwind' and 'show debug py-unwind'.
Converts the debug print out in python/py-unwind.c to use the new
debug printing scheme. I have also modified what is printed in a few
places, for example, rather than printing frame pointers, I now print
the frame level, this matches what we do in the general 'set debug
frame' tracing, and is usually more helpful (I think).
I also added a couple of ENTER/EXIT scope printers.
gdb/ChangeLog:
* python/py-unwind.c (pyuw_debug): Convert to bool.
(show_pyuw_debug): New function.
(pyuw_debug_printf): Define.
(PYUW_SCOPED_DEBUG_ENTER_EXIT): Define.
(pyuw_this_id): Convert to new debug print macros.
(pyuw_prev_register): Likewise.
(pyuw_sniffer): Likewise.
(pyuw_dealloc_cache): Likewise.
(_initialize_py_unwind): Update now pyuw_debug is a bool, and add
show function when registering.
Replace fprint_frame_id with a member function frame_id::to_string
that returns a std::string. Convert all of the previous users of
fprint_frame_id to use the new member function. This means that
instead of writing things like this:
fprintf_unfiltered (file, " id=");
fprint_frame_id (file, s->id.id);
We can write this:
fprintf_unfiltered (file, " id=%s", s->id.id.to_string ().c_str ());
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dummy-frame.c (fprint_dummy_frames): Convert use of
fprint_frame_id to use frame_id::to_string.
* frame.c (fprint_field): Delete.
(fprint_frame_id): Moved to...
(frame_id::to_string): ...this, rewritten to return a string.
(fprint_frame): Convert use of fprint_frame_id to use
frame_id::to_string.
(compute_frame_id): Likewise.
(frame_id_p): Likewise.
(frame_id_eq): Likewise.
(frame_id_inner): Likewise.
* frame.h (struct frame_id) <to_string>: New member function.
(fprint_frame_id): Delete declaration.
* guile/scm-frame.c (frscm_print_frame_smob): Convert use of
fprint_frame_id to use frame_id::to_string.
* python/py-frame.c (frame_object_to_frame_info): Likewise.
* python/py-unwind.c (unwind_infopy_str): Likewise.
(pyuw_this_id): Likewise.
Instead of using a static buffer. This is safer, and we don't really
mind about any extra dynamic allocation here, since it's only used for
debug purposes.
gdb/ChangeLog:
* nat/linux-waitpid.c (status_to_str): Return std::string.
* nat/linux-waitpid.h (status_to_str): Likewise.
* linux-nat.c (linux_nat_post_attach_wait): Adjust.
(linux_nat_target::attach): Adjust.
(linux_handle_extended_wait): Adjust.
(wait_lwp): Adjust.
(stop_wait_callback): Adjust.
(linux_nat_filter_event): Adjust.
(linux_nat_wait_1): Adjust.
* nat/linux-waitpid.c (status_to_str): Adjust.
* nat/linux-waitpid.h (status_to_str): Adjust.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::wait_for_event_filtered):
Adjust to status_to_str returning std::string.
Change-Id: Ia8aead70270438a5690f243e6faafff6c38ff757
Currently, in order to tell whether support for disabling address
space randomization on Linux is available, GDB checks if the
personality syscall works, at configure time. I.e., it does a run
test, instead of a compile/link test:
AC_RUN_IFELSE([PERSONALITY_TEST],
[have_personality=true],
[have_personality=false],
This is a bit bogus, because the machine the build is done on may not
(and is when you consider distro gdbs) be the machine that eventually
runs gdb. It would be better if this were a compile/link test
instead, and then at runtime, GDB coped with the personality syscall
failing. Actually, GDB already copes.
One environment where this is problematic is building GDB in a Docker
container -- by default, Docker runs the container with seccomp, with
a profile that disables the personality syscall. You can tell Docker
to use a less restricted seccomp profile, but I think we should just
fix it in GDB.
"man 2 personality" says:
This system call first appeared in Linux 1.1.20 (and thus first
in a stable kernel release with Linux 1.2.0); library support
was added in glibc 2.3.
...
ADDR_NO_RANDOMIZE (since Linux 2.6.12)
With this flag set, disable address-space-layout randomization.
glibc 2.3 was released in 2002.
Linux 2.6.12 was released in 2005.
The original patch that added the configure checks was submitted in
2008. The first version of the patch that was submitted to the list
called personality from common code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058204.html
and then was moved to Linux-specific code:
https://sourceware.org/pipermail/gdb-patches/2008-June/058209.html
Since HAVE_PERSONALITY is only checked in Linux code, and
ADDR_NO_RANDOMIZE exists for over 15 years, I propose just completely
removing the configure checks.
If for some odd reason, some remotely modern system still needs a
configure check, then we can revert this commit but drop the
AC_RUN_IFELSE in favor of always doing the AC_LINK_IFELSE
cross-compile fallback.
gdb/ChangeLog:
* linux-nat.c (linux_nat_target::supports_disable_randomization):
Remove references to HAVE_PERSONALITY.
* nat/linux-personality.c: Remove references to HAVE_PERSONALITY.
(maybe_disable_address_space_randomization)
(~maybe_disable_address_space_randomizatio): Remove references to
HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbserver/ChangeLog:
* linux-low.cc:
(linux_process_target::supports_disable_randomization): Remove
reference to HAVE_PERSONALITY.
* config.in, configure: Regenerate.
gdbsupport/ChangeLog:
* common.m4 (personality test): Remove.
Before this patch:
(gdb) source ~/script.scm
ERROR: In procedure apply-smob/1:
ERROR: In procedure primitive-load-path: Unable to find file "~/script.scm" in load path
Error while executing Scheme code.
(gdb)
This is because the path is not tilde expanded. In contrast, when
sourcing a .py or .gdb script the path is tilde expanded.
This commit fixes this oversight, and allows the above source command
to work as expected.
The tilde expansion is done in the generic GDB code before we call the
sourcer function for any particular extension language.
gdb/ChangeLog:
* cli/cli-cmds.c: Add 'gdbsupport/gdb_tilde_expand.h'
include.
(source_script_with_search): Perform tilde expansion.
gdb/testsuite/ChangeLog:
* gdb.guile/guile.exp: Add an extra test.
I noticed gdb.base/ptype-offsets.exp failing occasionally, this was
due to lines like this in the test script:
send_gdb "set print type hex on\n"
As this does not match the '(gdb)' prompt that is produced, the prompt
would sometimes be matched against the next test, causing the next
test to think its output was missing and fail.
Fix this by switching to:
gdb_test_no_output "set print type hex on"
gdb/testsuite/ChangeLog:
* gdb.base/ptype-offsets.exp: Replace use of send_gdb with
gdb_test_no_output.
To make the management of memory automatic.
As to why I chose to make this an std::string and not an
std::unique_xmalloc_ptr<char>: some parts of the code consider both a
NULL value and an empty string value to mean "no filename".
target_desc_info_from_user_p, however, doesn't check for a non-NULL but
empty string value. So it seems like having two ways of denoting "no
filename" can lead to these kinds of inconsistencies. Using
std::string, "no filename" is only represented by an empty value.
As a bonus, using an std::string lets us copy target_desc_info objects
using the default assignment operator.
gdb/ChangeLog:
* target-descriptions.c (struct target_desc_info) <filename>:
Make std::string.
(copy_inferior_target_desc_info): Adjust.
(target_desc_info_free): Adjust.
(target_find_description): Adjust.
(set_tdesc_filename_cmd): Adjust.
(show_tdesc_filename_cmd): Adjust.
(unset_tdesc_filename_cmd): Adjust.
(maint_print_c_tdesc_cmd): Adjust.
Change-Id: I4e3a6ad8ccda2b88c202471d4f54249753cad127
In preparation for using non-POD types in the struct.
gdb/ChangeLog:
* target-descriptions.c (struct target_desc_info): Initialize
fields.
(get_tdesc_info): Use new.
(target_desc_info_free): Use delete.
Change-Id: I10fdaeeae7cdbd7930ae7adeeb13f7f363c67c7a
In my opinion, the target_desc_fetched, current_target_desc and
target_description_filename macros in target-descriptions.c are not very
useful. I don't think it's useful to hide that they operate on the
current inferior, as everything currently works under the assumption
that the various tdesc commands operate on the current inferior, and I
don't see that changing in the foreseeable future.
This change also avoids having multiple unnecessary calls to
current_inferior and get_tdesc_info per function.
gdb/ChangeLog:
* target-descriptions.c (struct target_desc_info) <tdesc>:
Adjust doc.
(target_desc_fetched): Remove.
(current_target_desc): Remove.
(target_description_filename): Remove.
(target_find_description): Adjust.
(target_clear_description): Adjust.
(target_current_description): Adjust.
(set_tdesc_filename_cmd): Adjust.
(show_tdesc_filename_cmd): Adjust.
(unset_tdesc_filename_cmd): Adjust.
(maint_print_c_tdesc_cmd): Adjust.
(maint_print_xml_tdesc_cmd): Adjust.
Change-Id: Ibfb581490e949c16d59924e2cac633ede5c26c5b
Change int parameter to bool in remote_notice_new_inferior (remote.c)
and notice_new_inferior (infcmd.c), and update the callers.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* infcmd.c (notice_new_inferior): Change parameter type.
* inferior.h (notice_new_inferior): Change parameter type.
* remote.c (remote_notice_new_inferior): Change parameter type to
bool. Also update type of local variable to bool.
(remote_target::update_thread_list): Change type of local variable
to bool.
(remote_target::process_stop_reply): Pass bool instead of int to
remote_notice_new_inferior.
target_stack::unpush needs to get the target beneath the target being
unpushed to update the m_top field (which keeps the stratum of the
top-most target). It currently does so using target_ops::beneath, which
uses the target stack of the current inferior. The target stack of the
current inferior is the same as the `this` in the unpush method.
Avoid this detour and remove this reference to the current inferior by
calling target_ops::find_beneath and passing `this` to find the target
beneath `t` in the target stack that is `this`.
gdb/ChangeLog:
* target.c (target_stack::unpush): Call target_ops::find_beneath
to get the target beneath `t`.
Change-Id: If9d9661567c5c16f655d270bd2ec9f1b3aa6dadc
The target_close function currently checks that the target to be closed
isn't pushed in the current inferior:
gdb_assert (!current_inferior ()->target_is_pushed (targ));
Normally, a target is closed when its refcount has dropped to 0, due to
not being used in any inferior anymore. I think it would make sense to
change that assert to not only check in the current inferior, but to
check in all inferiors. It would be quite bad (and a bug) to close a
target while it's still pushed in one of the non-current inferiors.
gdb/ChangeLog:
* target.c (target_close): Check in all inferiors that the
target is not pushed.
Change-Id: I6e37fc3f3476a0593da1e476604642b2de90f1d5
Instead of initializing a new debuginfod_client for each query, store
the first initialized client for the remainder of the GDB session and
use it for every debuginfod query.
In conjunction with upcoming changes to libdebuginfod, using one client
for all queries will avoid latency caused by unneccesarily setting up
TCP connections multiple times.
Tested on Fedora 33 x86_64.
gdb/ChangeLog:
* debuginfod-support.c (debuginfod_init): Remove.
(get_debuginfod_client): New function.
Now that libiberty includes htab_eq_string, we can remove the
identical function from gdb.
gdb/ChangeLog
2021-05-07 Tom Tromey <tom@tromey.com>
* breakpoint.c (ambiguous_names_p): Use htab_eq_string.
* utils.c (streq_hash): Remove.
* utils.h (streq_hash): Don't declare.
* completer.c (completion_tracker::discard_completions): Update
comment.
* ada-lang.c (_initialize_ada_language): Use htab_eq_string.
Re-format all Python files using black [1] version 21.4b0. The goal is
that from now on, we keep all Python files formatted using black. And
that we never have to discuss formatting during review (for these files
at least) ever again.
One change is needed in gdb.python/py-prettyprint.exp, because it
matches the string representation of an exception, which shows source
code. So the change in formatting must be replicated in the expected
regexp.
To document our usage of black I plan on adding this to the "GDB Python
Coding Standards" wiki page [2]:
--8<--
All Python source files under the `gdb/` directory must be formatted
using black version 21.4b0.
This specific version can be installed using:
$ pip3 install 'black == 21.4b0'
All you need to do to re-format files is run `black <file/directory>`,
and black will re-format any Python file it finds in there. It runs
quite fast, so the simplest is to do:
$ black gdb/
from the top-level.
If you notice that black produces changes unrelated to your patch, it's
probably because someone forgot to run it before you. In this case,
don't include unrelated hunks in your patch. Push an obvious patch
fixing the formatting and rebase your work on top of that.
-->8--
Once this is merged, I plan on setting a up an `ignoreRevsFile`
config so that git-blame ignores this commit, as described here:
https://github.com/psf/black#migrating-your-code-style-without-ruining-git-blame
I also plan on working on a git commit hook (checked in the repo) to
automatically check the formatting of the Python files on commit.
[1] https://pypi.org/project/black/
[2] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards
gdb/ChangeLog:
* Re-format all Python files using black.
gdb/testsuite/ChangeLog:
* Re-format all Python files using black.
* gdb.python/py-prettyprint.exp (run_lang_tests): Adjust.
Change-Id: I28588a22c2406afd6bc2703774ddfff47cd61919
In code dealing with commands, there's a pattern repeated a few times of
calling lookup_cmd with some speficic arguments and then using strcmp
on the returned command to check for an exact match.
As a later patch would add a few more similar lines of code, this patch
adds a new lookup_cmd_exact function which simplify this use case.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_exact): Add.
* cli/cli-script.c (do_define_command): Use lookup_cmd_exact.
(define_prefix_command): Ditto.
* command.h: Add lookup_cmd_exact.
With the test-case attached in PR26327, gdb aborts:
...
$ gdb -q -batch 447.dealII -ex "b main"
Aborted (core dumped)
...
when running out of stack due to infinite recursion:
...
#8 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x35e4b40)
at src/gdb/dwarf2/read.c:700
#9 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x22ee2c0)
at src/gdb/dwarf2/read.c:700
#10 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x35e4b40)
at src/gdb/dwarf2/read.c:700
#11 0x00000000006aaba6 in dwarf2_cu::get_builder (this=0x22ee2c0)
at src/gdb/dwarf2/read.c:700
...
We're recursing in this code in dwarf2_cu::get_builder():
...
/* Otherwise, search ancestors for a valid builder. */
if (ancestor != nullptr)
return ancestor->get_builder ();
...
due to the fact that the ancestor chain is a cycle.
Higher up in the call stack, we find some code that is responsible for
triggering this, in new_symbol:
...
case DW_TAG_formal_parameter:
{
/* If we are inside a function, mark this as an argument. If
not, we might be looking at an argument to an inlined function
when we do not have enough information to show inlined frames;
pretend it's a local variable in that case so that the user can
still see it. */
struct context_stack *curr
= cu->get_builder ()->get_current_context_stack ();
if (curr != nullptr && curr->name != nullptr)
SYMBOL_IS_ARGUMENT (sym) = 1;
...
This is code that was added to support pre-4.1 gcc, to be able to show
arguments of inlined functions as locals, in the absense of sufficiently
correct debug information.
Removing this code (that is, doing SYMBOL_IS_ARGUMENT (sym) = 1
unconditially), fixes the crash. The ancestor variable also seems to have
been added specifically to deal with fallout from this code, so remove that as
well.
Tested on x86_64-linux:
- openSUSE Leap 15.2 with gcc 7.5.0, and
- openSUSE Tumbleweed with gcc 10.3.0.
gdb/ChangeLog:
2021-05-07 Tom de Vries <tdevries@suse.de>
PR symtab/26327
* dwarf2/read.c (struct dwarf2_cu): Remove ancestor.
(dwarf2_cu::get_builder): Remove ancestor-related code.
(new_symbol): Remove code supporting pre-4.1 gcc that show arguments
of inlined functions as locals.
(follow_die_offset, follow_die_sig_1): Remove setting of ancestor.
gdb/doc/ChangeLog:
2021-05-07 Tom de Vries <tdevries@suse.de>
PR symtab/26327
* gdb.texinfo (Inline Functions): Update.
Change gdbscm_safe_source_script to return a
gdb::unique_xmalloc_ptr<char> instead of a raw char*. Update the
users of this function.
There should be no user visible change after this commit.
gdb/ChangeLog:
* guile/guile-internal.h (gdbscm_safe_source_script): Change
function return type.
* guile/guile.c (gdbscm_source_script): Update to handle change in
gdbscm_safe_source_script.
* guile/scm-objfile.c (gdbscm_source_objfile_script): Likewise.
* guile/scm-safe-call.c (gdbscm_safe_source_script): Change return
type.
Currently, using the guile API, if a user tries to print a breakpoint
object that represents a watchpoint, then GDB will crash. For
example:
(gdb) guile (use-modules (gdb))
(gdb) guile (define wp1 (make-breakpoint "some_variable" #:type BP_WATCHPOINT #:wp-class WP_WRITE))
(gdb) guile (register-breakpoint! wp1)
(gdb) guile (display wp1) (newline)
Aborted (core dumped)
This turns out to be because GDB calls event_location_to_string on the
breakpoints location, and watchpoint breakpoints don't have a
location.
This commit resolves the crash by just skipping the printing of the
location if the breakpoint doesn't have one.
Potentially, we could improve on this by printing details about what
the watchpoint is watching, however, I'm considering this a possible
future enhancement, this commit focuses just on having GDB not crash.
gdb/ChangeLog:
* guile/scm-breakpoint.c (bpscm_print_breakpoint_smob): Only print
breakpoint locations when the breakpoint actually has a location.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_watchpoints): Print the
watchpoint object before and after registering it with GDB.
Convert gdb.guile/scm-breakpoint.exp to use proc_with_prefix instead
of using nested with_test_prefix calls. Allows a level of indentation
to be removed from most of the test procs.
There were two procs that didn't use with_test_prefix, but I converted
them to be proc_with_prefix anyway, for consistency.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Convert to
'proc_with_prefix', remove use of 'with_test_prefix', and
reindent.
(test_bkpt_deletion): Likewise.
(test_bkpt_cond_and_cmds): Likewise.
(test_bkpt_invisible): Likewise.
(test_watchpoints): Likewise.
(test_bkpt_internal): Likewise.
(test_bkpt_eval_funcs): Likewise.
(test_bkpt_registration): Likewise.
(test_bkpt_address): Convert to 'proc_with_prefix'.
(test_bkpt_probe): Likewise.
Extend some test names to avoid duplicates.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Extend test
names to avoid duplicates.
(test_bkpt_cond_and_cmds): Likewise.
(test_bkpt_eval_funcs): Likewise.
Add a '--force' flag to the '-break-condition' command to be
able to force conditions.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_condition): New function.
* mi/mi-cmds.c: Change the binding of "-break-condition" to
mi_cmd_break_condition.
* mi/mi-cmds.h (mi_cmd_break_condition): Declare.
* breakpoint.h (set_breakpoint_condition): Declare a new
overload.
* breakpoint.c (set_breakpoint_condition): New overloaded function
extracted out from ...
(condition_command): ... this.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): Add a test
for the -break-condition command's "--force" flag.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force' flag of the '-break-condition' command.
Add a '--force-condition' flag to the '-break-insert' command to be
able to force conditions. Because the '-dprintf-insert' command uses
the same mechanism as the '-break-insert' command, it obtains the
'--force-condition' flag, too.
gdb/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Recognize the
'--force-condition' flag to force the condition in the
'-break-insert' and '-dprintf-insert' commands.
* NEWS: Mention the change.
gdb/testsuite/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/mi-break.exp (test_forced_conditions): New proc that
is called by the test.
gdb/doc/ChangeLog:
2021-05-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention the
'--force-condition' flag of the '-break-insert' and
'-dprintf-insert' commands.
When running test-case gdb.threads/detach-step-over.exp with target board
readnow, I run into:
...
Reading symbols from /lib64/libc.so.6...^M
Reading symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
Expanding full symbols from \
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
FAIL: gdb.threads/detach-step-over.exp: \
breakpoint-condition-evaluation=host: target-non-stop=on: non-stop=on: \
displaced=off: iter 2: attach (timeout)
...
Fix this by doing exp_continue when encountering the "Reading symbols" or
"Expanding full symbols" lines.
This is still fragile and times out with a higher load, similated f.i. by
stress -c 5. Fix that by using a timeout factor of 2.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/detach-step-over.exp: Do exp_continue when encountering
"Reading symbols" or "Expanding full symbols" lines. Using timeout
factor of 2 for attach.
When running test-case gdb.threads/fork-plus-threads.exp with target board
readnow, I run into:
...
[LWP 9362 exited]^M
[New LWP 9365]^M
[New LWP 9363]^M
[New LWP 9364]^M
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
There is code in the test-case to prevent timeouts with readnow:
...
-re "Thread \[^\r\n\]+ exited" {
# Avoid timeout with check-read1
exp_continue
}
-re "New Thread \[^\r\n\]+" {
# Avoid timeout with check-read1
exp_continue
}
...
but this doesn't trigger because we get LWP rather than Thread.
Fix this by making these regexps accept LWP as well.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-05-05 Tom de Vries <tdevries@suse.de>
* gdb.threads/fork-plus-threads.exp: Handle "New LWP <n>" and
"LWP <n> exited" messages.
I noticed two errors in the Type.fields documentation:
1. It is possible to call `fields` on an array type, in which case it
returns one field representing the array's range. It is not
mentioned.
2. When calling `fields` on a type that doesn't have fields (by nature,
like an int), GDB raises a TypeError. It does not return an empty
sequence, as currently documented.
Fix these, and change the text into a bullet list. I find it easier to
read than one big paragraph.
The first issue is already tested in gdb.python/py-type.exp, but the
second one doesn't seem tested. Add a test in gdb.python/py-type.exp
for it.
gdb/doc/ChangeLog:
* python.texi (Types In Python): Re-organize Type.fields doc.
Mention handling of array types. Correct doc for when calling
the method on another type.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp (test_fields): Test calling fields on
an int type.
Change-Id: I11c688177504cb070b81a4446ac91dec50b56a22
The `Type.range ()` tests in gdb.python/flexible-array-member.exp pass
when the test is compiled with gcc 9 or later, but not with gcc 8 or
earlier:
$ make check TESTS="gdb.python/flexible-array-member.exp" RUNTESTFLAGS="CC_FOR_TARGET='gcc-8'"
python print(zs['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zs['items'].type.range())
python print(zso['items'].type.range())^M
(0, 0)^M
(gdb) FAIL: gdb.python/flexible-array-member.exp: python print(zso['items'].type.range())
The value that we get for the upper bound of a flexible array member
declared with a "0" size is 0 with gcc <= 8 and is -1 for gcc >= 9.
This is due to different debug info. For this member, gcc 8 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e4)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
For the same type, gcc 9 does:
0x000000d5: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000034 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000e5)
0x000000de: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x0000002d "long unsigned int")
DW_AT_count [DW_FORM_data1] (0x00)
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like. But for now, just change the test to accept the two
values, to get rid of the failure and make the test in sync
I also realized (by looking at the py-type.exp test) that calling the
fields method on an array type yields one field representing the "index"
of the array. The type of that field is of type range
(gdb.TYPE_CODE_RANGE). When calling `.range()` on that range type, it
yields the same range tuple as when calling `.range()` on the array type
itself. For completeness, add some tests to access the range tuple
through that range type as well.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Adjust expected range
value for member declared with 0 size. Test accessing range
tuple through range type.
Change-Id: Ie4e06d99fe9315527f04577888f48284d649ca4c
Since gdb commit 880ae75a2b "gdb delay guile initialization until
gdbscm_finish_initialization" I'm running into:
...
(gdb) print My_Var > 10.0^M
free(): invalid pointer^M
ERROR: GDB process no longer exists
GDB process exited with wait status 5995 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.ada/fixed_cmp.exp: gnat_encodings=all: print My_Var > 10.0
...
The problem is that both gdb and libguile try to set the libgmp memory functions,
and since the gdb commit the ones from libguile are effective, which results
in gdb freeing some memory in a way that is not compatible with the way that
memory was actually allocated.
The fact that libguile tries to set the libgmp memory functions is a bug which
should be fixed starting version v3.0.6.
Meanwhile, work around this in gdb by not allowing libguile to set the libgomp
memory functions.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-04 Tom de Vries <tdevries@suse.de>
PR guile/27806
* guile/guile.c (gdbscm_initialize): Don't let guile change libgmp
memory functions.
The test gdb.python/py-startup-opt.exp checks the behaviour of GDB's:
set python dont-write-bytecode on
This flag (when on) stops Python creating .pyc files. The test first
checks that .pyc files will be created, then turns this option on and
checks .pyc files will not be created.
However, if the user has PYTHONDONTWRITEBYTECODE set in their
environment then this will prevent Python from creating .pyc files, as
such the first test, that .pyc files are being created, currently
fails.
We could unset PYTHONDONTWRITEBYTECODE, however, until Python 3.8
there is no way to control where Python writes the .pyc files. As the
GDB developer clearly doesn't want .pyc files created in their
file-system it feels wrong to silently unset this environment
variable.
My proposal then, is that we just spot when this environment variable
is set and adjust the expected results. My hope is that across all
GDB developers some will be running with PYTHONDONTWRITEBYTECODE
unset, so this feature will be fully tested at least some of the time.
gdb/testsuite/ChangeLog:
PR testsuite/27788
* gdb.python/py-startup-opt.exp (test_python_settings): Change the
expected results when environment variable PYTHONDONTWRITEBYTECODE
is set.
Currently, the DWARF reader has a separate pass to read type units --
create_all_type_units. While working on other patches, I discovered
that this caused DWARF 5 type units to be read twice, once by
create_all_comp_units and once by create_all_type_units.
There's no need any more (if there ever was) to treat type units
differently from CUs. So, this patch removes create_all_type_units
and unifies the code paths.
Note that the DWO code still has a second pass. I haven't looked into
this code yet; perhaps it can also be simplified.
Regression tested using the debug-types board file on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_initialize_objfile): Update.
(add_signatured_type_cu_to_table): Remove.
(create_debug_type_hash_table): Assume dwo_file is non-null.
(create_debug_types_hash_table): Update comment.
(create_all_type_units): Remove.
(sort_tu_by_abbrev_offset): Update comment.
(build_type_psymtabs): Rename from build_type_psymtabs_1.
(build_type_psymtabs): Remove.
(process_skeletonless_type_unit, dwarf2_build_psymtabs_hard):
Update.
(read_comp_units_from_section): Add types_htab, section_kind
parameters.
(create_all_comp_units): Read type units.
I don't think there is any deep reason to separate CUs and TUs in
dwarf2_per_bfd. This patch removes all_type_units and unifies these
two containers. Some minor tweaks are needed to the index writers,
because both forms of index keep CUs and TUs separate;
Regression tested on x86-63 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct tu_stats) <nr_tus>: New member.
(struct dwarf2_per_bfd) <get_cutu, get_tu>: Remove
<get_cu>: Now inline.
<all_type_units>: Remove.
* dwarf2/read.c (dwarf2_per_bfd::~dwarf2_per_bfd): Update.
(dwarf2_per_bfd::get_cutu, dwarf2_per_bfd::get_cu)
(dwarf2_per_bfd::get_tu): Remove.
(dwarf2_per_bfd::allocate_signatured_type): Update nr_tus.
(create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names)
(dw2_symtab_iter_next, dwarf2_base_index_functions::print_stats)
(dwarf2_base_index_functions::expand_all_symtabs)
(dw2_expand_marked_cus, dw_expand_symtabs_matching_file_matcher)
(dwarf2_base_index_functions::map_symbol_filenames)
(dw2_debug_names_iterator::next, dwarf2_initialize_objfile)
(add_signatured_type_cu_to_table, create_all_type_units)
(add_type_unit, build_type_psymtabs_1, print_tu_stats)
(create_all_comp_units): Update.
* dwarf2/index-write.c (check_dwarf64_offsets, write_gdbindex)
(write_debug_names): Update.
In a patch series I am working on, I'd like to have a non-POD member
in dwarf2_per_cu_data. This currently can't be done because
dwarf2_per_cu_data is allocated on an obstack and initialized with
memset.
This patch changes the DWARF reader to allocate objects of this type
with 'new'. The various "subclasses" of this type (signatured_type in
particular) are now changed to derive from dwarf2_per_cu_data, and
also use 'new' for allocation.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_bfd) <allocate_per_cu,
allocate_signatured_type>: Change return type.
<all_comp_units, all_type_units>: Hold unique pointers.
(struct dwarf2_per_cu_data): Add constructor and initializers.
(struct signatured_type): Derive from dwarf2_per_cu_data.
* dwarf2/read.c (type_unit_group): Derive from
dwarf2_per_cu_data.
(dwarf2_per_bfd::get_cutu, dwarf2_per_bfd::get_cu)
(dwarf2_per_bfd::get_tu)
(dwarf2_per_bfd::allocate_signatured_type)
(dwarf2_per_bfd::allocate_signatured_type)
(create_cu_from_index_list, create_cus_from_index_list)
(create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names)
(create_addrmap_from_aranges)
(dwarf2_base_index_functions::find_last_source_symtab)
(dw_expand_symtabs_matching_file_matcher)
(dwarf2_gdb_index::expand_symtabs_matching)
(dwarf2_base_index_functions::map_symbol_filenames)
(create_cus_from_debug_names_list)
(dw2_debug_names_iterator::next)
(dwarf2_debug_names_index::expand_symtabs_matching)
(create_debug_type_hash_table, add_type_unit)
(fill_in_sig_entry_from_dwo_entry, lookup_dwo_signatured_type):
Update.
(allocate_type_unit_groups_table): Use delete.
(create_type_unit_group): Change return type. Use new.
(get_type_unit_group, build_type_psymtabs_1)
(build_type_psymtab_dependencies)
(process_skeletonless_type_unit, set_partial_user)
(dwarf2_build_psymtabs_hard, read_comp_units_from_section)
(create_cus_hash_table, queue_and_load_dwo_tu, follow_die_sig_1)
(read_signatured_type): Update.
(dwarf2_find_containing_comp_unit): Change type of
'all_comp_units'.
(run_test): Update.
(dwarf2_per_bfd::allocate_per_cu)
(dwarf2_per_bfd::allocate_signatured_type): Change return type.
Use new.
(add_signatured_type_cu_to_table): Update.
* dwarf2/index-write.c (write_one_signatured_type)
(check_dwarf64_offsets, psyms_seen_size, write_gdbindex)
(write_debug_names): Update.
The only callers of get_image_name are nat/windows-nat.c, so make it
static.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (get_image_name): Don't declare.
* nat/windows-nat.c (get_image_name): Now static.
