| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
gdb/doc/ChangeLog:
2021-05-25 Hannes Domani <ssbssa@yahoo.de>
* python.texi (Symbols In Python): Fix gdb.SYMBOL_LOC_COMMON_BLOCK.
|
|
tui_win_info::refresh_window first redraws the background window, then
tui_wrefresh draws the python text on top of it, which flickers.
By using wnoutrefresh for the background window, the actual drawing on
the screen is only done once, without flickering.
gdb/ChangeLog:
2021-05-24 Hannes Domani <ssbssa@yahoo.de>
* python/py-tui.c (tui_py_window::refresh_window):
Avoid flickering.
|
|
Add '@:' after 'e.g.' to let texinfo know that this is not the end of
a sentence. This is only needed when there's a space immediately
after the last '.'.
gdb/doc/ChangeLog:
* gdb.texi (Initialization Files): Add '@:' after 'e.g.'.
(Source Path): Likewise.
(GDB/MI Development and Front Ends): Likewise.
(ARM Features): Likewise.
(gdb man): Likewise.
|
|
In a linux kernel mailing list discussion, it was mentioned that "gdb has
this odd thing where it takes the 64-bit vs 32-bit data for the whole process
from one thread, and picks the worst possible thread to do it (ie explicitly
not even the main thread, ...)" [1].
The picking of the thread is done here in
x86_linux_nat_target::read_description:
...
/* GNU/Linux LWP ID's are process ID's. */
tid = inferior_ptid.lwp ();
if (tid == 0)
tid = inferior_ptid.pid (); /* Not a threaded program. */
...
To understand what this code does, let's investigate a scenario in which
inferior_ptid.lwp () != inferior_ptid.pid ().
Say we start exec jit-attach-pie, identified with pid x. The main thread
starts another thread that sleeps, and then the main thread waits for the
sleeping thread. So we have two threads, identified with LWP IDs x and x+1:
...
PID LWP CMD
x x ./jit-attach-pie
x x+1 ./jit-attach-pie
...
[ The thread with LWP x is known as the thread group leader. ]
When attaching to this exec using the pid, gdb does a stop_all_threads which
iterates over all the threads, first LWP x, and then LWP x+1.
So the state we arrive with at x86_linux_nat_target::read_description is:
...
(gdb) p inferior_ptid
$1 = {m_pid = x, m_lwp = x+1, m_tid = 0}
...
and consequently we probe 64/32-bitness from thread LWP x+1.
[ Note that this is different from when gdb doesn't attach but instead
launches the exec itself, in which case there's just one thread to begin with,
and consequently the probed thread is LWP x. ]
According to aforementioned remark, a better choice would have been the main
thread, that is, LWP x.
This patch implement that choice, by simply doing:
...
tid = inferior_ptid.pid ();
...
The fact that gdb makes a per-process permanent choice for 64/32-bitness is a
problem in itself: each thread can be in either 64 or 32 bit mode, and change
forth and back. That is a problem that this patch doesn't fix.
Now finally: why does this matter in the context of the linux kernel
discussion? The discussion was related to a patch that exposed io_uring
threads to user-space. This made it possible that one of those threads would
be picked out to select 64/32-bitness. Given that such threads are atypical
user-space threads in the sense that they don't return to user-space and don't
have a userspace register state, reading their registers returns garbage, and
so it could f.i. occur that in a 64-bit process with all normal user-space
threads in 64-bit mode, the probing would return 32-bit.
It may be that this is worked-around on the kernel side by providing userspace
register state in those threads such that current gdb is happy. Nevertheless,
it seems prudent to fix this on the gdb size as well.
Tested on x86_64-linux.
[1] https://lore.kernel.org/io-uring/CAHk-=wh0KoEZXPYMGkfkeVEerSCEF1AiCZSvz9TRrx=Kj74D+Q@mail.gmail.com/
gdb/ChangeLog:
2021-05-23 Tom de Vries <tdevries@suse.de>
PR tdep/27822
* target.h (struct target_ops): Mention target_thread_architecture in
read_description comment.
* x86-linux-nat.c (x86_linux_nat_target::read_description): Use
pid to determine if process is 64-bit or 32-bit.
* aarch64-linux-nat.c (aarch64_linux_nat_target::read_description):
Same.
* ppc-linux-nat.c (ppc_linux_nat_target::read_description): Same.
* riscv-linux-nat.c (riscv_linux_nat_target::read_description): Same.
* s390-linux-nat.c (s390_linux_nat_target::read_description): Same.
* arm-linux-nat.c (arm_linux_nat_target::read_description): Same.
Likewise, use pid to determine if kernel supports reading VFP
registers.
|
|
The comments in the enum cmdarg_kind were using -sx and -sex instead
of -eix and -eiex.
(Note that gdb --help does not speak about these options).
(pushed as obvious)
|
|
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.
|
|
The test in gdb.dwarf2/dw2-inline-with-lexical-scope.c fails with icc.
The reason is, icc did not emit code for a dead statement, which in
turn caused some labels to be collapsed. Fix this by replacing the
dead code with assignment to a global value. The statement itself
does not change the test scenario.
Also fix a whitespacing problem around an assignment operator.
gdb/testsuite/ChangeLog:
2021-05-21 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.dwarf2/dw2-inline-with-lexical-scope.c (func): Replace
a dead code with an assignment to a global var. Fix a
whitespacing problem around an assignment operator.
|
|
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
which we can compile into llvm byte code using clang:
...
$ clang -g -S -emit-llvm --target=x86_64-unknown-unknown-elf test.c
...
and then run using lli, which uses the llvm jit:
...
$ lli test.ll
...
If we run this under gdb, we run into an assert:
...
$ gdb -q -batch -ex run --args /usr/bin/lli test.ll
Dwarf Error: Cannot not find DIE at 0x18a936e7 \
[from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
src/gdb/jit.c:1178: internal-error: \
void jit_event_handler(gdbarch*, objfile*): \
Assertion `jiter->jiter_data != nullptr' failed.
...
This is caused by the following.
When running jit_breakpoint_re_set_internal, we first handle
libLLVM.so.10.debug, and set a jit breakpoint.
Next we handle libLLVM.so.10:
...
(gdb) p the_objfile.original_name
$42 = 0x2494170 "libLLVM.so.10"
...
but the minimal symbols we find are from libLLVM.so.10.debug:
...
(gdb) p reg_symbol.objfile.original_name
$43 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
(gdb) p desc_symbol.objfile.original_name
$44 = 0x38e7c50 "libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug"
...
and consequently, the objf_data is the one from libLLVM.so.10.debug:
...
jiter_objfile_data *objf_data
= get_jiter_objfile_data (reg_symbol.objfile);
...
and so we hit this:
...
if (objf_data->cached_code_address == addr)
continue;
...
and no second jit breakpoint is inserted.
Subsequently, the jit breakpoint is triggered and handled, but when finding
the symbol for the breakpoint address we get:
...
(gdb) p jit_bp_sym.objfile.original_name
$52 = 0x2494170 "libLLVM.so.10"
...
The assert 'jiter->jiter_data != nullptr' triggers because it checks
libLLVM.so.10 while the one with jiter_data setup is libLLVM.so.10.debug.
This fixes the assert:
...
jiter_objfile_data *objf_data
- = get_jiter_objfile_data (reg_symbol.objfile);
- = get_jiter_objfile_data (the_objfile);
...
but consequently we'll have two jit breakpoints, so we also make sure we don't
set a jit breakpoint on separate debug objects like libLLVM.so.10.debug.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-21 Tom de Vries <tdevries@suse.de>
PR breakpoint/27889
* jit.c (jit_breakpoint_re_set_internal): Skip separate debug
objects. Call get_jiter_objfile_data with the_objfile.
|
|
I guess this was used with the old VEC implementation, but there is no
reason to have this typedef anymore.
gdb/ChangeLog:
* linespec.c (linespec_p): Remove. Replace all uses with
"linespec *".
Change-Id: I4cea59ae1cd46985da9c08d3a69686846b1ad028
|
|
In cli/cli-script.c, process_next_line() allocates memory
which will eventually end up being assigned to the 'next'
field in struct command_line. However, in a case
recurse_read_control_structure returns 'invalid_control'
this memory is leaked. This commit uses std::unique_ptr
as appropriate to prevent this leakage.
This issue was found by coverity scanning.
gdb/ChangeLog:
* cli/cli-script.h (command_line_up): New unique_ptr typedef.
* cli/cli-script.c (multi_line_command_p): Use unique_ptr
command_line_up instead of struct command_line.
(build_command_line): Likewise.
(get_command_line): Update the cmd function call parameter.
(process_next_line): Use unique_ptr command_line_up instead
of struct command_line.
(recurse_read_control_structure): Change the the type of
next to command_line_up.
(read_command_lines_1): Change type of `next' to be
command_line_up and update all references of `next'
accordingly.
|
|
gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
|
|
|
|
Add a powerpc64-prologue testcase, this is based on the existing
powerpc-prologue test, but updated for the powerpc64 (le) target.
YYYY-MM-DD Will Schmidt <will_schmidt@vnet.ibm.com>
gcc/testsuite/ChangeLog
* gdb.arch/powerpc64-prologue.c: New test to exercise prologues
for the powerpc64 LE target.
* gdb.arch/powerpc-prologue.exp: Test Harness.
|
|
clang 11 with libc++'s <algorithm> fails to match the existing
operator<() for std::less<> since the method is not marked const.
gdb/ChangeLog:
* dwarf2/read.c (tu_abbrev_offset::operator<): Mark const.
|
|
These methods are just trivial wrappers around the versions accepting
a char pointer. By moving them to the header the compiler can inline
them.
gdb/ChangeLog:
* ui-out.c (ui_out::field_string): Move to ui-out.h.
(ui_out::text): Ditto.
* ui-out.h (class ui_out): Add definitions of
ui_out::field_string and ui_out::text which were previously
defined in ui-out.c.
|
|
While adding a ui_out::text () overload accepting a std::string, I
noticed that several callers of ui_out::field_string () were converting
std::string instances to char pointers even if not necessary.
gdb/ChangeLog:
* ui-out.c (ui_out::field_string): Add missing style_argument
to the overload accepting a std::string, to make it equivalent
to the char pointer version.
* ui-out.h (class ui_out): Ditto.
* break-catch-sig.c (signal_catchpoint_print_one): Do not
convert std::strings to char pointers before passing them to
ui_out::field_string ().
* break-catch-throw.c (print_one_detail_exception_catchpoint):
Ditto.
* cli/cli-setshow.c (do_show_command): Ditto.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Ditto.
* infcmd.c (print_return_value_1): Ditto.
* inferior.c (print_inferior): Ditto.
* linux-thread-db.c (info_auto_load_libthread_db): Ditto.
* mi/mi-cmd-var.c (print_varobj): Ditto.
(mi_cmd_var_set_format): Ditto.
(mi_cmd_var_info_type): Ditto.
(mi_cmd_var_info_expression): Ditto.
(mi_cmd_var_evaluate_expression): Ditto.
(mi_cmd_var_assign): Ditto.
(varobj_update_one): Ditto.
* mi/mi-main.c (list_available_thread_groups): Ditto.
(mi_cmd_data_read_memory_bytes): Ditto.
(mi_cmd_trace_frame_collected): Ditto.
* osdata.c (info_osdata): Ditto.
* probe.c (info_probes_for_spops): Ditto.
* target-connection.c (print_connection): Ditto.
* thread.c (print_thread_info_1): Ditto.
* tracepoint.c (print_one_static_tracepoint_marker): Ditto.
|
|
gdb/ChangeLog:
* ui-out.h (class ui_out): Add ui_out::text accepting a constant
reference to a std::string. Fix all callers using
std::string::c_str.
* ui-out.c (ui_out::text): Ditto.
|
|
This commit:
commit ecf25064e87a3d2d59871b3ea7126fa0dee0001d
Date: Thu May 13 15:42:20 2021 +0100
gdb: fix pretty printing max depth behaviour
Introduced a couple of duplicate tests, this commit resolves them by
providing unique test names.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-pretty-print.exp: Add test names to resolve
duplicate test names.
|
|
When running test-case gdb.base/info-types-c++.exp with check-read1 I run
into:
...
425: typedef const void * std::allocator_traits<std::allocator<std::\
_Sp_counted_ptr_inplace<std::filesystem::__cxx11::\
recursive_directory_iterator::_Dir_stack, std::allocator<std::filesystem::\
__cxx11::recursive_directory_iterator::_Dir_stack>, \
FAIL: gdb.base/info-types-c++.exp: info types (timeout)
...
The corresponding gdb_test_multiple does contain an exp_continue which
resets the timeout counter every time info for another file is printed, but
this doesn't help for this timeout because it times out during printing info
for a single file.
Fix this by processing line-by-line.
Tested on x86_64-linux, both with gcc-7.5.0 and gcc-4.8.5 (the latter is
different because the "unsigned int" type is missing).
gdb/testsuite/ChangeLog:
2021-05-19 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp.tcl: Scan info types output line-by-line.
|
|
In a case open() returns 0 tty might be leaked. While 0 should be
stdin (and therefore is an unlikely return value from open()), it's
still the case that the test should be for non-negative return values
from open().
gdb/ChangeLog:
2021-05-11 Alexandra Hájková <ahajkova@redhat.com>
* inflow.c (new_tty): Do not leak tty.
|
|
Simon pointed out that dwarf2/cu.h and dwarf2/comp-unit.h seemingly
mean the same thing. He suggested renaming the latter to
comp-unit-head.h, which is what this patch does.
gdb/ChangeLog
2021-05-17 Tom Tromey <tom@tromey.com>
* dwarf2/read.h: Update include.
* dwarf2/read.c: Update include.
* dwarf2/line-header.c: Update include.
* dwarf2/cu.h: Update include.
* dwarf2/comp-unit-head.h: Rename from comp-unit.h.
* dwarf2/comp-unit-head.c: Rename from comp-unit.c.
* Makefile.in (COMMON_SFILES): Update.
|
|
This changes the dwarf2_cu marking functions to be methods on
dwarf2_cu.
gdb/ChangeLog
2021-05-17 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (maybe_queue_comp_unit)
(dwarf2_per_objfile::age_comp_units): Update.
(dwarf2_add_dependence, dwarf2_mark_helper, dwarf2_mark): Move to
dwarf2_cu methods.
* dwarf2/cu.h (struct dwarf2_cu) <mark, clear_mark, is_marked,
add_dependence>: New methods.
<m_dependencies>: Add "m_" prefix. Now private.
<m_mark>: Add "m_" prefix.
* dwarf2/cu.c (dwarf2_cu::dwarf2_cu): Update.
(dwarf2_mark_helper): New function.
(dwarf2_cu::mark, dwarf2_cu::add_dependence): New methods.
|
|
This moves some of the dwarf2_cu methods to a new file, dwarf2/cu.c.
gdb/ChangeLog
2021-05-17 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_cu::addr_sized_int_type)
(dwarf2_cu::start_symtab, dwarf2_cu::addr_type)
(dwarf2_cu::dwarf2_cu): Move to cu.c.
* dwarf2/cu.c: New file.
* Makefile.in (COMMON_SFILES): Add dwarf2/cu.c.
|
|
This moves dwarf2_cu and one supporting data structure to a new header
file. The main goal, as always with this kind of change, is to make
the DWARF reader a bit more understandable.
gdb/ChangeLog
2021-05-17 Tom Tromey <tom@tromey.com>
* Makefile.in (HFILES_NO_SRCDIR): Add dwarf2/cu.h.
* dwarf2/read.c (struct delayed_method_info, struct dwarf2_cu):
Move to cu.h.
* dwarf2/cu.h: New file.
|
|
Two additional settings for developers who use emacs:
1. Set brace-list-open to 0 for C and C++ modes, this ensures we
format things like:
enum blah
{
....
};
Instead of the default for the emacs GNU style:
enum blah
{
...
};
The former seems to be the GDB style.
2. Set sentence-end-double-space to t. This is actually the default
value for this setting, but if anyone has customised this to nil in
general, then forcing this back to t for GDB files will give a
better behaviour for the paragraph filling.
gdb/ChangeLog:
* .dir-locals.el: Set sentence-end-double-space for all modes, and
set brace-list-open to 0 for C and C++ modes.
gdbserver/ChangeLog:
* .dir-locals.el: Set sentence-end-double-space for all modes, and
set brace-list-open to 0 for C and C++ modes.
gdbsupport/ChangeLog:
* .dir-locals.el: Set sentence-end-double-space for all modes, and
set brace-list-open to 0 for C and C++ modes.
|
|
With GCC trunk, gdb.ada/access_to_packed_array.exp causes a GDB crash.
The problem is that ptype tries to resolve a dynamic type. However,
the inferior is not running, so there are no frames.
This patch updates dwarf2_evaluate_loc_desc::get_frame_base to handle
this situation.
gdb/ChangeLog
2021-05-17 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (dwarf2_evaluate_loc_desc::get_frame_base): Throw
if frame is null.
|
|
I tried a build using the undefined behavior sanitizer, and gcc gave
this error:
In file included from /usr/include/string.h:495,
from ../gnulib/import/string.h:41,
from ../../binutils-gdb/gdb/../gdbsupport/common-defs.h:95,
from ../../binutils-gdb/gdb/nat/linux-osdata.c:20:
In function 'char* strncpy(char*, const char*, size_t)',
inlined from 'void time_from_time_t(char*, int, TIME_T)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:923:15,
inlined from 'void time_from_time_t(char*, int, TIME_T)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:911:1,
inlined from 'void linux_xfer_osdata_sem(buffer*)' at ../../binutils-gdb/gdb/nat/linux-osdata.c:1082:22:
/usr/include/bits/string_fortified.h:106:34: error: 'char* __builtin_strncpy(char*, const char*, long unsigned int)' specified bound 32 equals destination size [-Werror=stringop-truncation]
This patch fixes the problem by subtracting one from the length
parameter to strncpy.
I changed a couple of other similar functions -- gcc does not warn
about these, but I didn't see any substantial difference between the
different cases, and I think these are just latent warnings, to be
triggered in the future by a change to inlining heuristics.
gdb/ChangeLog
2021-05-17 Tom Tromey <tromey@adacore.com>
* nat/linux-osdata.c (user_from_uid, time_from_time_t)
(group_from_gid): Subtract one from strncpy length.
|
|
Address sanitizer pointed out a buglet in source.c:add_path.
In this test, from gdb.base/source-dir.exp:
(gdb) set directories :/foo:/bar
... 'p[-1]' will result in a buffer underflow.
This patch fixes the bug by introducing a new check.
2021-05-17 Tom Tromey <tromey@adacore.com>
* source.c (add_path): Check 'p' before using 'p[-1]'.
|
|
Address sanitizer pointed out that the patch to use 'delete' for
dwarf2_per_cu_data introduced a bug -- now it is possible to delete a
signatured_type using a pointer to its base class.
This patch fixes the problem by introducing a deleter and a unique_ptr
specialization. A virtual destructor would be more ordinary here, but
it seemed wasteful to add a vtable just for this purpose. If virtual
methods are ever needed here, we can revisit this.
2021-05-17 Tom Tromey <tromey@adacore.com>
* dwarf2/read.h (struct dwarf2_per_cu_data_deleter: New.
(dwarf2_per_cu_data_up): New typedef.
(struct dwarf2_per_bfd) <allocate_per_cu>: Change return type.
<all_comp_units>: Use dwarf2_per_cu_data_up.
* dwarf2/read.c (dwarf2_per_cu_data::operator()): New function.
(dwarf2_per_bfd::allocate_per_cu): Return dwarf2_per_cu_data_up.
(create_cu_from_index_list): Likewise.
(create_signatured_type_table_from_index)
(create_cus_from_debug_names_list, add_type_unit)
(read_comp_units_from_section): Update.
(dwarf2_find_containing_comp_unit): Change type of all_comp_units.
(run_test): Update.
|
|
I noticed that sort_tu_by_abbrev_offset only has a single caller. It
seemed simpler to replace it with an implementation of operator<
instead.
2021-05-17 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (tu_abbrev_offset::operator<): New method.
(sort_tu_by_abbrev_offset): Remove.
(build_type_psymtabs): Update.
|
|
I noticed these files because they weren't considered by black for
reformatting, prior to adding pyproject.toml, because their extension is
not .py. I don't think they specifically need to be named .py.in, so I
suggest renaming them to .py. This will make it nicer to edit them, as
editors will recognize them more easily as Python files.
Perhaps this was needed before, when the testsuite didn't always put
output files in the output directory. Then, a different name for the
source and destination file might have been desirable to avoid
overwriting a file with itself (perhaps that wasn't well handled). But
in any case, it doesn't see to cause any problem now.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-gdb.py.in: Rename to:
* gdb.python/py-framefilter-gdb.py: ... this.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: Rename to:
* gdb.python/py-framefilter-invalidarg-gdb.py: ... this.
Change-Id: I63bb94010bbbc33434ee1c91a386c91fc1ff80bc
|
|
When running black to format Python files, files with extension .py.in
are ignored, because they don't end in .py. Add a pyproject.toml file
to instruct black to pick up these files too.
gdb/ChangeLog:
* py-project.toml: New.
* gdb-gdb.py.in: Re-format.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-gdb.py.in: Re-format.
* gdb.python/py-framefilter-invalidarg-gdb.py.in: Re-format.
Change-Id: I9b88faec3360ea24788f44c8b89fe0b2a5f4eb97
|
|
Same idea as the previous patches, but for whether a command is a
"command class help" command. I think this one is particularly useful,
because it's not obvious when reading code what "c->func == NULL" means.
Remove the cmd_func_p function, which does kind of the same thing as
cmd_list_element::is_command_class_help (except it doesn't give a clue
about the semantic of a NULL func value).
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_command_class_help>:
New, use it.
* command.h (cmd_func_p): Remove.
* cli/cli-decode.c (cmd_func_p): Remove.
Change-Id: I521a3e1896dc93a5babe1493d18f5eb071e1b3b7
|
|
Same idea as the previous patch, but for prefix instead of alias.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_prefix>: New, use it.
Change-Id: I76a9d2e82fc8d7429904424674d99ce6f9880e2b
|
|
Add the cmd_list_element::is_alias helper to check whether a command is
an alias. I find it easier to understand the intention in:
if (c->is_alias ())
than
if (c->alias_target != nullptr)
Change all the spots that are reading alias_target just to compare it to
NULL/nullptr to use is_alias instead.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <is_alias>: New, use it.
Change-Id: I26ed56f99ee47fe884fdfedf87016501631693ce
|
|
cmd_pointer is another field whose name I found really not clear. Yes,
it's a pointer to a command, the type tells me that. But what's the
relationship of that command to the current command? This field
contains, for an alias, the command that it aliases. So I think that
the name "alias_target" would be more appropriate.
Also, rename "old" parameters to "target" in the functions that add
aliases.
gdb/ChangeLog:
* cli/cli-decode.h (cmd_list_element) <cmd_pointer>: Rename
to...
<alias_target>: ... this.
(add_alias_cmd): Rename old to target.
(add_info_alias): Rename old_name to target_name.
(add_com_alias): Likewise.
Change-Id: I8db36c6dd799fae155f7acd3805f6d62d98befa9
|
|
While browsing this code, I found the name "prefixlist" really
confusing. I kept reading it as "list of prefixes". Which it isn't:
it's a list of sub-commands, for a prefix command. I think that
renaming it to "subcommands" would make things clearer.
gdb/ChangeLog:
* Rename "prefixlist" parameters to "subcommands" throughout.
* cli/cli-decode.h (cmd_list_element) <prefixlist>: Rename to...
<subcommands>: ... this.
* cli/cli-decode.c (lookup_cmd_for_prefixlist): Rename to...
(lookup_cmd_with_subcommands): ... this.
Change-Id: I150da10d03052c2420aa5b0dee41f422e2a97928
|
|
I don't think this can ever happen, that we add an alias command and
pass a nullptr old (target) command. Remove the "if" handling this,
replace with an assert.
gdb/ChangeLog:
* cli/cli-decode.c (add_alias_cmd): Don't handle old == 0.
Change-Id: Ibb39e8dc4e0c465fa42e6826215f30a0a0aef932
|
|
I don't think this method really benefits from being implemented in the
header file, especially because it's recursive, it can't be inlined.
Move it to the source file, so it's no re-compiled by every CU
including cli/cli-decode.h.
I also noticed this method could be const, make it so.
gdb/ChangeLog:
* cli/cli-decode.h (prefixname): Make const, move implementation
to cli/cli-decode.c.
* cli/cli-decode.c (cmd_list_element::prefixname): New.
Change-Id: I1597cace98d9a4ba71f51f1f495e73cc07b5dcf3
|
|
As mentioned in the test case itself, depending on the fortran compiler
used, class member names used in the print commands and also output of
these print commands varies. Existing print commands and its output are
suited for gfortran, hence they were failing with clang compiler and test
case was modified accordingly for clang compiler.
gdb/testsuite/ChangeLog:
* gdb.base/class-allocatable-array.exp: Modified test for clang.
|
|
The problems can be illustrated, with any program, below:
(gdb) print main
$1 = {main} 0x0
The return type was incorrectly set in read_func_kind_type, with
the name of the function, which leads c_type_print_base_1 to print
it. In addition, the address of a new function needs to be set with
that info in its minimal symtab entry, when the new function is added.
After the fix:
(gdb) print main
$1 = {int ()} 0x4004b7 <main>
A new test, gdb.ctf/funcreturn.exp, is added to the testsuite.
gdb/ChangeLog:
* ctfread.c (new_symbol): Set function address.
(read_func_kind_type): Remove incorrect type name setting.
Don't copy name returned from ctf_type_ame_raw throughout file.
gdb/testsuite/ChangeLog:
* gdb.ctf/funcreturn.exp: New file.
* gdb.ctf/whatis.c: Copy from gdb.base.
|
|
An upstream Rust bug notes notes that the Python pretty-printing
feature is broken for values that appear as members of certain types
in Rust.
The bug here is that some of the Rust value-printing code calls
value_print_inner, a method on rust_language. This bypasses the
common code that calls into Python.
I'm checking this in.
gdb/ChangeLog
2021-05-14 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_language::val_print_struct)
(rust_language::print_enum): Use common_val_print, not
value_print_inner.
gdb/testsuite/ChangeLog
2021-05-14 Tom Tromey <tom@tromey.com>
* gdb.rust/pp.exp: New file.
* gdb.rust/pp.py: New file.
* gdb.rust/pp.rs: New file.
|
|
After the gdb test-suite runs there are some files
left in /tmp/tmp*/*.gdb-index, remove those files
and the directory at the end of the test case.
gdb/testsuite:
2021-05-14 Bernd Edlinger <bernd.edlinger@hotmail.de>
* gdb.base/index-cache.exp: Cleanup $cache_dir/*.gdb-index and
remove the directory.
* gdb.dwarf2/per-bfd-sharing.exp: Likewise.
|
|
Define a 'connection_num' attribute for Inferior objects. The
read-only attribute is the ID of the connection of an inferior, as
printed by "info inferiors". In GDB's internal terminology, that's
the process stratum target of the inferior. If the inferior has no
target connection, the attribute is None.
gdb/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* python/py-inferior.c (infpy_get_connection_num): New function.
(inferior_object_getset): Add a new element for 'connection_num'.
* NEWS: Mention the 'connection_num' attribute of Inferior objects.
gdb/doc/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* python.texi (Inferiors In Python): Mention the 'connection_num'
attribute.
gdb/testsuite/ChangeLog:
2021-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.python/py-inferior.exp: Add test cases for 'connection_num'.
|
|
Convert a couple of local variables from int to bool. There should be
no user visible changes after this commit.
gdb/ChangeLog:
* remote.c (check_pending_events_prevent_wildcard_vcont): Change
argument type, update and re-wrap, header comment.
(remote_target::commit_resumed): Convert any_process_wildcard and
may_global_wildcard_vcont from int to bool.
|
|
The 'print max-depth' feature incorrectly causes GDB to skip printing
the string representation of pretty printed variables if the variable
is stored at a nested depth corresponding to the set max-depth value.
This change ensures that it is always printed before checking whether
the maximum print depth has been reached.
Regression tested with GCC 7.3.0 on x86_64, ppc64le, aarch64.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value): Replaced duplicate code.
* guile/scm-pretty-print.c (ppscm_print_children): Check max_depth
just before printing child values.
(gdbscm_apply_val_pretty_printer): Don't check max_depth before
printing string representation.
* python/py-prettyprint.c (print_children): Check max_depth just
before printing child values.
(gdbpy_apply_val_pretty_printer): Don't check max_depth before
printing string representation.
gdb/testsuite/ChangeLog:
* gdb.python/py-format-string.c: Added a variable to test.
* gdb.python/py-format-string.exp: Check string representation is
printed at appropriate max_depth settings.
* gdb.python/py-nested-maps.exp: Likewise.
* gdb.guile/scm-pretty-print.exp: Add additional tests.
|
|
The gdb/callback.h & gdb/remote-sim.h headers have nothing to do with
gdb and are really definitions for the libsim API under the sim/ tree.
While gdb uses those headers as a client, it's not specific to it. So
create a new sim/ namespace and move the headers there.
|
|
Looks like these were copied & pasted as nothing from them are used.
|
|
I realized that with "follow-exec-mode == new", the process target
stayed pushed in the original inferior. This can cause a small
incoherence:
$ ./gdb -q -nx --data-directory=data-directory -ex "set follow-exec-mode new" --args execer args-for-execer
Reading symbols from execer...
(gdb) r
Starting program: /home/smarchi/build/binutils-gdb/gdb/execer args-for-execer
I am execer and my argv[1] is: args-for-execer
process 3562426 is executing new program: /home/smarchi/build/binutils-gdb/gdb/execee
[New inferior 2]
[New process 3562426]
I am execee and my argv[1] is: arg-for-execee
[Inferior 2 (process 3562426) exited normally]
(gdb) info inferiors
Num Description Connection Executable
1 <null> 1 (native) /home/smarchi/build/binutils-gdb/gdb/execer
* 2 <null> /home/smarchi/build/binutils-gdb/gdb/execee
(gdb) maintenance print target-stack
The current target stack is:
- exec (Local exec file)
- None (None)
(gdb) inferior 1
[Switching to inferior 1 [<null>] (/home/smarchi/build/binutils-gdb/gdb/execer)]
(gdb) maintenance print target-stack
The current target stack is:
- native (Native process)
- exec (Local exec file)
- None (None)
On exec, when execution continues into inferior 2, the native target
isn't unpushed from inferior 1. When inferior 2's execution finishes
normally, inf_child_target::mourn_inferior unpushes the native target,
because the native target has been implicitly opened.
I think that if the native target was implicitly opened, it should be
unpushed from inferior 1, just like it is unpushed from an inferior
whose execution terminate. This patch implements that.
gdb/ChangeLog:
* inf-child.h (inf_child_target) <follow_exec>: New.
* inf-child.c (inf_child_target::follow_exec): New.
Change-Id: I782cc08d73d93a990f4e53611107f68b2cb58af1
|
|
target_ops::follow_exec
On "exec", some targets need to unpush themselves from the inferior,
and do some bookkeeping, like forgetting the data associated to the
exec'ing inferior.
One such example is the thread-db target. It does so in
a special case in thread_db_target::wait, just before returning the
TARGET_WAITKIND_EXECD event to its caller.
We have another such case in the context of rocm-gdb [1], where the
"rocm" target is pushed on top of the linux-nat target. When an exec
happens, we want to unpush the rocm target from the exec'ing inferior to
close some file descriptors that refer to the pre-exec address space and
forget about that inferior. We then want to push the target on the
inferior in which execution continues, to open the file descriptors for
the post-exec address space.
I think that a good way to address this cleanly is to do all this in the
target_ops::follow_exec implementations. Make the
process_stratum_target::follow_exec implementation have the default
behavior of pushing itself to the new inferior's target stack (if
execution continues in a new inferior) and add the initial thread.
remote_target::follow_exec is an example of process target that wants to
do a bit more than the default behavior. So it calls
process_stratum_target::follow_exec first and does the extra work
second.
linux-thread-db (a non-process target) implements follow_exec to do some
bookeeping (forget about that process' data), before handing down the
event down to the process target (which hits
process_stratum_target::follow_exec).
gdb/ChangeLog:
* target.h (struct target_ops) <follow_exec>: Add ptid_t
parameter.
(target_follow_exec): Likewise.
* target.c (target_follow_exec): Add ptid_t parameter.
* infrun.c (follow_exec): Adjust call to target_follow_exec,
don't push target nor create thread.
* linux-thread-db.c (class thread_db_target) <follow_exec>: New.
(thread_db_target::wait): Just return on TARGET_WAITKIND_EXECD.
(thread_db_target::follow_exec): New.
* remote.c (class remote_target) <follow_exec>: Add ptid_t parameter.
(remote_target::follow_exec): Call
process_stratum_target::follow_exec.
* target-delegates.c: Re-generate.
Change-Id: I3f96d0ba3ea0dde6540b7e1b4d5cdb01635088c8
|
