| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This moves the new DLL-loading code into nat/windows-nat.c, and
changes both gdb and gdbserver to use the shared code. One
client-provided callback, handle_load_dll, is changed to allow the
code to be shared. This callback was actually never called from
nat/windows-nat.c; maybe I had planned to share more here and then
didn't finish... I'm not sure.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat::handle_load_dll): Update.
(windows_nat_target::get_windows_debug_event): Call
dll_loaded_event.
(windows_add_all_dlls, windows_add_dll): Move to
nat/windows-nat.c.
* nat/windows-nat.h (handle_load_dll): Change parameters.
(dll_loaded_event, windows_add_all_dlls): Declare.
* nat/windows-nat.c (windows_add_dll, windows_add_all_dlls): Move
from windows-nat.c.
(dll_loaded_event): New function.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (do_initial_child_stuff): Update.
(windows_nat::handle_load_dll): Rename from win32_add_one_solib.
Change parameter type.
(win32_add_dll, win32_add_all_dlls)
(windows_nat::handle_load_dll): Remove.
(get_child_debug_event): Call dll_loaded_event.
|
|
This changes gdbserver to use the function indirection code that was
just moved into nat/windows-nat.[ch]. One additional function is used
by gdbserver that was not used by gdb.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* nat/windows-nat.h (GenerateConsoleCtrlEvent): New define.
(GenerateConsoleCtrlEvent_ftype, GenerateConsoleCtrlEvent):
Declare.
* nat/windows-nat.c (GenerateConsoleCtrlEvent): Define.
(initialize_loadable): Initialize GenerateConsoleCtrlEvent.
gdbserver/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* win32-low.cc (GETPROCADDRESS): Remove.
(winapi_DebugActiveProcessStop, winapi_DebugSetProcessKillOnExit)
(winapi_DebugBreakProcess, winapi_GenerateConsoleCtrlEvent)
(winapi_Wow64SetThreadContext, win32_Wow64GetThreadContext)
(win32_Wow64SetThreadContext): Remove.
(win32_set_thread_context, do_initial_child_stuff)
(win32_process_target::attach, win32_process_target::detach):
Update.
(winapi_EnumProcessModules, winapi_EnumProcessModulesEx)
(winapi_GetModuleInformation, winapi_GetModuleInformationA):
Remove.
(win32_EnumProcessModules, win32_EnumProcessModulesEx)
(win32_GetModuleInformation, win32_GetModuleInformationA):
Remove.
(load_psapi): Remove.
(win32_add_dll, win32_process_target::request_interrupt): Update.
(initialize_low): Call initialize_loadable.
|
|
gdb and gdbserver both look for functions in some Windows DLLs at
runtime. This patch moves this code out of gdb and into
nat/windows-nat, so it can be shared by both programs.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c: Move code to nat/windows-nat.[ch].
(_initialize_windows_nat): Call initialize_loadable.
* nat/windows-nat.h (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation)
(GetModuleFileNameExA, GetModuleFileNameExW)
(LookupPrivilegeValueA, OpenProcessToken, GetConsoleFontSize)
(GetCurrentConsoleFont, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Move from windows-nat.c.
(AdjustTokenPrivileges_ftype)
(DebugActiveProcessStop_ftype, DebugBreakProcess_ftype)
(DebugSetProcessKillOnExit_ftype, EnumProcessModules_ftype)
(EnumProcessModulesEx_ftype, GetModuleInformation_ftype)
(GetModuleFileNameExA_ftype, GetModuleFileNameExW_ftype)
(LookupPrivilegeValueA_ftype, OpenProcessToken_ftype)
(GetConsoleFontSize_ftype)
(GetCurrentConsoleFont_ftype, Wow64SuspendThread_ftype)
(Wow64GetThreadContext_ftype, Wow64SetThreadContext_ftype)
(Wow64GetThreadSelectorEntry_ftype): Likewise.
(initialize_loadable): Declare.
* nat/windows-nat.c (AdjustTokenPrivileges)
(DebugActiveProcessStop, DebugBreakProcess)
(DebugSetProcessKillOnExit, EnumProcessModules)
(EnumProcessModulesEx, GetModuleInformation, GetModuleFileNameExA)
(GetModuleFileNameExW, LookupPrivilegeValueA, OpenProcessToken)
(GetCurrentConsoleFont, GetConsoleFontSize, Wow64SuspendThread)
(Wow64GetThreadContext, Wow64SetThreadContext)
(Wow64GetThreadSelectorEntry): Define.
(bad, bad_GetCurrentConsoleFont, bad_GetConsoleFontSize): Move
from windows-nat.c.
(initialize_loadable): Likewise, and rename.
|
|
windows-nat.c defines a number of replacement functions that simply
return zero. This patch removes these in favor of a couple of
template functions.
gdb/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* windows-nat.c (bad_GetModuleFileNameEx): Remove define.
(bad_DebugActiveProcessStop, bad_DebugBreakProcess)
(bad_DebugSetProcessKillOnExit, bad_EnumProcessModules)
(bad_GetModuleFileNameExW, bad_GetModuleFileNameExA)
(bad_GetModuleInformation, bad_OpenProcessToken): Remove.
(bad): New template functions.
(_initialize_loadable): Update.
|
|
Running the AdaCore internal test suite with -fgnat-encodings=minimal
found a gdb crash. The bug is that GDB ends up with a typedef in
ada_index_type, resulting in a NULL dereference.
This crash can be reproduced using GCC 11 with the included test case.
Tested on x86-64 Fedora 32. Because this is Ada-specific, and was
already reviewed by Joel, I am going to check it in.
2021-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_index_type): Use ada_check_typedef.
gdb/testsuite/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* gdb.ada/enum_idx_packed/pck.ads (My_Enum, My_Array_Type)
(Confused_Array): New types.
* gdb.ada/enum_idx_packed/foo.adb (Confused_Array): New variable.
* gdb.ada/enum_idx_packed.exp: Add new tests.
|
|
Once in a while, I run into this timeout:
...
FAIL: gdb.mi/mi-sym-info.exp: List all variables from debug information \
only (timeout)
...
I can make the timeout reproducible by setting timeout to 8s (instead of the
default 10s) for the duration of that test.
Make the test-case more stable by fixing all timeouts caused by setting
timeout to 5, either by adding with_timeout_factor, or increasing its factor.
Tested on x86_64-linux. Also tested in parallel with stress -c 5, to simulate
a busy system in another way.
gdb/testsuite/ChangeLog:
2021-04-30 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Add with_timeout_factor, and increase
existing timeout factors.
|
|
Since commit 2d61316c32a "[gdb/testsuite] Fix buffer full errors in
gdb.mi/mi-sym-info.exp", we have a duplicate test name:
...
Running src/gdb/testsuite/gdb.mi/mi-sym-info.exp ...
DUPLICATE: gdb.mi/mi-sym-info.exp: List all variables
...
This is caused by a copy-paste accident: the idea was to copy the test, edit
it, and then remove the old test, but I forgot to remove the old one.
Remove it now.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-30 Tom de Vries <tdevries@suse.de>
* gdb.mi/mi-sym-info.exp: Remove duplicate test.
|
|
Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into:
...
FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout)
FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout)
...
The commit adds this line in proc vgdb_start:
...
set vgdbcmd "set remotetimeout 3"
...
which has no effect given that the value of var vgdbcmd is not used before
it's overwritten. We can fix this by doing instead:
...
set_remotetimeout 3
...
The FAIL I'm observing is fixed by increasing the remotetimeout value to 4.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-29 Tom de Vries <tdevries@suse.de>
PR testsuite/27786
* lib/valgrind.exp (vgdb_start): Use set_remotetimeout. Increase
remotetimeout to 4.
|
|
In a review, I suggested to use "namespace gdb::observers" instead of
two separate namespace declarations. I didn't realize that this was a
C++17 feature, which breaks compilers that default to an earlier version
of the language, like g++ 4.8. Change it back to two separate
declarations.
gdb/ChangeLog:
* auto-load.h: Split namespace declaration.
Change-Id: I701537161967fbd9fcc298ff600bd072aab1251d
|
|
These two variables:
struct regcache *regcache = get_thread_regcache (tp);
const address_space *aspace = regcache->aspace ();
are only needed inside the "if". Getting a thread's regcache is a
somewhat expensive operation, so it's good to avoid it if not necessary.
Move the variable declarations and their initialization to the "if"
scope.
gdb/ChangeLog:
* infrun.c (save_waitstatus): Move variables to inner scope.
Change-Id: Ief1463728755b4dcc142c0a0a76896e9d594ae84
|
|
Some errors introduced in commit:
commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9
Date: Thu Aug 27 16:53:13 2020 +0100
gdb: startup commands to control Python extension language
gdb/ChangeLog:
* NEWS: Fix typo and stray full stop.
|
|
Currently, the Ada expression parser treats 'null' as an integer 0.
However, this causes overloading to fail in certain cases.
This patch changes the Ada expression parser to use a special type for
'null'. I chose pointer-to-int0, because I think that's not likely to
be needed for any other Ada expression. Note this works because a
"mod 1" type has an underlying non-zero byte size; the test includes a
check for this.
The output is changed so that "print null", by default, shows "null".
And, ada_type_match is changed both to recognize the special null type
and to remove a bit of weird code related to how pointers are treated
for overload type matching.
Tested on x86-64 Fedora 32. Because this only touches Ada, and Joel
already approved it internally at AdaCore, I am checking it in.
gdb/ChangeLog
2021-04-28 Tom Tromey <tromey@adacore.com>
* ada-exp.y (primary): Use new type for null pointer.
* ada-lang.c (ada_type_match): Remove "may_deref"
parameter. Handle null pointer.
(ada_args_match): Update.
* ada-valprint.c (ada_value_print_ptr, ada_value_print):
Handle null pointer.
gdb/testsuite/ChangeLog
2021-04-28 Tom Tromey <tromey@adacore.com>
* gdb.ada/null_overload.exp: New file.
* gdb.ada/null_overload/foo.adb: New file.
|
|
Clean up a few places where we are not using @env{...} to reference
environment variables.
gdb/doc/ChangeLog:
* gdb.texinfo (Initialization Files): Use @env when referencing
environment variables.
(Shell Commands): Likewise.
(Starting): Likewise.
(Arguments): Likewise.
(Environment): Likewise.
(Edit): Likewise.
(Compiling and Injecting Code): Likewise.
(Files): Likewise.
(Command History): Likewise.
(Screen Size): Likewise.
(Emacs): Likewise.
|
|
Add two new commands to GDB that can be placed into the early
initialization to control how Python starts up. The new options are:
set python ignore-environment on|off
set python dont-write-bytecode auto|on|off
show python ignore-environment
show python dont-write-bytecode
These can be used from GDB's startup file to control how the Python
extension language behaves. These options are equivalent to the -E
and -B flags to python respectively, their descriptions from the
Python man page:
-E Ignore environment variables like PYTHONPATH and PYTHONHOME
that modify the behavior of the interpreter.
-B Don't write .pyc files on import.
gdb/ChangeLog:
* NEWS: Mention new commands.
* python/python.c (python_ignore_environment): New static global.
(show_python_ignore_environment): New function.
(set_python_ignore_environment): New function.
(python_dont_write_bytecode): New static global.
(show_python_dont_write_bytecode): New function.
(set_python_dont_write_bytecode): New function.
(_initialize_python): Register new commands.
gdb/doc/ChangeLog:
* python.texinfo (Python Commands): Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.python/py-startup-opt.exp: New file.
|
|
Now that both Python and Guile are fully initialized from their
respective finish_initialization methods, the "finish" in the method
name doesn't really make sense; initialization starts _and_ finishes
with that method.
As such, this commit renames finish_initialization to just initialize.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* extension-priv.h (struct extension_language_ops): Rename
'finish_initialization' to 'initialize'.
* extension.c (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this, update comment, and updated
the calls to reflect the change in struct extension_language_ops.
* extension.h (finish_ext_lang_initialization): Renamed to...
(ext_lang_initialization): ...this.
* guile/guile.c (gdbscm_finish_initialization): Renamed to...
(gdbscm_initialize): ...this, update comment at definition.
(guile_extension_ops): Update.
* main.c (captured_main_1): Update call to
finish_ext_lang_initialization.
* python/python.c (gdbpy_finish_initialization): Rename to...
(gdbpy_initialize): ...this, update comment at definition, and
update call to do_finish_initialization.
(python_extension_ops): Update.
(do_finish_initialization): Rename to...
(do_initialize): ...this, and update comment.
|
|
Now (thanks to the last few commits) all extension languages are
fully initialised in their finish_initialization method, this commit
delays the call to this method until after the early initialization
files have been processed.
Right now there's no benefit from doing this, but in a later commit I
plan to add new options for Python that will control how Python is
initialized.
With this commit in place, my next commits will allow the user to add
options to their early initialization file and alter how Python starts
up.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Add a call to
finish_ext_lang_initialization.
* top.c (gdb_init): Remove call to finish_ext_lang_initialization.
|
|
Like with the previous commit, this commit delays the initialisation
of the guile extension language until gdbscm_finish_initialization.
This is mostly about splitting the existing gdbscm_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbscm_initialize_*
functions.
Then the call to code previously in _initialize_guile is moved into
gdbscm_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* guile/guile.c (gdbscm_set_backtrace): Add declaration.
(gdbscm_finish_initialization): Add code moved from
_initialize_guile.
(_initialize_guile): Move code to gdbscm_finish_initialization.
* guile/scm-arch.c (gdbscm_initialize_arches): Move some code into
_initialize_scm_arch.
(_initialize_scm_arch): New function.
* guile/scm-block.c (gdbscm_initialize_blocks): Move some code
into _initialize_scm_block.
(_initialize_scm_block): New function.
* guile/scm-frame.c (gdbscm_initialize_frames): Move some code
into _initialize_scm_frame.
(_initialize_scm_frame): New function.
* guile/scm-objfile.c (gdbscm_initialize_objfiles): Move some code
into _initialize_scm_objfile.
(_initialize_scm_objfile): New function.
* guile/scm-progspace.c (gdbscm_initialize_pspaces): Move some
code into _initialize_scm_progspace.
(_initialize_scm_progspace): New function.
* guile/scm-symbol.c (gdbscm_initialize_symbols): Move some code
into _initialize_scm_symbol.
(_initialize_scm_symbol): New function.
* guile/scm-symtab.c (gdbscm_initialize_symtabs): Move some code
into _initialize_scm_symtab.
(_initialize_scm_symtab): New function.
* guile/scm-type.c (gdbscm_initialize_types): Move some code into
_initialize_scm_type.
(_initialize_scm_type): New function.
|
|
Delay Python initialisation until gdbpy_finish_initialization.
This is mostly about splitting the existing gdbpy_initialize_*
functions in two, all the calls to register_objfile_data_with_cleanup,
gdbarch_data_register_post_init, etc are moved into new _initialize_*
functions, but everything else is left in the gdbpy_initialize_*
functions.
Then the call to do_start_initialization (in python/python.c) is moved
from the _initialize_python function into gdbpy_finish_initialization.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/py-arch.c (_initialize_py_arch): New function.
(gdbpy_initialize_arch): Move code to _initialize_py_arch.
* python/py-block.c (_initialize_py_block): New function.
(gdbpy_initialize_blocks): Move code to _initialize_py_block.
* python/py-inferior.c (_initialize_py_inferior): New function.
(gdbpy_initialize_inferior): Move code to _initialize_py_inferior.
* python/py-objfile.c (_initialize_py_objfile): New function.
(gdbpy_initialize_objfile): Move code to _initialize_py_objfile.
* python/py-progspace.c (_initialize_py_progspace): New function.
(gdbpy_initialize_pspace): Move code to _initialize_py_progspace.
* python/py-registers.c (_initialize_py_registers): New function.
(gdbpy_initialize_registers): Move code to
_initialize_py_registers.
* python/py-symbol.c (_initialize_py_symbol): New function.
(gdbpy_initialize_symbols): Move code to _initialize_py_symbol.
* python/py-symtab.c (_initialize_py_symtab): New function.
(gdbpy_initialize_symtabs): Move code to _initialize_py_symtab.
* python/py-type.c (_initialize_py_type): New function.
(gdbpy_initialize_types): Move code to _initialize_py_type.
* python/py-unwind.c (_initialize_py_unwind): New function.
(gdbpy_initialize_unwind): Move code to _initialize_py_unwind.
* python/python.c (_initialize_python): Move call to
do_start_initialization to gdbpy_finish_initialization.
(gdbpy_finish_initialization): Add call to
do_start_initialization.
|
|
In order for our SIGINT handling to work correctly with Python we
require that SIGINT be set to SIG_DFL during Python's initialisation.
Currently this is the case, but, in a later commit I plan to delay the
initialisation of Python until after the point where GDB's own SIGINT
handler has been installed.
The consequence of this is that our SIGINT handling would become
broken.
In this commit I propose adding an RAII class that will ensure SIGINT
is set to SIG_DFL during the call to each extension languages
finish_initialization method.
At this point this change should have not effect.
gdb/ChangeLog:
* extension.c (struct scoped_default_signal): New struct.
(scoped_default_sigint): New typedef.
(finish_ext_lang_initialization): Make use of
scoped_default_sigint.
|
|
The argument to gdb_init is not used, remove it.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* main.c (captured_main_1): Don't pass argument to gdb_init.
* top.c (gdb_init): Remove unused argument, and add header
comment.
* top.h (gdb_init): Remove argument.
|
|
I'm seeing timeouts from gdb.rust/traits.exp when we attempt to print
things with "maint print objfiles".
This happens for two reasons:
1 - GDB does not explicitly split each entry into its own line, but rather
relies on the terminal's width to insert line breaks.
2 - When running the GDB testsuite, such width may be unlimited, which will
prevent GDB from inserting any line breaks.
As a result, the output may be too lengthy and will come in big lines. Tweak
the support library to match the patterns line-by-line, which gives us more
time to match things. Also fix GDB's output to print one entry per line,
regardless of the terminal width.
A similar approach was used in another testcase using the same command (commit
eaeaf44cfdc9a4096a0dd52fa0606f29d4bfd48e). With the new line breaks, we don't
need a particular pattern, so clean up that test as well.
gdb/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* psymtab.c (psymbol_functions::dump): Output newline.
* symmisc.c (dump_objfile): Likewise.
gdb/testsuite/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* gdb.base/maint.exp: Drop a pattern that is not needed.
* lib/gdb.exp (readnow): Match line-by-line.
|
|
For aarch64, the "info all-registers" output is very verbose. If you run
this test using read1, it will timeout before the command output is done being
read.
Read line-by-line so we don't run into timeouts.
gdb/testsuite/ChangeLog:
2021-04-27 Luis Machado <luis.machado@linaro.org>
* gdb.xml/tdesc-reload.exp: Pass -lbl.
|
|
Without any explicit dependencies specified, the observers attached
to the 'gdb::observers::new_objfile' observable are always notified
in the order in which they have been attached.
The new_objfile observer callback to auto-load scripts is attached in
'_initialize_auto_load'.
The new_objfile observer callback that propagates the new_objfile event
to the Python side is attached in 'gdbpy_initialize_inferior', which is
called via '_initialize_python'.
With '_initialize_python' happening before '_initialize_auto_load',
the consequence was that the new_objfile event was emitted on the Python
side before autoloaded scripts had been executed when a new objfile was
loaded.
As a result, trying to access the objfile's pretty printers (defined in
the autoloaded script) from a handler for the Python-side
'new_objfile' event would fail. Those would only be initialized later on
(when the 'auto_load_new_objfile' callback was called).
To make sure that the objfile passed to the Python event handler
is properly initialized (including its 'pretty_printers' member),
make sure that the 'auto_load_new_objfile' observer is notified
before the 'python_new_objfile' one that propagates the event
to the Python side.
To do this, make use of the mechanism to explicitly specify
dependencies between observers (introduced in a preparatory commit).
Add a corresponding testcase that involves a test library with an autoloaded
Python script and a handler for the Python 'new_objfile' event.
(The real world use case where I came across this issue was in an attempt
to extend handling for GDB pretty printers for dynamically loaded
objfiles in the Qt Creator IDE, s. [1] and [2] for more background.)
[1] https://bugreports.qt.io/browse/QTCREATORBUG-25339
[2] https://codereview.qt-project.org/c/qt-creator/qt-creator/+/333857/1
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* gdb/auto-load.c (_initialize_auto_load): 'Specify token
when attaching the 'auto_load_new_objfile' observer, so
other observers can specify it as a dependency.
* gdb/auto-load.h (struct token): Declare
'auto_load_new_objfile_observer_token' as token to be used
for the 'auto_load_new_objfile' observer.
* gdb/python/py-inferior.c (gdbpy_initialize_inferior): Make
'python_new_objfile' observer depend on 'auto_load_new_objfile'
observer, so it gets notified after the latter.
gdb/testsuite/ChangeLog:
* gdb.python/libpy-autoloaded-pretty-printers-in-newobjfile-event.so-gdb.py: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-lib.h: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event-main.cc: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp: New test.
* gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.py: New test.
Change-Id: I8275b3f4c3bec32e56dd7892f9a59d89544edf89
|
|
Previously, the observers attached to an observable were always notified
in the order in which they had been attached. That order is not easily
controlled, because observers are typically attached in _initialize_*
functions, which are called in an undefined order.
However, an observer may require that another observer attached only
later is called before itself is.
Therefore, extend the 'observable' class to allow explicitly specifying
dependencies when attaching observers, by adding the possibility to
specify tokens for observers that it depends on.
To make sure dependencies are notified before observers depending on
them, the vector holding the observers is sorted in a way that
dependencies come before observers depending on them. The current
implementation for sorting uses the depth-first search algorithm for
topological sorting as described at [1].
Extend the observable unit tests to cover this case as well. Check that
this works for a few different orders in which the observers are
attached.
This newly introduced mechanism to explicitly specify dependencies will
be used in a follow-up commit.
[1] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* unittests/observable-selftests.c (dependency_test_counters):
New.
(observer_token0, observer_token1, observer_token2,
observer_token3, observer_token4, observer_token5): New.
(struct dependency_observer_data): New struct.
(observer_dependency_test_callback): New function.
(test_observers): New.
(run_dependency_test): New function.
(test_dependency): New.
(_initialize_observer_selftest): Register dependency test.
gdbsupport/ChangeLog:
* observable.h (class observable): Extend to allow specifying
dependencies between observers, keep vector holding observers
sorted so that dependencies are notified before observers
depending on them.
Change-Id: I5399def1eeb69ca99e28c9f1fdf321d78b530bdb
|
|
PR gdb/27743 points out a gdb crash when expanding partial symtabs,
where one of the compilation units uses DW_TAG_imported_unit.
This crash happens for gdb 10, but not git trunk. This patch pulls
over the new test case only.
gdb/testsuite/ChangeLog
2021-04-26 Tom Tromey <tromey@adacore.com>
PR gdb/27743:
* gdb.dwarf2/imported-unit-bp.exp: New file.
* gdb.dwarf2/imported-unit-bp-main.c: New file.
* gdb.dwarf2/imported-unit-bp-alt.c: New file.
|
|
Bug 27773 shows that passing a filename in a non-existent directory to
the "dump binary" command leads to a gdb crash. This is because the
gdb_fopen_cloexec in dump_binary_file fails (returns nullptr) and the
return value is not checked. Fix that by erroring out if
gdb_fopen_cloexec fails.
gdb/ChangeLog:
PR gdb/27773
* cli/cli-dump.c (dump_binary_file): Check result of
gdb_fopen_cloexec.
gdb/testsuite/ChangeLog:
PR gdb/27773
* gdb.base/dump.exp: Test dump to non-existent dir.
Change-Id: Iea89a3bf9e6b9dcc31142faa5ae17bc855759328
|
|
The test checks for a particular ARCH level, but it needs to check for
ARCH levels from a minimum and upwards.
gdb/testsuite/ChangeLog:
2021-04-26 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-dbreg-contents.c (set_watchpoint): Fix arch level
comparison.
|
|
On sparc build failed as:
```
gdb/sparc-linux-nat.c: In member function
'virtual void sparc_linux_nat_target::fetch_registers(regcache*, int)':
gdb/sparc-linux-nat.c:36:37:
error: cannot convert 'regcache*' to 'process_stratum_target*'
36 | { sparc_fetch_inferior_registers (regcache, regnum); }
| ^~~~~~~~
| |
| regcache*
```
The fix adopts gdb/sparc-nat.h API change in d1e93af64a6
("gdb: set current thread in sparc_{fetch,collect}_inferior_registers").
gdb/ChangeLog:
* sparc-linux-nat.c (sparc_linux_nat_target): fix sparc build
by passing `process_stratum_target*` parameter.
|
|
This commit adds a flag to the ptype command in order to print the
offsets and sizes of struct members using the hexadecimal notation. The
'x' flag ensures use of the hexadecimal notation while the 'd' flag
ensures use of the decimal notation. The default is to use decimal
notation.
Before this patch, gdb only uses decimal notation, as pointed out in PR
gdb/22640.
Here is an example of this new behavior with hex output turned on:
(gdb) ptype /ox struct type_print_options
/* offset | size */ type = struct type_print_options {
/* 0x0000: 0x0 | 0x0004 */ unsigned int raw : 1;
/* 0x0000: 0x1 | 0x0004 */ unsigned int print_methods : 1;
/* 0x0000: 0x2 | 0x0004 */ unsigned int print_typedefs : 1;
/* 0x0000: 0x3 | 0x0004 */ unsigned int print_offsets : 1;
/* 0x0000: 0x4 | 0x0004 */ unsigned int print_in_hex : 1;
/* XXX 3-bit hole */
/* XXX 3-byte hole */
/* 0x0004 | 0x0004 */ int print_nested_type_limit;
/* 0x0008 | 0x0008 */ typedef_hash_table *local_typedefs;
/* 0x0010 | 0x0008 */ typedef_hash_table *global_typedefs;
/* 0x0018 | 0x0008 */ ext_lang_type_printers *global_printers;
/* total size (bytes): 32 */
}
This patch also adds the 'set print type hex' and 'show print type hex'
commands in order to set and inspect the default behavior regarding the
use of decimal or hexadecimal notation when printing struct sizes and
offsets.
Tested using on x86_64.
gdb/ChangeLog:
PR gdb/22640
* typeprint.h (struct type_print_options): Add print_in_hex
flag.
(struct print_offset_data): Add print_in_hex flag, add a
constructor accepting a type_print_options* argument.
* typeprint.c (type_print_raw_options, default_ptype_flags): Set
default value for print_in_hex.
(print_offset_data::indentation): Allow more horizontal space.
(print_offset_data::print_offset_data): Add ctor.
(print_offset_data::maybe_print_hole, print_offset_data::update):
Handle the print_in_hex flag.
(whatis_exp): Handle 'x' and 'd' flags.
(print_offsets_and_sizes_in_hex): Declare.
(set_print_offsets_and_sizes_in_hex): Create.
(show_print_offsets_and_sizes_in_hex): Create.
(_initialize_typeprint): Update help message for the ptype
command, register the 'set print type hex' and 'show print type
hex' commands.
* c-typeprint.c (c_print_type, c_type_print_base_struct_union)
(c_type_print_base): Construct the print_offset_data
object using the type_print_optons parameter.
* rust-lang.c (rust_language::print_type): Construct the
print_offset_data object using the type_print_optons parameter.
* NEWS: Mention the new flags of the ptype command.
gdb/doc/ChangeLog:
PR gdb/22640
* gdb.texinfo (Symbols): Describe the 'x' and 'd' flags of the
ptype command, describe 'set print type hex' and 'show print
type hex' commands. Update 'ptype/o' examples.
gdb/testsuite/ChangeLog:
PR gdb/22640
* gdb.base/ptype-offsets.exp: Add tests to verify the behavior
of 'ptype/ox' and 'ptype/od'. Check that 'set print type hex'
changes the default behavior of 'ptype/o'. Update to take into
account new horizontal layout.
* gdb.rust/simple.exp: Update ptype test to check new horizontal
layout.
* gdb.rust/union.exp: Same.
|
|
Move the declaration of struct type_print_raw_options before struct
print_offset_data to ease upcoming changes. This is a helper commit
intended to make it easier to build a print_offset_data object from
configurations given by a type_print_raw_options.
gdb/ChangeLog:
* typeprint.h (struct type_print_options): Move before
print_offset_data.
|
|
gdb/ChangeLog:
GDB 10.2 released.
|
|
Give a name to each observer, this will help produce more meaningful
debug message.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer> <observer>:
Add name parameter.
<name>: New field.
<attach>: Add name parameter, update all callers.
Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0
|
|
gdb/ChangeLog:
* observable.c (observer_debug): Change to bool.
gdbsupport/ChangeLog:
* observable.h (observer_debug): Change to bool.
Change-Id: I58634235a20740a66eacb1c83bae3cf3304ae1fd
|
|
While working on some changes to 'info sources' I ran into a situation
where I was seeing the same source files reported twice in the output
of the 'info sources' command when using either .gdb_index or the
.debug_name index.
I traced the problem back to some caching in
dwarf2_base_index_functions::map_symbol_filenames; when called GDB
caches the set of filenames, but, filesnames are not removed as the
index entries are expanded into full symtabs. As a result we can end
up seeing filenames reported both from a full symtab _and_ from
a (stale) previously cached index entry.
Now, obviously, when seeing a problem like this the "correct" fix is
to remove the stale entries from the cache, however, I ran a few
experiments to see why this wasn't really hitting us anywhere, and, as
far as I can tell, ::map_symbol_filenames is only called from three
places:
1. The mi command -file-list-exec-source-files,
2. The 'info sources' command, and
3. Filename completion
However, the result of this "bug" is that we will see duplicate
filenames, and readline's completion mechanism already removes
duplicates, so for case #3 we will never see any problems.
Cases #1 and #2 are basically the same, and in each case, to see a
problem we need to ensure we craft the test in a particular way, start
up ensuring we have some unexpected symtabs, then run one of the
commands to populate the cache, then expand one of the symtabs, and
list the sources again. At this point you'll see duplicate entries in
the results. Hardly surprising we haven't randomly hit this situation
in testing.
So, considering that use cases #1 and #2 are certainly not "high
performance" code (i.e. I don't think these justify the need for
caching) this leaves use case #3. Does this use justify the need for
caching? Well the psymbol_functions::map_symbol_filenames function
doesn't seem to do any extra caching, and within
dwarf2_base_index_functions::map_symbol_filenames, the only expensive
bit appears to be the call to dw2_get_file_names, and this already
does its own caching via this_cu->v.quick->file_names.
The upshot of all this analysis was that I'm not convinced the need
for the additional caching is justified, and so, I propose that to fix
the bug in GDB, I just remove the extra caching (for now).
If we later find that the caching _was_ useful, then we can
reintroduce it, but add it back such that it doesn't reintroduce this
bug.
As I was changing dwarf2_base_index_functions::map_symbol_filenames I
replaced the use of htab_up with std::unordered_set.
Tested using target_boards cc-with-debug-names and dwarf4-gdb-index.
gdb/ChangeLog:
* dwarf2/read.c: Add 'unordered_set' include.
(dwarf2_base_index_functions::map_symbol_filenames): Replace
'visited' hash table with 'qfn_cache' unordered_set. Remove use
of per_Bfd->filenames_cache cache, and use function local
filenames_cache instead. Reindent.
* dwarf2/read.h (struct dwarf2_per_bfd) <filenames_cache>: Delete.
gdb/testsuite/ChangeLog:
* gdb.base/info_sources.exp: Add new tests.
|
|
Use a function_view instead of function pointer + data. Actually,
nothing uses the data anyway, but that makes iterate_over_bp_locations
more like iterate_over_breakpoints.
gdb/ChangeLog:
* breakpoint.c (iterate_over_bp_locations): Change callback to
function view, remove data parameter.
* breakpoint.h (iterate_over_bp_locations): Likewise.
* record-full.c (record_full_sync_record_breakpoints): Remove
data parameter.
Change-Id: I66cdc94a505f67bc640bcc66865fb535ee939a57
|
|
I noticed that when using ptype/o, the "<no data fields>" text that
may be emitted is indented incorrectly. This patch fixes the bug and
adds a new test case.
I also removed a stray backslash from ptype-offsets.exp that I noticed
while writing the test. This seemed too trivial to warrant a separate
patch.
gdb/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* c-typeprint.c (c_type_print_base_struct_union): Use
print_spaces_filtered_with_print_options.
gdb/testsuite/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* gdb.base/ptype-offsets.cc (struct empty_member): New.
(main): Use empty_member.
* gdb.base/ptype-offsets.exp: Add new test.
|
|
We don't want to execute this test if Python support is not compiled in
GDB, add the necessary check.
gdb/testsuite/ChangeLog:
* gdb.python/flexible-array-member.exp: Add check for Python
support.
Change-Id: I853b937d2a193a0bb216566bef1a35354264b1c5
|
|
As reported in bug 27757, we get an internal error when doing:
$ cat test.c
struct foo {
int len;
int items[];
};
struct foo *p;
int main() {
return 0;
}
$ gcc test.c -g -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
Reading symbols from ./test...
/home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is because the Python code (typy_range) blindly reads the high
bound of the type of `items` as a constant value. Since it is a
flexible array member, it has no high bound, the property is undefined.
Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
the getters check that you are not getting a property value of the wrong
kind, so this causes a failed assertion.
Fix it by checking if the property is indeed a constant value before
accessing it as such. Otherwise, use 0. This restores the previous GDB
behavior: because the structure was zero-initialized, this is what was
returned before. But now this behavior is explicit and not accidental.
Add a test, gdb.python/flexible-array-member.exp, that is derived from
gdb.base/flexible-array-member.exp. It tests the same things, but
through the Python API. It also specifically tests getting the range
from the various kinds of flexible array member types (AFAIK it wasn't
possible to do the equivalent through the CLI).
gdb/ChangeLog:
PR gdb/27757
* python/py-type.c (typy_range): Check that bounds are constant
before accessing them as such.
* guile/scm-type.c (gdbscm_type_range): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/27757
* gdb.python/flexible-array-member.c: New test.
* gdb.python/flexible-array-member.exp: New test.
* gdb.guile/scm-type.exp (test_range): Add test for flexible
array member.
* gdb.guile/scm-type.c (struct flex_member): New.
(main): Use it.
Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841
|
|
Turn continuations-related functions into methods of the inferior
class. This is a refactoring.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* Makefile.in (COMMON_SFILES): Remove continuations.c.
* inferior.c (inferior::add_continuation): New method, adapted
from 'add_inferior_continuation'.
(inferior::do_all_continuations): New method, adapted from
'do_all_inferior_continuations'.
(inferior::~inferior): Clear the list of continuations directly.
* inferior.h (class inferior) <continuations>: Rename into...
<m_continuations>: ...this and make private.
* continuations.c: Remove.
* continuations.h: Remove.
* event-top.c: Don't include "continuations.h".
Update the users below.
* inf-loop.c (inferior_event_handler)
* infcmd.c (attach_command)
(notice_new_inferior): Update.
|
|
Use lambdas and std::list to track inferior continuations. This is a
refactoring.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* inferior.h (class inferior) <continuations>: Change the type
to be an std::list of std::function's.
Update the references and uses below.
* continuations.c (struct continuation): Delete.
(make_continuation): Delete.
(do_my_continuations_1): Delete.
(do_my_continuations): Delete.
(discard_my_continuations_1): Delete.
(discard_my_continuations): Delete.
(add_inferior_continuation): Update.
(do_all_inferior_continuations): Update.
(discard_all_inferior_continuations): Update.
* continuations.h (add_inferior_continuation): Update to take
an std::function as the parameter.
* infcmd.c (struct attach_command_continuation_args): Delete.
(attach_command_continuation): Delete.
(attach_command_continuation_free_args): Delete.
(attach_command): Update.
(notice_new_inferior): Update.
|
|
Inferior continuations are no longer used by the until and finish
command. It is used only by the attach command and the remote target
upon detecting new inferiors. Update the comment accordingly.
Also update another comment about non-existent thread continuations and
remove an unused #include.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* continuations.h: Update the general comment.
* inferior.h (class inferior) <continuations>: Update the comment.
* interps.c: Do not include "continuations.h".
|
|
The 'err' parameter of 'do_all_inferior_continuations' is effectively
unused. There is only one place where the function is called, and
there the argument is a literal 0. So, remove the parameter.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* continuations.h (do_all_inferior_continuations): Remove the 'err'
parameter. Update the references below.
* continuations.c (do_my_continuations_1)
(do_my_continuations)
(do_all_inferior_continuations): Update.
* inf-loop.c (inferior_event_handler): Update.
* infcmd.c (attach_command_continuation): Update.
|
|
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcmd.c (attach_post_wait): Update the function comment.
|
|
The 'arg' parameter of 'attach_post_wait' is unused. Remove it.
gdb/ChangeLog:
2021-04-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcmd.c (attach_post_wait): Remove the unused parameter 'args'.
Update the references below.
(struct attach_command_continuation_args)
(attach_command_continuation)
(attach_command_continuation_free_args)
(attach_command)
(notice_new_inferior): Update to remove the reference to 'args'.
|
|
Occassionally I run into the following assert:
...
(gdb) PASS: gdb.multi/multi-target-continue.exp: inferior 5
Remote debugging from host ::1, port 49990^M
Process multi-target-continue created; pid = 31241^M
src/gdb/remote-notif.c:113: internal-error: \
void remote_async_get_pending_events_handler(gdb_client_data): \
Assertion `target_is_non_stop_p ()' failed.^M
...
The assert checks target_is_non_stop_p, which is related to the current
target.
Fix this by changing the assert such that it checks non-stopness related to
the event it's handling.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-04-22 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR remote/27710
* remote.c (remote_target_is_non_stop_p): New function.
* remote.h (remote_target_is_non_stop_p): Declare.
* remote-notif.c (remote_async_get_pending_events_handler): Fix assert
to check non-stopness using notif_state->remote rather current target.
|
|
I enabled code coverage and ran the gdb test suite, and noticed that
the new Rust parser was missing testing on a few lines that were easy
to cover. This patch mostly adds tests for certain syntax errors; but
this process also uncovered a couple of real bugs: I must have
cut-and-pasted the 'sizeof' parsing code from some other code, because
it is checking for KW_MUT (the old bison parser did not do this), and
the array length check is actually impossible because a negative
number like '-1' is parsed as two tokens.
gdb/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* rust-parse.c (rust_parser::parse_sizeof): Remove KW_MUT code.
(struct typed_val_int) <val>: Now ULONGEST.
(rust_parser::parse_array_type): Remove negative check.
(rust_lex_int_test): Change 'value' to ULONGEST.
gdb/testsuite/ChangeLog
2021-04-22 Tom Tromey <tom@tromey.com>
* gdb.rust/modules.exp: Add checks for syntax errors.
* gdb.rust/expr.exp: Add checks for syntax errors.
* gdb.rust/simple.exp: Add checks for syntax errors.
|
|
Currently default_addressable_memory_unit_size always returns 1,
indicating 1 byte is 1 octet. If a target has something other than
this (common) setup then the target should override the
default_addressable_memory_unit_size.
However, the bfd library already knows about each targets octets per
byte, so it seems redundant making targets override this method to
tell GDB something it already knows (through bfd).
In this commit I propose to make default_addressable_memory_unit_size
return a value based on bfd's bits per byte. I checked, and for every
target that GDB currently supports the bits per byte in bfd is 8, so
the current behaviour will not change.
In fact, the only targets in bfd that have bits per byte set to
something other than 8 can be found in cpu-tic4x.c and cpu-tic54x.c, I
don't believe these are supported by GDB right now.
I don't propose to remove the ability to override
default_addressable_memory_unit_size, this allows targets additional
flexibility for how to handle weird combinations of byte sizes.
This change was motivated by an out of tree target I was working on,
but it seemed like it was a good change that others might benefit
from.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* arch-utils.c (default_addressable_memory_unit_size): Return a
value based on bfd's bits per byte.
|
|
I noticed some holes in struct dwarf2_per_cu_data. This patch
rearranges the type slightly, and shrinks the size of some fields.
This reduces it from 136 bytes to 112 bytes (on x86-64).
I also reduced the size of the DWARF "version" fields in a couple of
spots. It seemed needless to use a short to hold a value that ranges
from 2 to 5, and this also helped the goal of shrinking
dwarf2_per_cu_data.
2021-04-21 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_cu_data) <dwarf_version>: Now
unsigned char.
(struct dwarf2_per_cu_data): Rearrange.
* dwarf2/comp-unit.h (struct comp_unit_head) <version>: Now
unsigned char.
(struct comp_unit_head): Rearrange.
* dwarf2/comp-unit.c (read_comp_unit_head): Update.
|
|
gdb/testsuite/ChangeLog:
* gdb.base/valgrind-bt.exp: Add gdb_test "break main".
Update expected string for gdb_test "bt".
* lib/valgrind.exp: Add set remotetimeout 3.
Increase vgdb wait from 1 to 2.
Add max-invoke-ms option to vgdb command line.
|
|
Currently gdb has a configure option:
...
$ ./src/gdb/configure --help
...
--without-included-regex
don't use included regex; this is the default on
systems with version 2 of the GNU C library (use
with caution on other system)
...
The configure option controls config.h macro USE_INCLUDED_REGEX, which is
used in gdb/gdb_regex.h to choose between:
- using regex from libiberty (which is included in the binutils-gdb.git repo,
hence the 'included' in USE_INCLUDED_REGEX), or
- using regex.h.
In the former case, the symbol regcomp is remapped to a symbol xregcomp, which
is then provided by libiberty.
In the latter case, the symbol regcomp is resolved at runtime, usually binding
to libc. However, there is no mechanism in place to enforce this.
PR27681 is an example of where that causes problems. On openSUSE Tumbleweed,
the ncurses package got the --with-pcre2 configure switch enabled, and solved
the resulting dependencies using:
...
$ cat /usr/lib64/libncursesw.so
/* GNU ld script */
-INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl))
+INPUT(/lib64/libncursesw.so.6 AS_NEEDED(-ltinfo -ldl -lpcre2-posix -lpcre2-8))
...
This lead to regcomp being bound to libpcre2-posix instead of libc.
This causes problems in several ways:
- by compiling using regex.h, we've already chosen a specific regex_t
implementation, and the one from pcre2-posix is not the same.
- in gdb_regex.c we use GNU regex function re_search, which pcre2-posix
doesn't provide, so while regcomp binds to pcre2-posix, re_search binds to
libc.
A note on the latter: it's actually a bug to compile a regex using regcomp and
then pass it to re_search. The GNU regex interface requires one to use
re_compile_pattern or re_compile_fastmap. But as long we're using one of the
GNU regex incarnations in gnulib, glibc or libiberty, we get away with this.
The PR could be fixed by adding -lc in a specific position in the link line,
to force regcomp to be bound to glibc. But this solution was considered
in the discussion in the PR as being brittle, and possibly causing problems
elsewhere.
Another solution offered was to restrict regex usage to posix, and no longer
use the GNU regex API. This however could mean having to reproduce some of
that functionality locally, which would mean maintaining the same
functionality in more than one place.
The solution chosen here, is to hardcode --with-included-regex, that is, using
libiberty.
The option of using glibc for regex was introduced because glibc became the
authorative source for GNU regex, so it offered the possibility to link
against a more up-to-date regex version.
In that aspect, this patch is a step back. But we have the option of using a
more up-to-date regex version as a follow-up step: by using the regex from
gnulib.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-04-21 Tom de Vries <tdevries@suse.de>
PR build/27681
* configure.ac: Remove --without-included-regex/--with-included-regex.
* config.in: Regenerate.
* configure: Regenerate.
* gdb_regex.h: Assume USE_INCLUDED_REGEX is defined.
|
