Commit Graph

46959 Commits

Author SHA1 Message Date
Tom Tromey
e228ef975e Share DLL code between gdb and gdbserver
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.
2021-04-30 10:22:24 -06:00
Tom Tromey
de07187290 Use nat/windows-nat function indirection code
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.
2021-04-30 10:22:24 -06:00
Tom Tromey
9e439f0098 Move function indirection code to nat/windows-nat
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.
2021-04-30 10:22:24 -06:00
Tom Tromey
1053c6389a Use template functions in windows-nat.c
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.
2021-04-30 10:22:23 -06:00
Tom Tromey
2869ac4b59 Fix crash with GNAT minimal encodings
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.
2021-04-30 07:33:01 -06:00
Tom de Vries
5536f0cc62 [gdb/testsuite] Make gdb.mi/mi-sym-info.exp more robust against timeouts
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.
2021-04-30 11:25:47 +02:00
Tom de Vries
7f7f284dfe [gdb/testsuite] Fix duplicate test name in gdb.mi/mi-sym-info.exp
Since commit 2d61316c32 "[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.
2021-04-30 11:25:47 +02:00
Tom de Vries
3f33407487 [gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.exp
Since commit 6d5702a5eb "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.
2021-04-29 23:32:20 +02:00
Simon Marchi
e197dfae62 gdb: don't use C++17 namespace declaration style
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
2021-04-29 16:24:49 -04:00
Simon Marchi
89ba430c6b gdb: move some variables to an inner scope in save_waitstatus
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
2021-04-29 10:16:28 -04:00
Andrew Burgess
8eb82ba1fd gdb/NEWS: Fix typo and stray full stop
Some errors introduced in commit:

  commit edeaceda7b
  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.
2021-04-29 10:31:16 +01:00
Tom Tromey
db2534b704 Fix Ada overloading with 'null'
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.
2021-04-28 10:19:57 -06:00
Andrew Burgess
e43c3e2a74 gdb/doc: use @env to reference environment variables
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.
2021-04-28 13:29:52 +01:00
Andrew Burgess
edeaceda7b gdb: startup commands to control Python extension language
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.
2021-04-28 09:56:22 +01:00
Andrew Burgess
041ca48e97 gdb: extension languages finish_initialization to initialize
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.
2021-04-28 09:56:21 +01:00
Andrew Burgess
1178f01adf gdb: initialise extension languages after processing early startup files
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.
2021-04-28 09:56:20 +01:00
Andrew Burgess
880ae75a2b gdb delay guile initialization until gdbscm_finish_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.
2021-04-28 09:56:20 +01:00
Andrew Burgess
8e3685bf25 gdb: delay python initialisation until gdbpy_finish_initialization
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.
2021-04-28 09:56:20 +01:00
Andrew Burgess
913832e99c gdb: ensure SIGINT is set to SIG_DFL during initialisation
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.
2021-04-28 09:56:19 +01:00
Andrew Burgess
a3b5ef3e45 gdb: remove unused argument from gdb_init
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.
2021-04-28 09:56:19 +01:00
Luis Machado
b9f90c72ee Fix timeout with maint print objfiles
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
eaeaf44cfd). 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.
2021-04-27 20:42:07 -03:00
Luis Machado
4b62a30d5b Fix timeout for gdb.xml/tdesc-reload.exp
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.
2021-04-27 20:40:44 -03:00
Michael Weghorn
2c473def12 gdb: do autoload before notifying Python side in new_objfile event
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
2021-04-27 11:22:32 -04:00
Michael Weghorn
9a6e099f43 gdbsupport: allow to specify dependencies between observers
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
2021-04-27 11:22:32 -04:00
Tom Tromey
e8b6c1da56 Add test case for gdb 10 crash
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.
2021-04-26 09:53:32 -06:00
Simon Marchi
bea3329b76 gdb: check result of gdb_fopen_cloexec in dump_binary_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
2021-04-26 11:27:07 -04:00
Luis Machado
21f9178575 Fix gdb.arch/aarch64-dbreg-contents.exp FAIL
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.
2021-04-26 09:50:21 -03:00
Sergei Trofimovich
c290cb01fa gdb: fix sparc build failure of linux-nat
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 d1e93af64a
("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.
2021-04-26 07:22:08 +01:00
Lancelot SIX
fbb46296d7 [PR gdb/22640] ptype: add option to use hexadecimal notation
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.
2021-04-25 18:00:54 +01:00
Lancelot SIX
18bbba46a9 gdb/typeprint.h: reorder struct declaration
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.
2021-04-25 17:55:09 +01:00
Joel Brobecker
77393c9b18 Document the GDB 10.2 release in gdb/ChangeLog
gdb/ChangeLog:

	GDB 10.2 released.
2021-04-25 08:19:04 +04:00
Simon Marchi
c90e7d6352 gdbsupport, gdb: give names to observers
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
2021-04-24 19:26:41 -04:00
Simon Marchi
98c897e37a gdbsupport, gdb: change observer_debug to bool
gdb/ChangeLog:

	* observable.c (observer_debug): Change to bool.

gdbsupport/ChangeLog:

	* observable.h (observer_debug): Change to bool.

Change-Id: I58634235a20740a66eacb1c83bae3cf3304ae1fd
2021-04-23 16:28:26 -04:00
Andrew Burgess
9fc2995588 gdb: remove some caching from the dwarf reader
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.
2021-04-23 09:40:42 +01:00
Simon Marchi
0406545d06 gdb: use function_view for iterate_over_bp_locations' callback
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
2021-04-22 22:01:19 -04:00
Tom Tromey
432ce4cf68 Fix ptype/o bug with "<no data fields>"
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.
2021-04-22 19:39:56 -06:00
Simon Marchi
a87caa6d52 gdb/testsuite: add Python support check in gdb.python/flexible-array-member.exp
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
2021-04-22 15:45:34 -04:00
Simon Marchi
e25d6d93c4 gdb: fix getting range of flexible array member in Python
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
2021-04-22 15:01:28 -04:00
Tankut Baris Aktemur
4efeb0d3e8 gdb/continuations: turn continuation functions into inferior methods
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.
2021-04-22 17:22:39 +02:00
Tankut Baris Aktemur
c4c493de2b gdb/continuations: use lambdas instead of function pointers
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.
2021-04-22 17:22:39 +02:00
Tankut Baris Aktemur
1194676e0b gdb/continuations: do minor cleanup
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".
2021-04-22 17:22:39 +02:00
Tankut Baris Aktemur
35682f0a64 gdb/continuations: remove the 'err' from 'do_all_inferior_continuations'
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.
2021-04-22 17:22:38 +02:00
Tankut Baris Aktemur
6fee5eee88 gdb/infcmd: update the comment for 'attach_post_wait'
gdb/ChangeLog:
2021-04-22  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* infcmd.c (attach_post_wait): Update the function comment.
2021-04-22 17:22:38 +02:00
Tankut Baris Aktemur
27d0790a58 gdb/infcmd: remove the unused parameter 'args' in 'attach_post_wait'
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'.
2021-04-22 17:22:38 +02:00
Tom de Vries
c39ebbf43f [gdb] Fix assert in remote_async_get_pending_events_handler
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.
2021-04-22 17:01:00 +02:00
Tom Tromey
22f80c0f77 Improve code coverage of Rust testing
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.
2021-04-22 07:16:36 -06:00
Andrew Burgess
05f3c0f09e gdb: allow default_addressable_memory_unit_size to handle more cases
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.
2021-04-22 09:16:54 +01:00
Tom Tromey
7e7a35fbca Shrink size of dwarf2_per_cu_data
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.
2021-04-21 16:57:31 -06:00
Carl Love
6d5702a5eb Fix test case gdb.base/valgrind-bt.exp.
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.
2021-04-21 16:17:03 -05:00
Tom de Vries
ff50752029 [gdb/build] Hardcode --with-included-regex
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.
2021-04-21 21:54:03 +02:00
Tankut Baris Aktemur
10a636ccb4 gdb/breakpoint: add a 'force_condition' parameter to 'create_breakpoint'
The 'create_breakpoint' function takes a 'parse_extra' argument that
determines whether the condition, thread, and force-condition
specifiers should be parsed from the extra string or be used from the
function arguments.  However, for the case when 'parse_extra' is
false, there is no way to pass the force-condition specifier.  This
patch adds it as a new argument.

Also, in the case when parse_extra is false, the current behavior is
as if the condition is being forced.  This is a bug.  The default
behavior should reject the breakpoint.  See below for a demo of this
incorrect behavior.  (The MI command '-break-insert' uses the
'create_breakpoint' function with parse_extra=0.)

  $ gdb -q --interpreter=mi3 /tmp/simple
  =thread-group-added,id="i1"
  =cmd-param-changed,param="history save",value="on"
  =cmd-param-changed,param="auto-load safe-path",value="/"
  ~"Reading symbols from /tmp/simple...\n"
  (gdb)
  -break-insert -c junk -f main
  &"warning: failed to validate condition at location 1, disabling:\n  "
  &"No symbol \"junk\" in current context.\n"
  ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="1.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
  (gdb)
  break main if junk
  &"break main if junk\n"
  &"No symbol \"junk\" in current context.\n"
  ^error,msg="No symbol \"junk\" in current context."
  (gdb)
  break main -force-condition if junk
  &"break main -force-condition if junk\n"
  ~"Note: breakpoint 1 also set at pc 0x114e.\n"
  &"warning: failed to validate condition at location 1, disabling:\n  "
  &"No symbol \"junk\" in current context.\n"
  ~"Breakpoint 2 at 0x114e: file /tmp/simple.c, line 2.\n"
  =breakpoint-created,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",cond="junk",times="0",original-location="main",locations=[{number="2.1",enabled="N",addr="0x000000000000114e",func="main",file="/tmp/simple.c",fullname="/tmp/simple.c",line="2",thread-groups=["i1"]}]}
  ^done
  (gdb)

After applying this patch, we get the behavior below:

  (gdb)
  -break-insert -c junk -f main
  ^error,msg="No symbol \"junk\" in current context."

This restores the behavior that is present in the existing releases.

gdb/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* breakpoint.h (create_breakpoint): Add a new parameter,
	'force_condition'.
	* breakpoint.c (create_breakpoint): Use the 'force_condition'
	argument when 'parse_extra' is false to check if the condition
	is invalid at all of the breakpoint locations.
	Update the users below.
	(break_command_1)
	(dprintf_command)
	(trace_command)
	(ftrace_command)
	(strace_command)
	(create_tracepoint_from_upload): Update.
	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update.
	* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Update.
	* python/py-breakpoint.c (bppy_init): Update.
	* python/py-finishbreakpoint.c (bpfinishpy_init): Update.

gdb/testsuite/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.mi/mi-break.exp: Extend with checks for invalid breakpoint
	conditions.
2021-04-21 16:47:17 +02:00
Simon Marchi
98e713abc6 testsuite, gdb.mi: fix duplicate test names in mi-break.exp
gdb/testsuite/ChangeLog:
2021-04-21  Simon Marchi  <simon.marchi@polymtl.ca>
	    Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.mi/mi-break.exp: Fix the duplicate test names.
2021-04-21 16:47:16 +02:00
Tankut Baris Aktemur
85c88e2a79 gdb/breakpoint: display "N" on MI for disabled-by-condition locations
For breakpoint locations that are disabled because of an invalid
condition, CLI displays "N*" in the 'enabled' field, where '*' refers
to the footnote below the table:

  (*): Breakpoint condition is invalid at this location.

This is not necessary for MI, where we shall simply print "N" without
the footnote.

Update the document to mention the "N" value for the MI.  Also remove
the line about the 'enable' field, because there is no such field for
locations.

gdb/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* breakpoint.c (print_one_breakpoint_location): Display "N" for
	disabled-by-condition locations on MI-like output.
	(breakpoint_1): Do not display the disabled-by-condition footnote
	if the output is MI-like.

gdb/doc/ChangeLog:
2021-04-21  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.texinfo (GDB/MI Breakpoint Information): Update the
	description for the 'enabled' field of breakpoint locations.
2021-04-21 16:47:16 +02:00
Frederic Cambus
fd34472cdc update-netbsd.sh: fix script name, update year range in copyright.
Fix the script name and year range in update-netbsd.sh.

gdb/ChangeLog
2021-04-21  Frederic Cambus  <fred@statdns.com>

	* syscalls/update-netbsd.sh: Fix script name display in usage, and
	update year range in generated copyright notices.
2021-04-21 08:05:14 -06:00
Felix Willgerodt
184dcd81c7 gdb: Fix reduce/reduce conflicts for qualifier_seq_noopt in the C parser.
This fixes a problem with GDB's address space qualifier parsing.  GDB uses
'@' as a way to express an address space in expression evaluation.  This can
currently lead to a crash for "Add support for the __flash qualifier on AVR"
(487d975399), the only user I am aware of.

Program:
~~~
const __flash char data_in_flash = 0xab;

int
main (void)
{
  const __flash char *pointer_to_flash = &data_in_flash;
}
~~~

Before:
~~~
(gdb) p data_in_flash
$1 = -85 '\253'
(gdb) p *(const char * @flash) pointer_to_flash
$2 = -85 '\253'
(gdb) p *(@flash const char *) pointer_to_flash
type-stack.c:201: internal-error: type* type_stack::follow_types(type*): unrecognized tp_ value in follow_types
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
~~~

After:
~~~
(gdb) p data_in_flash
$1 = -85 '\253'
(gdb) p *(const char *) pointer_to_flash
$2 = 0 '\000'
(gdb) p *(const char * @flash) pointer_to_flash
$3 = -85 '\253'
(gdb) p *(@flash const char *) pointer_to_flash
$4 = 0 '\000'
(gdb)
~~~

Note that how the binding of this qualifier is interpreted and resolved for an
address/pointer is target specific.  Hence only the prepended qualifier works
for AVR, even if it seems syntactically incorrect.  I won't change this for
AVR, as I am not familiar with that target.

Bison now also complains about less conflicts:

Before:
  YACC   c-exp.c
gdb/gdb/c-exp.y: warning: 153 shift/reduce conflicts [-Wconflicts-sr]
gdb/gdb/c-exp.y: warning: 70 reduce/reduce conflicts [-Wconflicts-rr]

After:
  YACC   c-exp.c
gdb/gdb/c-exp.y: warning: 60 shift/reduce conflicts [-Wconflicts-sr]
gdb/gdb/c-exp.y: warning: 69 reduce/reduce conflicts [-Wconflicts-rr]

gdb/ChangeLog:
2021-04-20  Felix Willgerodt  <felix.willgerodt@intel.com>

	* c-exp.y (qualifier_seq_noopt): Replace qualifier_seq with
	qualifier_seq_noopt.
2021-04-20 08:44:17 +02:00
Felix Willgerodt
525174e886 gdb: Allow address space qualifier parsing in C++.
The goal of this patch is to allow target dependent address space qualifiers
in the C++ expression parser.  This can be useful for memory examination on
targets that actually use different address spaces in hardware without
having to deep-dive into implementation details of the whole solution.

GDB uses the @ symbol to parse address space qualifiers.  The only current
user that I am aware of is the __flash support for avr, which was added in
"Add support for the __flash qualifier on AVR"
(487d975399)
and only works for C.

One use-case of the AVR patch is:

~~~
const __flash char data_in_flash = 0xab;

int
main (void)
{
  const __flash char *pointer_to_flash = &data_in_flash;
}
~~~

~~~
(gdb) print pointer_to_flash
$1 = 0x1e8 <data_in_flash> "\253"
(gdb) print/x *pointer_to_flash
$2 = 0xab
(gdb) x/x pointer_to_flash
0x1e8 <data_in_flash>: 0xXXXXXXab
(gdb)
(gdb) p/x *(char* @flash) pointer_to_flash
$3 = 0xab
~~~

I want to enable a similar usage of e.g. @local in C++.

Before this patch (using "set debug parser on"):

~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
A syntax error in expression, near `local) &x'.
~~~

After:
~~~
(gdb) p *(int* @local) 0x1234
(...)
Reading a token: Next token is token '@' ()
Shifting token '@' ()
Entering state 46
Reading a token: Next token is token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Shifting token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
Entering state 121
Reducing stack by rule 278 (line 1773):
   $1 = token UNKNOWN_CPP_NAME (ssym<name=local, sym=(null), field_of_this=0>)
-> $$ = nterm name ()
Stack now 0 49 52 76 222 337 46
Entering state 167
Reducing stack by rule 131 (line 1225):
   $1 = token '@' ()
   $2 = nterm name ()
Unknown address space specifier: "local"
~~~

The "Unknown address space qualifier" is the right behaviour, as I ran this
on a target that doesn't have multiple address spaces and therefore obviously
no support for such qualifiers.

gdb/ChangeLog:
2021-04-20  Felix Willgerodt  <felix.willgerodt@intel.com>

	* c-exp.y (single_qualifier): Handle UNKNOWN_CPP_NAME.

gdb/testsuite/ChangeLog:
2021-04-20  Felix Willgerodt  <felix.willgerodt@intel.com>

	* gdb.base/address_space_qualifier.exp: New file.
2021-04-20 08:43:09 +02:00
Andrew Burgess
f5dc2ee39d gdb: use compiled_regex instead of std::regex
In GDB we should be using compiled_regex instead of std::regex.
Replace one use in producer.c.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* producer.c: Replace 'regex' include with 'gdb_regex.h'.
	(producer_is_icc): Replace use of std::regex with gdb's
	compiled_regex.
2021-04-19 18:28:57 +01:00
Tom Tromey
392e0bcc0e Fix kfail patterns in inline-locals.exp
PR gdb/27742 points out that my recent change to
print_variable_and_value caused a regression in inline-locals.exp.  I
can't reproduce this, but I came up with this patch based on the
output shown in the bug.

gdb/testsuite/ChangeLog
2021-04-19  Tom Tromey  <tromey@adacore.com>

	PR gdb/27742:
	* gdb.opt/inline-locals.exp: Update kfail patterns.
2021-04-19 07:16:34 -06:00
Tom Tromey
42c2c69462 Handle unaligned mapping of .gdb_index
The .gdb_index was designed such that all data would be aligned.
Unfortunately, we neglected to require this alignment in the objcopy
instructions in the manual.  As a result, in many cases, a .gdb_index
in the wild will not be properly aligned by mmap.  This yields
undefined behavior, which is PR gdb/23743.

This patch fixes the bug by always assuming that the mapping is
unaligned, and using extract_unsigned_integer when needed.  A new
helper class is introduced to make this less painful.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	PR gdb/23743:
	* dwarf2/read.c (class offset_view): New.
	(struct symbol_table_slot): Remove.
	(struct mapped_index) <symbol_table, constant_pool>: Change type.
	<symbol_name_index, symbol_vec_index>: New methods.
	<symbol_name_slot_invalid, symbol_name_at, symbol_name_count>:
	Rewrite.
	(read_gdb_index_from_buffer): Update.
	(struct dw2_symtab_iterator) <vec>: Change type.
	(dw2_symtab_iter_init_common, dw2_symtab_iter_init)
	(dw2_symtab_iter_next, dw2_expand_marked_cus): Update.
	* dwarf2/index-write.c (class data_buf) <append_data>: Remove.
	<append_array, append_offset>: New methods.
	(write_hash_table, add_address_entry, write_gdbindex_1)
	(write_debug_names): Update.
	* dwarf2/index-common.h (byte_swap, MAYBE_SWAP): Remove.
2021-04-17 13:56:36 -06:00
Tom Tromey
da314dd397 Avoid crash in write_psymtabs_to_index
If I try "save gdb-index" using the executable from
gdb.cp/cmpd-minsyms.exp, gdb will crash.  This happens due to a
missing NULL check.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* dwarf2/index-write.c (write_psymtabs_to_index): Check
	partial_symtabs.

gdb/testsuite/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* gdb.dwarf2/gdb-index-nodebug.exp: New file.
2021-04-17 13:40:04 -06:00
Tom Tromey
0b7b2c2adf Simplify quick_symbol_functions::map_matching_symbols
quick_symbol_functions::map_matching_symbols is only used by the Ada
code.  Currently, it both expands certain psymtabs and then walks over
the full symtabs -- including any already-expanded ones -- calling a
callback.

It appears to work lazily as well, in that if the callback returns
false, iteration stops.  However, only the psymtab implementation does
this; the DWARF index implementations are not lazy.  It turns out,
though, that the only callback that is ever passed here never returns
false.

This patch simplifies this method by removing the callback.  The
method is also renamed.  In the new scheme, the caller is responsible
for walking the full symtabs, which removes some redundancy as well.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* psymtab.c (psymbol_functions::expand_matching_symbols): Rename
	from map_matching_symbols.  Change parameters.
	* psympriv.h (struct psymbol_functions) <expand_matching_symbols>:
	Rename from map_matching_symbols.  Change parameters.
	* dwarf2/read.c (struct dwarf2_gdb_index)
	<expand_matching_symbols>: Rename from map_matching_symbols.
	Change parameters.
	(struct dwarf2_debug_names_index) <expand_matching_symbols>:
	Rename from map_matching_symbols.  Change parameters.
	(dwarf2_gdb_index::expand_matching_symbols): Rename from
	dw2_map_matching_symbols.  Change parameters.
	(dwarf2_gdb_index::expand_matching_symbols): Remove old
	implementation.
	(dwarf2_debug_names_index::expand_matching_symbols): Rename from
	map_matching_symbols.  Change parameters.
	* objfiles.h (struct objfile) <expand_matching_symbols>: Rename
	from map_matching_symbols.  Change parameters.
	* symfile-debug.c (objfile::expand_matching_symbols): Rename from
	map_matching_symbols.  Change parameters.
	* ada-lang.c (map_matching_symbols): New function.
	(add_nonlocal_symbols): Update.
2021-04-17 09:35:06 -06:00
Tom Tromey
90160b5703 Remove quick_symbol_functions::expand_symtabs_with_fullname
This removes quick_symbol_functions::expand_symtabs_with_fullname,
replacing it with a call to expand_symtabs_matching.  As with the
previous patches, the implementation is consolidated in the objfile
method.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* quick-symbol.h (struct quick_symbol_functions)
	<expand_symtabs_with_fullname>: Remove.
	* psymtab.c (psymbol_functions::expand_symtabs_with_fullname):
	Remove.
	* psympriv.h (struct psymbol_functions)
	<expand_symtabs_with_fullname>: Remove.
	* dwarf2/read.c (struct dwarf2_base_index_functions)
	<expand_symtabs_with_fullname>: Remove.
	(dwarf2_base_index_functions::expand_symtabs_with_fullname):
	Remove.
	* objfiles.h (struct objfile) <expand_symtabs_with_fullname>:
	Update comment.
	* symfile-debug.c (objfile::expand_symtabs_with_fullname):
	Rewrite.
2021-04-17 09:35:06 -06:00
Tom Tromey
7089bd886e Remove quick_symbol_functions::expand_symtabs_for_function
This removes quick_symbol_functions::expand_symtabs_for_function,
replacing it with a call to expand_symtabs_matching.  As with the
previous patches, the implementation is consolidated in the objfile
method.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symfile-debug.c (objfile::expand_symtabs_for_function):
	Rewrite.
	* quick-symbol.h (struct quick_symbol_functions)
	<expand_symtabs_for_function>: Remove.
	* psymtab.c (psymbol_functions::expand_symtabs_for_function):
	Remove.
	* psympriv.h (struct psymbol_functions)
	<expand_symtabs_for_function>: Remove.
	* objfiles.h (struct objfile) <expand_symtabs_for_function>:
	Update comment.
	* dwarf2/read.c (struct dwarf2_gdb_index)
	<expand_symtabs_for_function>: Remove.
	(struct dwarf2_debug_names_index) <expand_symtabs_for_function>:
	Remove.
	(find_slot_in_mapped_hash): Remove.
	(dw2_symtab_iter_init_common): Merge with dw2_symtab_iter_init.
	(dw2_symtab_iter_init): Remove one overload.
	(dwarf2_gdb_index::expand_symtabs_for_function)
	(dwarf2_debug_names_index::expand_symtabs_for_function): Remove.
2021-04-17 09:35:06 -06:00
Tom Tromey
536a40f3a8 Remove quick_symbol_functions::map_symtabs_matching_filename
This replaces quick_symbol_functions::map_symtabs_matching_filename
with a call to expand_symtabs_matching.  As with the previous patch,
rather than update all callers, the implementation is consolidated in
objfile::map_symtabs_matching_filename.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symfile-debug.c (objfile::map_symtabs_matching_filename):
	Rewrite.
	* quick-symbol.h (struct quick_symbol_functions)
	<map_symtabs_matching_filename>: Remove.
	* psymtab.c (partial_map_expand_apply)
	(psymbol_functions::map_symtabs_matching_filename): Remove.
	* psympriv.h (struct psymbol_functions)
	<map_symtabs_matching_filename>: Remove.
	* objfiles.h (struct objfile) <map_symtabs_matching_filename>:
	Update comment.
	* dwarf2/read.c (struct dwarf2_base_index_functions)
	<map_symtabs_matching_filename>: Remove.
	(dw2_map_expand_apply)
	(dwarf2_base_index_functions::map_symtabs_matching_filename):
	Remove.
2021-04-17 09:35:06 -06:00
Tom Tromey
84d865e39c Remove quick_symbol_functions::lookup_symbol
This removes quick_symbol_functions, replacing it with calls to
expand_symtabs_matching.  Because the replacement is somewhat verbose,
objfile::lookup_symbol is not removed.  This consolidates some
duplicated code into this one spot.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symfile-debug.c (objfile::lookup_symbol): Rewrite.
	* quick-symbol.h (struct quick_symbol_functions) <lookup_symbol>:
	Remove.
	* psymtab.c (psymbol_functions::lookup_symbol): Remove.
	* psympriv.h (struct psymbol_functions) <lookup_symbol>: Remove.
	* objfiles.h (struct objfile) <lookup_symbol>: Add comment.
	* dwarf2/read.c (struct dwarf2_gdb_index) <lookup_symbol>:
	Remove.
	(struct dwarf2_debug_names_index) <lookup_symbol>: Remove.
	(dwarf2_gdb_index::lookup_symbol)
	(dwarf2_debug_names_index::lookup_symbol): Remove.
2021-04-17 09:35:05 -06:00
Tom Tromey
3bfa51a75f Add 'domain' parameter to expand_symtabs_matching
Currently, expand_symtabs_matching only accepts a search_domain
parameter.  However, lookup_symbol uses a domain_enum instead, and the
two, confusingly, do quite different things -- one cannot emulate the
other.  So, this patch adds a domain_enum parameter to
expand_symtabs_matching, with UNDEF_DOMAIN used as a wildcard.

This is another step toward replacing lookup_symbol with
expand_symtabs_matching.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symtab.c (global_symbol_searcher::expand_symtabs): Update.
	* symmisc.c (maintenance_expand_symtabs): Update.
	* symfile.c (expand_symtabs_matching): Update.
	* symfile-debug.c (objfile::expand_symtabs_matching): Add 'domain'
	parameter.
	* quick-symbol.h (struct quick_symbol_functions)
	<expand_symtabs_matching>: Add 'domain' parameter.
	* psymtab.c (recursively_search_psymtabs)
	(psymbol_functions::expand_symtabs_matching): Add 'domain'
	parameter.
	* psympriv.h (struct psymbol_functions) <expand_symtabs_matching>:
	Add 'domain' parameter.
	* objfiles.h (struct objfile) <expand_symtabs_matching>: Add
	'domain' parameter.
	* linespec.c (iterate_over_all_matching_symtabs): Update.
	* dwarf2/read.c (struct dwarf2_gdb_index)
	<expand_symtabs_matching>: Add 'domain' parameter.
	(struct dwarf2_debug_names_index) <expand_symtabs_matching>: Add
	'domain' parameter.
	(dw2_expand_symtabs_matching)
	(dwarf2_gdb_index::expand_symtabs_matching)
	(dw2_debug_names_iterator)
	(dwarf2_debug_names_index::expand_symtabs_matching): Add 'domain'
	parameter.
2021-04-17 09:35:05 -06:00
Tom Tromey
03a8ea51c3 Add search_flags to expand_symtabs_matching
This adds a block search flags parameter to expand_symtabs_matching.
All callers are updated to search both the static and global blocks,
as that was the implied behavior before this patch.

This is a step toward replacing lookup_symbol with
expand_symtabs_matching.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symtab.c (global_symbol_searcher::expand_symtabs)
	(default_collect_symbol_completion_matches_break_on): Update.
	* symmisc.c (maintenance_expand_symtabs): Update.
	* symfile.h (expand_symtabs_matching): Add search_flags
	parameter.
	* symfile.c (expand_symtabs_matching): Add search_flags
	parameter.
	* symfile-debug.c (objfile::expand_symtabs_matching): Add
	search_flags parameter.
	* quick-symbol.h (struct quick_symbol_functions)
	<expand_symtabs_matching>: Add search_flags parameter.
	* python/py-symbol.c (gdbpy_lookup_static_symbols): Update.
	* psymtab.c (recursively_search_psymtabs)
	(psymbol_functions::expand_symtabs_matching): Add search_flags
	parameter.
	* psympriv.h (struct psymbol_functions) <expand_symtabs_matching>:
	Add search_flags parameter.
	* objfiles.h (struct objfile) <expand_symtabs_matching>: Add
	search_flags parameter.
	* linespec.c (iterate_over_all_matching_symtabs): Update.
	* dwarf2/read.c (struct dwarf2_gdb_index)
	<expand_symtabs_matching>: Add search_flags parameter.
	(struct dwarf2_debug_names_index) <expand_symtabs_matching>: Add
	search_flags parameter.
	(dw2_map_matching_symbols): Update.
	(dw2_expand_marked_cus, dw2_expand_symtabs_matching)
	(dwarf2_gdb_index::expand_symtabs_matching): Add search_flags
	parameter.
	(dw2_debug_names_iterator): Change block_index to search flags.
	<m_block_index>: Likewise.
	(dw2_debug_names_iterator::next)
	(dwarf2_debug_names_index::lookup_symbol)
	(dwarf2_debug_names_index::expand_symtabs_for_function)
	(dwarf2_debug_names_index::map_matching_symbols)
	(dwarf2_debug_names_index::map_matching_symbols): Update.
	(dwarf2_debug_names_index::expand_symtabs_matching): Add
	search_flags parameter.
	* ada-lang.c (ada_add_global_exceptions)
	(collect_symbol_completion_matches): Update.
2021-04-17 09:35:05 -06:00
Tom Tromey
df35e6262d Let expand_symtabs_matching short-circuit
This changes expand_symtabs_exp_notify_ftype to return bool, and
updates all the uses.  Now, if the notification function returns
false, the call is short-circuited and stops examining symtabs.  This
is a step toward replacing map_symtabs_matching_filename with
expand_symtabs_matching.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* symtab.c (default_collect_symbol_completion_matches_break_on):
	Update.
	* symfile.h (expand_symtabs_matching): Return bool.
	* symfile.c (expand_symtabs_matching): Return bool.
	* symfile-debug.c (objfile::expand_symtabs_matching): Return
	bool.
	* quick-symbol.h (expand_symtabs_exp_notify_ftype): Return bool.
	(struct quick_symbol_functions) <expand_symtabs_matching>: Return
	bool.
	* psymtab.c (psymbol_functions::expand_symtabs_matching): Return
	bool.
	* psympriv.h (struct psymbol_functions)
	<expand_symtabs_matching>: Return bool.
	* objfiles.h (struct objfile) <expand_symtabs_matching>: Return
	bool.
	* dwarf2/read.c (struct dwarf2_gdb_index)
	<expand_symtabs_matching>: Return bool.
	(struct dwarf2_debug_names_index) <expand_symtabs_matching>:
	Return bool.
	(dw2_expand_symtabs_matching_symbol): Return bool.
	(dw2_expand_symtabs_matching_one, dw2_expand_marked_cus)
	(dw2_expand_symtabs_matching)
	(dwarf2_gdb_index::expand_symtabs_matching)
	(dwarf2_debug_names_index::expand_symtabs_matching)
	(dwarf2_debug_names_index::expand_symtabs_matching): Return bool.
2021-04-17 09:35:05 -06:00
Tom Tromey
e357e9904c Add block_search_flags
This adds block_search_flags, a flag enum.  This will be used to by
certain search functions so that the caller can control which blocks
are searched more precisely.

gdb/ChangeLog
2021-04-17  Tom Tromey  <tom@tromey.com>

	* quick-symbol.h (enum block_search_flag_values): New.
	(block_search_flags): New enum flags type.
2021-04-17 09:35:04 -06:00
Tom Tromey
3cbc7ac344 Rewrite the Rust expression parser
The Rust expression parser was written to construct its own AST, then
lower this to GDB expressions.  I did this primarily because the old
expressions were difficult to work with; after rewriting those, I
realized I could remove the AST from the Rust parser.

After looking at this, I realized it might be simpler to rewrite the
parser.  This patch reimplements it as a recursive-descent parser.  I
kept a fair amount of the existing code -- the lexer is pulled in
nearly unchanged.

There are several benefits to this approach:

* The parser is shorter now (from 2882 LOC to 2351).
* The parser is just ordinary C++ code that can be debugged in the
  usual way.
* Memory management in the parser is now straightforward, as
  parsing methods simply return a unique pointer or vector.

This required a couple of minor changes to the test suite, as some
errors have changed.

While this passes the tests, it's possible there are lurking bugs,
particularly around error handling.

gdb/ChangeLog
2021-04-16  Tom Tromey  <tom@tromey.com>

	* rust-parse.c: New file.
	* rust-exp.y: Remove.
	* Makefile.in (COMMON_SFILES): Add rust-parse.c.
	(SFILES): Remove rust-exp.y.
	(YYFILES, local-maintainer-clean): Remove rust-exp.c.

gdb/testsuite/ChangeLog
2021-04-16  Tom Tromey  <tom@tromey.com>

	* gdb.rust/simple.exp: Change error text.
	* gdb.rust/expr.exp: Change error text.
2021-04-16 16:34:08 -06:00
Tom Tromey
458620aabb Fix syntax error in Rust test
The Rust test case simple.exp does:

    print slice as &[i32][0]

However, this is a syntax error in Rust.  Parens are needed around the
"as".

gdb/testsuite/ChangeLog
2021-04-16  Tom Tromey  <tom@tromey.com>

	* gdb.rust/simple.exp: Add parens to 'as' test.
2021-04-16 16:34:07 -06:00
Simon Marchi
321d0cd7e7 gdb/testsuite: use -gdwarf-4 in simavr board
By default, when using the -g switch, avr-gcc generates stabs debug
information.  I think it would make more sense to test GDB against DWARF
information, because stabs is obsolete by now, and nobody work on it.
So change the simavr board to pass -gdwarf-4 as the debug flag.

The downside is that users are probably more likely to use just -g, so
we don't test GDB the same way as users are likely to use it.  But in
this case, if somebody comes and asks for help with GDB for AVR, I
suggest we encourage them to use -gdwarf-4.

I can't give stats about how that changes test results, because the
testsuite is too broken.  There is an internal error that happens quite
frequently that needs to be investigated:

    /home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.

I sent a question on the gcc mailing list, asking why stabs is the
default:

    https://gcc.gnu.org/pipermail/gcc/2021-April/235309.html

gdb/testsuite/ChangeLog:

	* boards/simavr.exp: Set debug_flags.

Change-Id: I70e471fad3a79ab1d79d13dda8436bb9eb666e0a
2021-04-16 11:02:32 -04:00
Luis Machado
1b6b755e91 Print bfloat16 DWARF types correctly
Even if the DWARF information contains a bfloat16 base type (__bf16), a
variable of such type will still be printed using the IEEE half float format,
which is wrong.

This patch teaches GDB how to pick the bfloat16 format for __bf16 types in
DWARF (based on the base type name) and uses IEEE half float for all the other
16-bit float formats.

Tested on aarch64-linux/x86_64-linux.

OK?

gdb/ChangeLog:

2021-04-16  Luis Machado  <luis.machado@linaro.org>

	* arch-utils.c (default_floatformat_for_type): Handle bfloat16.

gdb/testsuite:

2021-04-16  Luis Machado  <luis.machado@linaro.org>

	* gdb.dwarf2/dw2-bfloat16.exp: New file.
2021-04-16 11:14:16 -03:00
John Baldwin
c45ecc9d16 gdb fbsd-nat: Use new-style debug macros
gdb/ChangeLog:

	* fbsd-nat.c (fbsd_lwp_debug_printf, fbsd_nat_debug_printf): New,
	use throughout file.
2021-04-15 15:40:12 -07:00
Andrew Burgess
fd5c30cde5 gdb/testsuite: don't include paths in test names
Give a test a proper name in order to avoid including a path in the
test name.

gdb/testsuite/ChangeLog:

	* gdb.python/py-parameter.exp: Give a test a proper name to avoid
	including a path in the test name.
2021-04-15 21:33:58 +01:00
Simon Marchi
41f14dc862 gdb/testsuite: use foreach_with_prefix in gdb.threads/fork-plus-threads.exp
I noticed that using foreach_with_prefix could make things a bit
less verbose.  No changes in behavior expected.

gdb/testsuite/ChangeLog:

	* gdb.threads/fork-plus-threads.exp: Use foreach_with_prefix.

Change-Id: I06aa6e3d10a9cfb6ada11547aefe8c70b636ac81
2021-04-15 14:45:47 -04:00
Tom Tromey
a15a276b46 Avoid crash in Ada value printing with optimized-out array
The Ada value-printing code could crash when printing an array which
had been optimized out.

The crash is difficult to reproduce, but I did manage to write a test
that at least shows that the previous behavior was incorrect -- before
the patch, the array is printed as if it is valid and every value is 0.

gdb/ChangeLog
2021-04-15  Tom Tromey  <tromey@adacore.com>

	* ada-valprint.c (ada_value_print_array): Handle optimized-out
	arrays.

gdb/testsuite/ChangeLog
2021-04-15  Tom Tromey  <tromey@adacore.com>

	* gdb.dwarf2/arr-stride.exp: Add test.
2021-04-15 10:14:11 -06:00
Tom Tromey
644a2e75ac Use common_val_print_checked in print_variable_and_value
GDB was crashing in "bt full" for a large Ada program.  I tracked this
down to a combination of bugs.

The first bug, fixed here, is that print_variable_and_value calls
common_val_print.  Normally only the value-printing implementation
should call this; from the top level, common_val_print_checked is
preferred, because it correctly handles values that are wholly
optimized out.

I wasn't able to write a test case for this.

gdb/ChangeLog
2021-04-15  Tom Tromey  <tromey@adacore.com>

	* printcmd.c (print_variable_and_value): Use
	common_val_print_checked.
2021-04-15 10:14:11 -06:00
Tom Tromey
9e5e03df52 Use block_symbol in var_value_operation
I noticed that var_value_operation takes a block and a symbol, and
most callers destructure a block_symbol to pass in.  It seems better
for this class to simply hold a block_symbol instead.

Tested on x86-64 Fedora 32.

gdb/ChangeLog
2021-04-15  Tom Tromey  <tromey@adacore.com>

	* rust-exp.y (rust_parser::convert_ast_to_expression): Update.
	* parse.c (parser_state::push_symbol, parser_state::push_dollar):
	Update.
	* p-exp.y (variable): Update.
	* m2-exp.y (variable): Update.
	* go-exp.y (variable): Update.
	* expprint.c (dump_for_expression): New overload.
	* expop.h (check_objfile): New overload.
	(check_constant): New overload.
	(class var_value_operation): Use block_symbol.
	<get_symbol>: Rewrite.
	* eval.c (var_value_operation::evaluate)
	(var_value_operation::evaluate_funcall)
	(var_value_operation::evaluate_for_address)
	(var_value_operation::evaluate_for_address)
	(var_value_operation::evaluate_with_coercion)
	(var_value_operation::evaluate_for_sizeof)
	(var_value_operation::evaluate_for_cast): Update.
	* d-exp.y (PrimaryExpression): Update.
	* c-exp.y (variable): Update.
	* ax-gdb.c (var_value_operation::do_generate_ax): Update.
	* ada-lang.c (ada_var_value_operation::evaluate_for_cast)
	(ada_var_value_operation::evaluate)
	(ada_var_value_operation::resolve)
	(ada_funcall_operation::resolve): Update.
	* ada-exp.y (write_var_from_sym, write_object_renaming)
	(write_ambiguous_var, write_var_or_type, write_name_assoc)
	(maybe_overload): Update.
	* ada-exp.h (class ada_var_value_operation) <get_block>: Rewrite.
2021-04-15 10:05:00 -06:00
Tom Tromey
5809fbf2e2 gdb: add "set startup-quietly" command
This adds a new command to change GDB to behave as though "-quiet"
were always given.  This new command can be added to the gdbearlyinit
file to affect future GDB sessions.

gdb/ChangeLog:

	* NEWS: Add entry.
	* main.c (captured_main_1): Call check_quiet_mode.
	* top.c (startup_quiet): New global.
	(check_quiet_mode): New function.
	(show_startup_quiet): New function.
	(init_main): Register new command.
	* top.h (check_quiet_mode): Declare.

gdb/doc/ChangeLog:

	* gdb.texinfo (Mode Options): Mention "set startup-quietly".

gdb/testsuite/ChangeLog:

	* gdb.base/startup-file.exp: Add more tests.
2021-04-15 10:34:09 +01:00
Andrew Burgess
92e4e97a9f gdb: process early initialization files and command line options
Adds the ability to process commands at a new phase during GDB's
startup.  This phase is earlier than the current initialisation file
processing, before GDB has produced any output.

The number of commands that can be processed at this early stage will
be limited, and it is expected that the only commands that would be
processed at this stage will relate to some of the fundamentals of how
GDB starts up.

Currently the only commands that it makes sense to add to this early
initialization file are those like 'set style version ....' as the
version string is displayed during startup before the standard
initialization files are parsed.  As such this commit fully resolved
bug cli/25956.

This commit adds a mechanism to execute these early initialization
files from a users HOME directory, as well as some corresponding
command line flags for GDB.

The early initialization files that GDB will currently check for are
~/.config/gdb/gdbearlyinit (on Linux like systems) or ~/.gdbearlyinit
if the former is not found.

The output of 'gdb --help' has been extended to include a list of the
early initialization files being processed.

gdb/ChangeLog:

	PR cli/25956
	* NEWS: Mention new early init files and command line options.
	* config.in: Regenerate.
	* configure: Regenerate.
	* configure.ac: Define GDBEARLYINIT.
	* main.c (get_earlyinit_files): New function.
	(enum cmdarg_kind): Add CMDARG_EARLYINIT_FILE and
	CMDARG_EARLYINIT_COMMAND.
	(captured_main_1): Add support for new command line flags, and for
	processing startup files.
	(print_gdb_help): Include startup files in the output.

gdb/doc/ChangeLog:

	PR cli/25956
	* gdb.texinfo (File Options): Mention new command line options.
	(Startup): Discuss when early init files are processed.
	(Initialization Files): Add description of early init files.
	(Output Styling): Update description of 'version' style.
	(gdb man): Mention early init files.

gdb/testsuite/ChangeLog:

	PR cli/25956
	* gdb.base/early-init-file.c: New file.
	* gdb.base/early-init-file.exp: New file.
	* lib/gdb-utils.exp (style): Handle style 'none'.
2021-04-15 10:34:09 +01:00
Andrew Burgess
54b4dcc530 gdb: refactor the initialization file lookup code
In preparation for the next patch, which adds startup files, this
commit refactors the code for looking up the initialization files so
that the code can be more easily reused in the next commit.

There should be no user visible changes after this commit.

gdb/ChangeLog:

	* main.c (relocate_gdbinit_path_maybe_in_datadir): Rename to...
	(relocate_file_path_maybe_in_datadir): ...this.
	(class gdb_initfile_finder): New class.
	(get_init_files): Now uses gdb_initfile_finder.
	(print_gdb_help): Print 'None found' when there are no init files.
2021-04-15 10:34:09 +01:00
Tankut Baris Aktemur
fcc99c428a testsuite, dwarf2: use @DW_INL_declared_inlined in a test
gdb/testsuite/ChangeLog:
2021-04-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.dwarf2/dw2-inline-with-lexical-scope.exp: Use
	@DW_INL_declared_inlined for the inline attribute.
2021-04-14 19:10:02 +02:00
Tankut Baris Aktemur
34dc0f9596 gdb/dwarf2: fix "info locals" for clang-compiled inlined functions
GDB reports duplicate local vars with "<optimized out>" values for
inlined functions that are compiled with Clang.

Suppose we have

  __attribute__((always_inline))
  static void aFunction() {
    int a = 42;
    if(a > 2) {
      int value = a;
      value += 10; /* break here */
    }
  }

The "info locals" command at the "break here" line gives the following
output:

  ...
  Breakpoint 1, aFunction () at test.c:6
  6           value += 10; /* break here */
  (gdb) info locals
  value = 42
  a = 42
  value = <optimized out>
  (gdb)

The reason is, inlined functions that are compiled by Clang do not
contain DW_AT_abstract_origin attributes in the DW_TAG_lexical_block
entries.  See

  https://bugs.llvm.org/show_bug.cgi?id=49953

E.g. the DIE of the inlined function above is

0x00000087:     DW_TAG_inlined_subroutine
                  DW_AT_abstract_origin (0x0000002a "aFunction")
                  DW_AT_low_pc  (0x00000000004004b2)
                  DW_AT_high_pc (0x00000000004004d2)
                  DW_AT_call_file       ("/tmp/test.c")
                  DW_AT_call_line       (11)
                  DW_AT_call_column     (0x03)

0x0000009b:       DW_TAG_variable
                    DW_AT_location      (DW_OP_fbreg -4)
                    DW_AT_abstract_origin       (0x00000032 "a")

0x000000a3:       DW_TAG_lexical_block
                    DW_AT_low_pc        (0x00000000004004c3)
                    DW_AT_high_pc       (0x00000000004004d2)

0x000000b0:         DW_TAG_variable
                      DW_AT_location    (DW_OP_fbreg -8)
                      DW_AT_abstract_origin     (0x0000003e "value")

This causes GDB to fail matching the concrete lexical scope with the
corresponding abstract entry.  Hence, the local vars of the abstract
function that are contained in the lexical scope are read separately
(and thus, in addition to) the local vars of the concrete scope.
Because the abstract definitions of the vars do not contain location
information, we see the extra 'value = <optimized out>' above.

This bug is highly related to PR gdb/25695, but the root cause is not
exactly the same.  In PR gdb/25695, GCC emits an extra
DW_TAG_lexical_block without an DW_AT_abstract_origin that wraps the
body of the inlined function.  That is, the trees of the abstract DIE
for the function and its concrete instance are structurally not the
same.  In the case of using Clang, the trees have the same structure.

To tackle the Clang case, when traversing the children of the concrete
instance root, keep a reference to the child of the abstract DIE that
corresponds to the concrete child, so that we can match the two DIEs
heuristically in case of missing DW_AT_abstract_origin attributes.

The updated gdb.opt/inline-locals.exp test has been checked with GCC
5-10 and Clang 5-11.

gdb/ChangeLog:
2021-04-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* dwarf2/read.c (inherit_abstract_dies): Keep a reference to the
	corresponding child of the abstract DIE when iterating the
	children of the concrete DIE.

gdb/testsuite/ChangeLog:
2021-04-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* gdb.opt/inline-locals.c (scoped): New function.
	(main): Call 'scoped'.
	* gdb.opt/inline-locals.exp: Update with "info locals" tests
	for scoped variables.
	* gdb.dwarf2/dw2-inline-with-lexical-scope.c: New file.
	* gdb.dwarf2/dw2-inline-with-lexical-scope.exp: New file.
2021-04-14 18:55:36 +02:00
Andrew Burgess
b9de3b915c gdb/doc: add missing parentheses around prompt in some examples
While reading the manual for -info-os I noticed that the GDB prompt is
given as 'gdb' when it should really be '(gdb)'.  This is because the
prompt is created with: '@value{GDBP}'.

The GDBP variable (the GDB program name) is intended for use as the
prompt string (though this is not used consistently throughout the
manual), however it is normally used like '(@value{GDBP})', but in a
couple of places the enclosing parentheses are missing.

In this commit I do the following:

 - Change '@value{GDBP}' to '(@value{GDBP})' wherever the variable
   represents a prompt string.

 - Replaces '(gdb)' with '(@value{GDBP})' in one example where we are
   already using '(@value{GDBP})', this makes that one example
   consistent.

I have NOT:

 - Changed all instances of '(gdb)' with '(@value{GDBP})', this would
   be a huge change.

gdb/doc/ChangeLog:

	* gdb.texinfo (GDB/MI Miscellaneous Commands): Add missing
	parentheses to GDB prompt in example, and replace '(gdb)' with
	'(@value{GDBP})' in one example where the latter was already in
	use.
2021-04-14 16:48:08 +01:00
Tankut Baris Aktemur
ac4d323ea0 testsuite, gdb: recognize DW_OP_fbreg in lib/dwarf.exp
gdb/testsuite/ChangeLog:
2021-04-14  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

	* lib/dwarf.exp (_location): Recognize DW_OP_fbreg as an op.
2021-04-14 12:49:22 +02:00
Tom de Vries
329534fda7 [gdb] Fix regoff_t incompatibility
I did an experiment with importing the regex module in gnulib, and trying to
build gdb.

The first problem I ran into was that:
- regoff_t was defined as long int, and
- the address of a regoff_t variable i in ui_file_style::parse was passed
  as int * to function extended_color.

Fix this by changing the types of some function parameters of functions
read_semi_number and extended_color from int * to regoff_t *.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-04-13  Tom de Vries  <tdevries@suse.de>

	* ui-style.c (read_semi_number, extended_color): Change idx parameter
	type to regoff_t *.
2021-04-13 17:38:53 +02:00
Luis Machado
d9d2ef05f1 Fix build failure for 32-bit targets with --enable-targets=all
Replace use of %lx with %s.

gdb/ChangeLog:

2021-04-13  Luis Machado  <luis.machado@linaro.org>

	* rs6000-tdep.c (ppc_displaced_step_fixup): Use %s to print
	hex values.
2021-04-13 10:49:57 -03:00
Will Schmidt
6b142048ad [PATCH,rs6000] Fix vsx-regs.exp testcase failure
Hi,
  This test exercise updates to the F* and VS* registers
and verifies updates to the same.  Note that the registers
overlap; the doubleword[1] portion of any VS0-VS31
register contains the F0-F31 register contents, so any updates
to one can be measured in the other.

Per a brief investigation, we see that dl_main() currently
uses some VSX instructions, so the VS* values are not
going to be zero when this testcase reaches main, where these
tests begin.  The test harness does not explicitly
initialize the full VS* values, so the first test loop
that updates the F* values means our VS* values are
uninitalized and will fail the first set of checks.
This update explicitly initializes the doubleword[0] portion
of the VS* registers, to allow this test to succeed.

2021-04-12  Will Schmidt  <will_schmidt@vnet.ibm.com>

gdb/testsuite/ChangeLog:
        * gdb.arch/vsx-regs.exp: Initialize vs* doublewords.
2021-04-12 14:17:43 -05:00
Will Schmidt
c8a379440e [PATCH] gdb-power10-single-step
Hi,
  This is based on a patch originally written by Alan Modra.
Powerpc / Power10 ISA 3.1 adds prefixed instructions, which
are 8 bytes in length.  This is in contrast to powerpc previously
always having 4 byte instruction length.  This patch implements
changes to allow GDB to better detect prefixed instructions, and
handle single stepping across the 8 byte instructions.

Added #defines to help test for PNOP and prefix instructions.
Update ppc_displaced_step_copy_insn() to handle pnop and prefixed
instructions whem R=0 (non-pc-relative).

Updated ppc_displaced_step_fixup() to properly handle the offset
value matching the current instruction size

Updated the for-loop within ppc_deal_with_atomic_sequence() to
count instructions properly in case we have a mix of 4-byte and
8-byte instructions within the atomic_sequence_length.

Added testcase and harness to exercise pc-relative load/store
instructions with R=0.

2021-04-12  Will Schmidt  <will_schmidt@vnet.ibm.com>

        gdb/ChangeLog:
        * rs6000-tdep.c:  Add support for single-stepping of
        prefixed instructions.

        gdb/testsuite/ChangeLog:
        * gdb.arch/powerpc-plxv-nonrel.s:  Testcase using
        non-relative plxv instructions.
        * gdb.arch/powerpc-plxv-nonrel.exp: Testcase harness.
2021-04-12 14:11:02 -05:00
Will Schmidt
e3d528d7e6 [PATCH, rs6000, v3][PR gdb/27525] displaced stepping across addpcis/lnia.
This addresses PR gdb/27525.     The lnia and other variations
of the addpcis instruction write the value of the NIA into a target register.
If we are single-stepping across a breakpoint, the instruction is executed
from a displaced location, and thusly the written value of the PC/NIA
will be incorrect.   The changes here will measure the displacement
offset, and adjust the target register value to compensate.

YYYY-MM-DD  Will Schmidt  <will_schmidt@vnet.ibm.com>

gdb/ChangeLog:

        * rs6000-tdep.c (ppc_displaced_step_fixup): Update to handle
        the addpcis/lnia instruction.

gdb/testsuite/ChangeLog:

        * gdb.arch/powerpc-addpcis.exp: Testcase harness to
        exercise single-stepping over subpcis,lnia,addpcis instructions
        with displacement.
        * gdb.arch/powerpc-addpcis.s: Testcase with stream
        of addpcis/lnia/subpcis instructions.
        * gdb.arch/powerpc-lnia.exp: Testcase harness to exercise
        single-stepping over lnia instructions with displacement.
        * gdb.arch/powerpc-lnia.s: Testcase with stream of
        lnia instructions.
2021-04-12 13:35:54 -05:00
Will Schmidt
82d9b28047 [rs6000] Create a powerpc-power10.exp test
Inspired by the existing powerpc-power9.exp test, this is a
new test to cover the power10 instruction disassembly.

gdb/testsuite/ChangeLog:
2021-04-12  Will Schmidt  <will_schmidt@vnet.ibm.com>

	* gdb.arch/powerpc-power10.s: New test for instructions.
	* gdb.arch/powerpc-power10.exp: Harness to run the test.
2021-04-12 13:17:56 -05:00
Will Schmidt
b722acca42 Add myself to gdb/MAINTAINERS
gdb/ChangeLog:

        * MAINTAINERS (Write After Approval): Add myself.
2021-04-12 12:17:52 -05:00
Carl Love
6ba4cb845b RS6000 Add support to print vector register contents as float128
This patch adds a floating point 128-bit composite field to the vsx
register type.  When printing the register with p/f the float128 field will
be printed as a 128-bit floating point value.  A test case to verify the new
vsx register field is visible and correctly prints out the value of a 128-bit
floating point value is also added.

gdb/ChangeLog:

	* rs6000-tdep.c (rs6000_builtin_type_vec128): Add t_float128 variable.
	(rs6000_builtin_type_vec128): Add append_composite_type_field for
	float128.

gdb/testsuite/ChangeLog:

	* gdb.arch/vsx-vsr-float128.c: New test file.
	* gdb.arch/vsx-vsr-float128.exp: New expect file.
2021-04-12 10:36:10 -05:00
Simon Marchi
d471748373 gdb, gdbserver: remove WinCE support code
The support for WinCE was removed with commit 84b300de36 ("gdbserver:
remove support for ARM/WinCE").  There is some leftover code for WinCE
support, guarded by the _WIN32_WCE macro, which I didn't know of at the
time.

I didn't remove the _WIN32_WCE references in the tests, because in
theory we still support the WinCE architecture in GDB (when debugging
remotely).  So someone could run a test with that (although I'd be
really surprised).

gdb/ChangeLog:

	* nat/windows-nat.c: Remove all code guarded by _WIN32_WCE.
	* nat/windows-nat.h: Likewise.

gdbserver/ChangeLog:

	* win32-low.cc: Remove all code guarded by _WIN32_WCE.
	* win32-low.h: Likewise.

Change-Id: I7a871b897e2135dc195b10690bff2a01d9fac05a
2021-04-12 11:10:57 -04:00
Markus Metzger
9d8f30221b gdb, testsuite, btrace: relax unneeded stepi expected output
In gdb.btrace/reconnect.exp, we test that we can disconnect and reconnect
again to a GDB session that is recording with the btrace recording format.
It does not really matter what we are recording.

The test assumed that stepping from _start will bring us into an area
without debug information.  This is not correct on all systems.

Relax the expected output to also support systems where we do have debug
information for that code.
2021-04-12 14:46:16 +02:00
Eli Zaretskii
b3885679dd Fix handling DLL loads at run time
This patch makes handling a DLL load at run time (using LoadLibrary)
much more reliable when its file name cannot be obtained using the
lpImageName pointer provided by the DLL load debug event.  The
solution is to enumerate all the DLLs loaded by the inferior, looking
for the DLL that's loaded at base address provided by the lpBaseOfDll
pointer of the debug event.  Correctly resolving the DLL file name is
important, because without that GDB doesn't record the DLL in the list
of solibs, and then later is unable to show functions in that DLL in
the backtraces, which produces corrupted and truncated backtraces.
See this thread for the problems that causes:

  https://sourceware.org/pipermail/gdb-patches/2021-March/177022.html

gdb/ChangeLog:

2021-04-10  Eli Zaretskii  <eliz@gnu.org>

	* windows-nat.c (windows_nat::handle_load_dll): Call
	windows_add_dll if get_image_name failed to glean the name of the
	DLL by using the lpImageName pointer.
	(windows_add_all_dlls): Now a thin wrapper around windows_add_dll.
	(windows_add_dll): Now does what windows_add_all_dlls did before,
	but also accepts an argument LOAD_ADDR, which, if non-NULL,
	specifies the address where the DLL was loaded into the inferior,
	and looks for the single DLL loaded at that address.
2021-04-10 11:42:54 +03:00
Luis Machado
1ef6a59696 [AArch64] Fix include order for MTE
Similarly to commit 665af52ec2, fix a build
failure seen with an updated glibc, due to the enum/constant mismatch.

The old include file order eventually makes asm/ptrace.h get included before
sys/ptrace.h.

This patch fixes it. Seems fairly obvious and I'll push it shortly.

gdb/ChangeLog:

2021-04-09  Luis Machado  <luis.machado@linaro.org>

	* nat/aarch64-mte-linux-ptrace.c: Update include file order.
2021-04-09 11:36:55 -03:00
Dominique Quatravaux
83a559f7b9 Remove unused variable un darwin_nat_target::resume
gdb/ChangeLog:

	* darwin-nat.c (darwin_nat_target::resume): Remove status
	variable.

Change-Id: Ibcbdd6641a12252840c7dea9f388f4f8ce265e3d
2021-04-08 15:22:49 -04:00
Felix Willgerodt
16e311ab6d gdb: Allow prologue detection via symbols for Intel compilers.
The next-gen Intel Fortran compiler isn't flang-based, but emits
prologue_end in the same manner.  As do the newer Intel C/C++ compilers.
This allows prologue detection based on dwarf for all newer Intel compilers.
The cut-off version was not chosen for any specific reason other than the
effort to test this.

gdb/Changelog:
2021-04-08  Felix Willgerodt  <felix.willgerodt@intel.com>

    	* i386-tdep.c (i386_skip_prologue): Use symbol table to find the
    	prologue end for Intel compilers.
    	* amd64-tdep.c (amd64_skip_prologue): Likewise.
    	* producer.c (producer_is_icc_ge_19): New function.
    	* producer.h (producer_is_icc_ge_19): New declaration.
2021-04-08 09:19:57 +02:00