Simon Marchi [Sun, 2 May 2021 15:04:58 +0000 (11:04 -0400)]
sim: add default cases to two switches in sim-options.c
This is the next compilation error I hit when I build all targets with
Clang:
/home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:234:12: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ENVIRONMENT)
^~~~~~~~~~~~~~~~ ./config.h:215:26: note: expanded from macro 'WITH_ENVIRONMENT'
#define WITH_ENVIRONMENT ALL_ENVIRONMENT ^~~~~~~~~~~~~~~
/home/simark/src/binutils-gdb/sim/aarch64/../common/sim-options.c:276:15: error: no case matching constant switch condition '0' [-Werror] switch (WITH_ALIGNMENT)
^~~~~~~~~~~~~~ /home/simark/src/binutils-gdb/sim/aarch64/../common/sim-config.h:220:24: note: expanded from macro 'WITH_ALIGNMENT'
#define WITH_ALIGNMENT 0
^
This is a little bit special because these are switches on compile-time
value. But regardless, the idea is that we logically can't reach the
switches if WITH_ENVIRONMENT == 0 or WITH_ALIGNMENT == 0, so the code is
correct.
In addition to getting rid of the compiler warning, adding default cases
to these switches ensure that if we do get in an unexpected situation,
it is caught. In GDB, I'd use gdb_assert_not_reached, I don't know if
there is something similar in sim so I went with abort.
sim/common/ChangeLog:
* sim-options.c (standard_option_handler): Add default cases to
switches.
Mike Frysinger [Sun, 2 May 2021 04:07:21 +0000 (00:07 -0400)]
sim: replace custom attributes with ansidecl.h
A lot of this code predates the common attributes. We had already
started migrating over piece by piece, so just do a pass across all
the attributes and replace most of them.
Mike Frysinger [Sat, 2 Jan 2016 15:54:42 +0000 (10:54 -0500)]
sim: bfin: move option inits to respective modules
Now that modules can self declare their own init funcs, change the mmu
and mach logic to use it. We don't need to export the option symbols
or specifically call this logic from the sim_open function anymore.
Mike Frysinger [Sun, 2 May 2021 03:04:01 +0000 (23:04 -0400)]
sim: options: fix --help output
The hash table rewrite broke --help output due to subtle behavior:
calling dup_arg_p(NULL) will create & clear the table, not just
create it. The --help output relies on this to clear the table
before it shows things.
Mike Frysinger [Sat, 2 Jan 2016 15:50:46 +0000 (10:50 -0500)]
sim: add framework for declaring init callbacks locally
To facilitate decentralized module initialization/registration with an
eye towards multi-target support, add a framework to detect init calls
declared in the source and automatically call them. This is akin to
gdb's _initialize_xxx framework for letting modules autodiscover.
Mike Frysinger [Sat, 1 May 2021 20:30:59 +0000 (16:30 -0400)]
sim: nrun: add local strsignal prototype
While libiberty provides a definition for this for systems that lack
the function (e.g. Windows), it doesn't provide a prototype. So add
our own local copy in the one file that uses the func.
Mike Frysinger [Sat, 24 Apr 2021 18:28:17 +0000 (14:28 -0400)]
sim: callback: inline wrap helper
This is annoying as it requires inlining boiler plate, but we don't
have much choice: the wrap helper assumes the return value is always
an int, but that's already not the case with some of the callbacks
which use long. GCC has extensions to define macros-as-functions,
but we can't assume GCC.
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Do not separately read type units
Currently, the DWARF reader has a separate pass to read type units --
create_all_type_units. While working on other patches, I discovered
that this caused DWARF 5 type units to be read twice, once by
create_all_comp_units and once by create_all_type_units.
There's no need any more (if there ever was) to treat type units
differently from CUs. So, this patch removes create_all_type_units
and unifies the code paths.
Note that the DWO code still has a second pass. I haven't looked into
this code yet; perhaps it can also be simplified.
Regression tested using the debug-types board file on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Remove dwarf2_per_bfd::all_type_units
I don't think there is any deep reason to separate CUs and TUs in
dwarf2_per_bfd. This patch removes all_type_units and unifies these
two containers. Some minor tweaks are needed to the index writers,
because both forms of index keep CUs and TUs separate;
Regression tested on x86-63 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 20:07:58 +0000 (14:07 -0600)]
Allocate dwarf2_per_cu_data with 'new'
In a patch series I am working on, I'd like to have a non-POD member
in dwarf2_per_cu_data. This currently can't be done because
dwarf2_per_cu_data is allocated on an obstack and initialized with
memset.
This patch changes the DWARF reader to allocate objects of this type
with 'new'. The various "subclasses" of this type (signatured_type in
particular) are now changed to derive from dwarf2_per_cu_data, and
also use 'new' for allocation.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-04-30 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
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>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
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>
Tom Tromey [Fri, 30 Apr 2021 16:22:23 +0000 (10:22 -0600)]
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>
Tom Tromey [Fri, 30 Apr 2021 16:04:56 +0000 (10:04 -0600)]
Use rvalue reference in thread_pool::post_task
Tankut's recent patches made me realize that thread_pool::post_task
should have used an rvalue reference for its parameter. This patch
makes this change.
gdbsupport/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* thread-pool.cc (thread_pool::post_task): Update.
* thread-pool.h (class thread_pool) <post_task>: Take rvalue
reference to function.
Tom Tromey [Thu, 15 Apr 2021 14:54:06 +0000 (08:54 -0600)]
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.
Tom de Vries [Fri, 30 Apr 2021 09:25:47 +0000 (11:25 +0200)]
[gdb/testsuite] Fix duplicate test name in gdb.mi/mi-sym-info.exp
Since commit 2d61316c32a "[gdb/testsuite] Fix buffer full errors in
gdb.mi/mi-sym-info.exp", we have a duplicate test name:
...
Running src/gdb/testsuite/gdb.mi/mi-sym-info.exp ...
DUPLICATE: gdb.mi/mi-sym-info.exp: List all variables
...
This is caused by a copy-paste accident: the idea was to copy the test, edit
it, and then remove the old test, but I forgot to remove the old one.
Remove it now.
Tom de Vries [Thu, 29 Apr 2021 21:32:20 +0000 (23:32 +0200)]
[gdb/testsuite] Fix timeout in gdb.base/valgrind-infcall-2.exp
Since commit 6d5702a5eb3 "Fix test case gdb.base/valgrind-bt.exp" I run into:
...
FAIL: gdb.base/valgrind-infcall-2.exp: target remote for vgdb (timeout)
FAIL: gdb.base/valgrind-infcall-2.exp: monitor v.set gdb_output (timeout)
...
The commit adds this line in proc vgdb_start:
...
set vgdbcmd "set remotetimeout 3"
...
which has no effect given that the value of var vgdbcmd is not used before
it's overwritten. We can fix this by doing instead:
...
set_remotetimeout 3
...
The FAIL I'm observing is fixed by increasing the remotetimeout value to 4.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-29 Tom de Vries <tdevries@suse.de>
PR testsuite/27786
* lib/valgrind.exp (vgdb_start): Use set_remotetimeout. Increase
remotetimeout to 4.
Simon Marchi [Thu, 29 Apr 2021 20:24:19 +0000 (16:24 -0400)]
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.
Nick Clifton [Thu, 29 Apr 2021 16:55:43 +0000 (17:55 +0100)]
Fix an access through a null pointer when parsing a corrupt SOM format fle.
PR 27793
* som.c (som_slurp_symbol_table): Assign symbols without any scope
to the undefined section.
(som_decode_symclass): Check for a missing symbol section.
* syms.c (bfd_decode_symclass): Likewise.
Nick Clifton [Thu, 29 Apr 2021 16:41:43 +0000 (17:41 +0100)]
Fix illegal memory accesses when parsing a corrupt SOM format file.
PR 27792
* som.c (som_slurp_string_table): Place a terminating NUL byte at
the end of the table.
(som_slurp_symbol_table): Check for an over-large offset into the
string string table.
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.
Jan Beulich [Thu, 29 Apr 2021 09:45:10 +0000 (11:45 +0200)]
x86: relax when/how @size can be used
Allow a few more expression forms when the entire expression can be
resolved at assembly time. For this, i386_validate_fix() needs to
arrange for all processing of the relocation to be deferred to
tc_gen_reloc().
Jan Beulich [Thu, 29 Apr 2021 09:43:53 +0000 (11:43 +0200)]
x86: allow @size to also (sensibly) apply to sections
So far this (counter-intuitively) produced the size as recorded in the
(section) symbol. Obtain the section's size instead for section symbols.
(I wonder whether STT_SECTION symbols couldn't properly hold the
section's size in their st_size field, which in turn would likely mean
the internal symbol would also have its size properly updated.)
Note that this is not the same as the .sizeof.() pseudo-operator: @size
yields the local file's contribution to a section, while .sizeof.() gets
resolved by the linker to produce the final full section's size.
As to the 3rd each of the expected output lines in the changed testcase:
I can't find justification for zzz to come after yyy despite them being
defined in the opposite order in source. Therefore I think it's better
to permit both possible outcomes.
Tom Tromey [Tue, 27 Apr 2021 13:35:23 +0000 (07:35 -0600)]
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.
Nick Clifton [Wed, 28 Apr 2021 10:49:09 +0000 (11:49 +0100)]
Stop the BFD library from treating annobin symbols as potential function symbols.
bfd * elf.c (_bfd_elf_maybe_function_sym): Do not accept annobin
symbols as potential function symbols.
* elfnn-aarch64.c (elfNN_aarch64_maybe_function_sym): Likewise.
* elf64-ppc.c (ppc64_elf_maybe_function_sym): Likewise.
* elf32-arm.c (elf32_arm_maybe_function_sym): Likewise.
ld * testsuite/ld-elf/anno-sym.s: New test source file.
* testsuite/ld-elf/anno-sym.d: New test driver.
* testsuite/ld-elf/anno-sym.l: New test error output.
Andrew Burgess [Thu, 27 Aug 2020 15:53:13 +0000 (16:53 +0100)]
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.
Andrew Burgess [Thu, 22 Apr 2021 17:26:15 +0000 (18:26 +0100)]
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.
Andrew Burgess [Wed, 26 Aug 2020 16:31:12 +0000 (17:31 +0100)]
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.
Andrew Burgess [Thu, 22 Apr 2021 17:17:01 +0000 (18:17 +0100)]
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.
Andrew Burgess [Thu, 22 Apr 2021 16:11:25 +0000 (17:11 +0100)]
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.
Andrew Burgess [Thu, 22 Apr 2021 16:05:44 +0000 (17:05 +0100)]
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.
Jan Beulich [Wed, 28 Apr 2021 08:53:00 +0000 (10:53 +0200)]
x86: honor signedness of PC-relative relocations
PR gas/27763
While the comment in output_jump() was basically correct prior to the
introduction of 64-bit mode, both that and the not-JMP-like behavior of
XBEGIN require adjustments: Branches with 32-bit displacement do not
wrap at 4G in 64-bit mode, and XBEGIN with 16-bit operand size doesn't
wrap at 64k. Similarly %rip-relative addressing doesn't wrap at 4G.
The new testcase points out that for PE/COFF object_64bit didn't get
set so far, preventing in particular the check at the end of
md_convert_frag() to take effect.
For Mach-O the new testcase fails (bogusly), in that only the first two
of the expected errors get raised. Since for Mach-O many testcases
already fail, and since an x86_64-darwin target can't even be configured
for, I didn't think I need to bother.
Note that there are further issues in this area, in particular for
branches with operand size overrides. Such branches, which truncate
%rip / %eip, can't be correctly expressed with ordinary PC-relative
relocations. It's not really clear what to do with them - perhaps the
best we can do is to carry through all associated relocations, leaving
it to the linker (or even loader) to decide (once the final address
layout is known). Same perhaps goes for relocations associated with
32-bit addressing in 64-bit mode.
Luis Machado [Thu, 1 Apr 2021 20:00:43 +0000 (17:00 -0300)]
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 eaeaf44cfdc9a4096a0dd52fa0606f29d4bfd48e). With the new line breaks, we don't
need a particular pattern, so clean up that test as well.
Luis Machado [Thu, 1 Apr 2021 17:31:24 +0000 (14:31 -0300)]
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.
Michael Weghorn [Tue, 27 Apr 2021 14:02:42 +0000 (10:02 -0400)]
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.)
* 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.
Michael Weghorn [Tue, 27 Apr 2021 13:55:27 +0000 (09:55 -0400)]
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.
* 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.
H.J. Lu [Tue, 27 Apr 2021 15:16:55 +0000 (08:16 -0700)]
x86: Add () to silence GCC 5
Add () to !i.prefix[ADDR_PREFIX] to silence GCC 5:
gas/config/tc-i386.c:4152:31: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
&& !i.prefix[ADDR_PREFIX] != (flag_code == CODE_32BIT))
^
* config/tc-i386.c (optimize_encoding): Add () to silence GCC 5.
Mike Frysinger [Sun, 25 Apr 2021 22:11:35 +0000 (18:11 -0400)]
sim: nltvals: unify common syscall tables
Since libgloss provides a default syscall table for arches, use that
to provide the default syscall table for ports. Only the exceptions
need to be enumerated now with the common logic as the default.
Mike Frysinger [Fri, 23 Apr 2021 20:24:27 +0000 (16:24 -0400)]
sim: enable hardware support by default
Force this on for all ports. We have a few common models that can
be used, so make them generally available. If the port doesn't use
any hardware (the default), then behavior is unchanged.
Tom Tromey [Mon, 26 Apr 2021 15:53:32 +0000 (09:53 -0600)]
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.
Simon Marchi [Mon, 26 Apr 2021 15:27:07 +0000 (11:27 -0400)]
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.
Jan Beulich [Mon, 26 Apr 2021 08:41:35 +0000 (10:41 +0200)]
x86: correct overflow checking for 16-bit PC-relative relocs
The only insn requiring a truly 16-bit PC-relative relocation outside of
16-bit mode is XBEGIN (with an operand size override). For it, the
relocation generated should behave similar to 8- and (for 64-bit) 32-bit
PC-relatives ones, i.e. be checked for a signed value to fit the field.
This same mode is also correct for 16-bit code. Outside of 16-bit code,
branches with operand size overrides act in a truly PC-relative way only
when living in the low 32k of address space, as they truncate rIP to 16
bits. This can't be expressed by a PC-relative relocation.
Putting in place a new testcase, I'd like to note that the two existing
ones (pcrel16 and pcrel16abs) appear to be pretty pointless: They don't
expect any error despite supposedly checking for overflow, and in fact
there can't possibly be any error for the
- former since gas doesn't emit any relocation in the first place there,
- latter because the way the relocation gets expressed by gas doesn't
allow the linker to notice the overflow; it should be detected by gas
if at all, but see above (an error would be reported here for x86-64
afaict, but this test doesn't get re-used there).
Jan Beulich [Mon, 26 Apr 2021 08:37:30 +0000 (10:37 +0200)]
x86: optimize LEA
Over the years I've seen a number of instances where people used
lea (%reg1), %reg2
or
lea symbol, %reg
despite the same thing being expressable via MOV. Since additionally
LEA often has restrictions towards the ports it can be issued to, while
MOV typically gets dealt with simply by register renaming, transform to
MOV when possible (without growing opcode size and without altering
involved relocation types).
Note that for Mach-O the new 64-bit testcases would fail (for
BFD_RELOC_X86_64_32S not having a representation), and hence get skipped
there.
Jan Beulich [Mon, 26 Apr 2021 08:35:51 +0000 (10:35 +0200)]
x86-64: have value properly checked when resolving fixup
Constants not known at the time an individual insn gets assembled and
going into a sign-extended field still shouldn't be silently truncated
at the time the respective fixup gets resolved.
Lancelot SIX [Sat, 17 Apr 2021 11:10:23 +0000 (12:10 +0100)]
[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:
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.
Lancelot SIX [Sat, 17 Apr 2021 11:10:23 +0000 (12:10 +0100)]
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.
Switch observer to use the "new" debug printf mechanism and sprinkle a
few debug prints. Here's a small example of the output with "infrun"
and "observer" debug output enabled:
[infrun] proceed: enter
[observer] notify: start: observable target_resumed notify() called
[observer] notify: start: calling observer mi-interp of observable target_resumed
[observer] notify: end: calling observer mi-interp of observable target_resumed
[observer] notify: start: calling observer py-inferior of observable target_resumed
[observer] notify: end: calling observer py-inferior of observable target_resumed
[observer] notify: end: observable target_resumed notify() called
...
Simon Marchi [Sat, 24 Apr 2021 23:26:04 +0000 (19:26 -0400)]
gdbsupport: allow passing format string to scoped_debug_start_end
A little thing that bothers me with scoped_debug_start_end is that it's
not possible to pass a format string to add context to the messages: the
start and end messages are fixed.
It was done like this at the time because there's the risk that debug
output is not enabled on entry (when the constructor runs) but is
enabled on exit (when the destructor runs). For example, a user
debugging from a top-gdb may manually enable a debug_foo variable. If
debug output is disabled while the constructor runs, we won't render the
format string (to minimize overhead) so it won't be available in the
destructor.
I think it would be nice to be able to use a format string along with
scoped_debug_start_end, and I think it's unfortunate that such a narrow
use case prevents it. So with this patch, I propose that we allow
passing a format string to scoped_debug_start_end, and if the rare
situation described above happens, then we just show a "sorry, message
not available" kind of message.
The following patch makes use of this.
gdbsupport/ChangeLog:
* common-debug.h (struct scoped_debug_start_end)
<scoped_debug_start_end>: Change start_msg/end_msg for
start_prefix/end_prefix. Add format string parameter and make
variadic.
<~scoped_debug_start_end>: Adjust.
<m_end_msg>: Rename to...
<m_end_prefix>: ... this.
<m_with_format>: New.
<m_msg>: New.
(scoped_debug_start_end): Make variadic.
(scoped_debug_enter_exit): Adjust.
Simon Marchi [Sat, 24 Apr 2021 23:26:04 +0000 (19:26 -0400)]
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.
Mike Frysinger [Sat, 24 Apr 2021 04:10:44 +0000 (00:10 -0400)]
sim: options: increase max option count
As we turn on more modules by default for all ports, the number of
options has been increasing. The sim-options module has a limit on
the number of options it can support, and if it's exceeded, it likes
to go into an infinite loop. Increase the ceiling and add an assert
so we abort right away instead of hanging.
This will be needed to turn on hw support for v850 as it will then
exceed the current limit.
Mike Frysinger [Sat, 24 Apr 2021 01:58:21 +0000 (21:58 -0400)]
sim: simplify hardware m4 macro
Every port using this sets the 1st arg to yes and the 2nd arg to "".
These are the defaults we probably want anyways in order to unify the
codebase, so move them to the macro and only allow ports to declare
extra hardware models.
Simon Marchi [Fri, 23 Apr 2021 18:03:30 +0000 (14:03 -0400)]
gdbsupport: include preprocessor.h in common-debug.h
While doing some changes, some code failed to compile because it used
the scoped_debug_start_end macro, but couldn't find the CONCAT macro.
Fix that by making common-debug.h include preprocessor.h, the header
file that provides CONCAT.
projects / thirdparty / binutils-gdb.git / log
