ar_base is uninitialized for cores w/o windowed registers as their
regmap doesn't have register 0x0100.
Check that ar_base is initialized and if not initialize it with a0_base.
gdb/
* xtensa-tdep.c (xtensa_derive_tdep): Make sure ar_base is
initialized.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Improve gnulib in gdb's guess work, gettimeofday() works in uClibcm promise.
This patch helps building x86_64-unknown-linux-uclibc toolchains, the final
gdb-native step otherwise fails when linking the libinproctrace.so
Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
Originally reported in
https://bugzilla.redhat.com/show_bug.cgi?id=1577396 -- gdb build fails
with Python 3.7 due to references to a Python internal function whose
declaration changed in 3.7.
gdb/ChangeLog
2018-06-09 Paul Koning <paul_koning@dell.com>
PR gdb/23252
* python/python.c (do_start_initialization):
Avoid call to internal Python API.
(init__gdb_module): New function.
This patch fixes a bug introduced by fix to AArch64 pointer tagging.
In our fix for tagged pointer support our agreed approach was to sign
extend user-space address after clearing tag bits. This is not same
for all architectures and this patch allows sign extension for
addresses on targets which specifically set significant_addr_bit.
More information about patch that caused the issues and discussion
around tagged pointer support can be found in links below:
https://sourceware.org/ml/gdb-patches/2018-05/msg00000.htmlhttps://sourceware.org/ml/gdb-patches/2017-12/msg00159.html
gdb/ChangeLog:
2018-05-31 Omair Javaid <omair.javaid@linaro.org>
PR gdb/23210
* gdbarch.sh (significant_addr_bit): Default to zero when
not set by target architecture.
* gdbarch.c: Re-generated.
* utils.c (address_significant): Update.
On Windows, starting a new process with GDBserver seems to work,
in the sense that the program does get started, and GDBserver
confirms that it is listening for GDB to connect. However, as soon as
GDB establishes the connection with GDBserver, and starts discussing
with it, GDBserver crashes, with a SEGV.
This SEGV occurs in remote-utils.c::prepare_resume_reply...
| regp = current_target_desc ()->expedite_regs;
| [...]
| while (*regp)
... because, in our case, REGP is NULL.
This patches fixes the issues by adding a parameter to init_target_desc,
in order to make sure that we always provide the list of registers when
we initialize a target description.
gdb/ChangeLog:
PR server/23158:
* regformats/regdat.sh: Adjust script, following the addition
of the new expedite_regs parameter to init_target_desc.
gdb/gdbserver/ChangeLog:
PR server/23158:
* tdesc.h (init_target_desc) <expedite_regs>: New parameter.
* tdesc.c (init_target_desc) <expedite_regs>: New parameter.
Use it to set the expedite_regs field in the given tdesc.
* x86-tdesc.h: New file.
* linux-aarch64-tdesc.c (aarch64_linux_read_description):
Adjust following the addition of the new expedite_regs parameter
to init_target_desc.
* linux-tic6x-low.c (tic6x_read_description): Likewise.
* linux-x86-tdesc.c: #include "x86-tdesc.h".
(i386_linux_read_description, amd64_linux_read_description):
Adjust following the addition of the new expedite_regs parameter
to init_target_desc.
* lynx-i386-low.c: #include "x86-tdesc.h".
(lynx_i386_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
* nto-x86-low.c: #include "x86-tdesc.h".
(nto_x86_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
* win32-i386-low.c: #include "x86-tdesc.h".
(i386_arch_setup): Adjust following the addition of the new
expedite_regs parameter to init_target_desc.
Trying to start a program with GDBserver on Windows yields
the following error:
$ gdbserver.exe --once :4444 simple_main.exe
Killing process(es): 5008
No program to debug
Exiting
The error itself comes from the following code shortly after
create_inferior gets called (in server.c::main):
/* Wait till we are at first instruction in program. */
create_inferior (program_path.get (), program_args);
[...]
if (last_status.kind == TARGET_WAITKIND_EXITED
|| last_status.kind == TARGET_WAITKIND_SIGNALLED)
was_running = 0;
else
was_running = 1;
if (!was_running && !multi_mode)
error ("No program to debug");
What happens is that the "last_status" global starts initialized
as zeroes, which means last_status.kind == TARGET_WAITKIND_EXITED,
and we expect create_inferior to be waiting for the inferior to
start until reaching the SIGTRAP, and to set the "last_status"
global to match that last event we received.
I suspect this is an unintended side-effect of the following change...
commit 2090129c36c7e582943b7d300968d19b46160d84
Date: Thu Dec 22 21:11:11 2016 -0500
Subject: Share fork_inferior et al with gdbserver
... which removes some code in server.c that was responsible for
starting the inferior in a functin that was named start_inferior,
and looked like this:
signal_pid = create_inferior (new_argv[0], &new_argv[0]);
[...]
/* Wait till we are at 1st instruction in program, return new pid
(assuming success). */
last_ptid = mywait (pid_to_ptid (signal_pid), &last_status, 0, 0);
The code has been transitioned to using fork_inferior, but sadly,
only for the targets that support it. On Windows, the calls to wait
setting "last_status" simply disappeared.
This patch adds it back in the Windows-specific implementation of
create_inferior.
gdb/gdbserver/ChangeLog:
PR server/23158:
* win32-low.c (win32_create_inferior): Add call to my_wait
setting last_status global.
Trying to start GDBserver on Windows currently yields the following
error...
$ gdbserver.exe --once :4444 simple_main.exe
glob could not process pattern '(null)'.
Exiting
... after which GDB terminates with a nonzero status.
This is because create_process in win32-low.c calls gdb_tilde_expand
with the result of a call to get_inferior_cwd without verifying that
the returned directory is not NULL:
| static BOOL
| create_process (const char *program, char *args,
| DWORD flags, PROCESS_INFORMATION *pi)
| {
| const char *inferior_cwd = get_inferior_cwd ();
| std::string expanded_infcwd = gdb_tilde_expand (inferior_cwd);
This patch avoids this by only calling gdb_tilde_expand when
INFERIOR_CWD is not NULL, which is similar to what is done on
GNU/Linux for instance.
gdb/gdbserver/ChangeLog:
PR server/23158:
* win32-low.c (create_process): Only call gdb_tilde_expand if
inferior_cwd is not NULL.
This patch fixes tagged pointer support for AArch64 GDB. Linux kernel
debugging failure was reported after tagged pointer support was committed.
After a discussion around best path forward to manage tagged pointers
on GDB side we are going to disable tagged pointers support for
aarch64-none-elf-gdb because for non-linux applications we cant be
sure if tagged pointers will be used by MMU or not.
Also for aarch64-linux-gdb we are going to sign extend user-space
address after clearing tag bits. This will help debug both kernel
and user-space addresses based on information from linux kernel
documentation given below:
According to AArch64 memory map:
https://www.kernel.org/doc/Documentation/arm64/memory.txt
"User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1."
According to AArch64 tagged pointers document:
https://www.kernel.org/doc/Documentation/arm64/tagged-pointers.txt
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
this byte for application use.
Running gdb testsuite after applying this patch introduces no regressions
and tagged pointer test cases still pass.
gdb/ChangeLog:
2018-05-10 Omair Javaid <omair.javaid@linaro.org>
PR gdb/23127
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Add call to
set_gdbarch_significant_addr_bit.
* aarch64-tdep.c (aarch64_gdbarch_init): Remove call to
set_gdbarch_significant_addr_bit.
* utils.c (address_significant): Update to sign extend addr.
commit b4987c956dfa44ca9fd8552f63e15f5fa094b2a4
Author: Sergio Durigan Junior <sergiodj@redhat.com>
Date: Fri Feb 9 18:44:59 2018 -0500
Create new common/pathstuff.[ch]
Introduced a regression when compiling for mingw*:
/gdb/common/pathstuff.c: In function 'gdb::unique_xmalloc_ptr<char>
gdb_realpath(const char*)':
/gdb/common/pathstuff.c:56:14: error: 'MAX_PATH' was not declared in this scope
char buf[MAX_PATH];
^
/gdb/common/pathstuff.c:57:5: error: 'DWORD' was not declared in this scope
DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
^
/gdb/common/pathstuff.c:57:11: error: expected ';' before 'len'
DWORD len = GetFullPathName (filename, MAX_PATH, buf, NULL);
^
/gdb/common/pathstuff.c:63:9: error: 'len' was not declared in this scope
if (len > 0 && len < MAX_PATH)
^
/gdb/common/pathstuff.c:64:54: error: 'buf' was not declared in this scope
return gdb::unique_xmalloc_ptr<char> (xstrdup (buf));
^
make[2]: *** [pathstuff.o] Error 1
The proper fix is to conditionally include "<windows.h>". This commit
does that, without introducing any regressions as per tests made by
our BuildBot.
gdb/ChangeLog:
2018-03-01 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/22907
* common/pathstuff.c: Conditionally include "<windows.h>".
I forgot to address Pedro's comment about my last patch and change the
order of the message printed when getcwd returns NULL on gdbserver.
This obvious commit does it.
gdb/gdbserver/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c (captured_main): Change order of error message printed
when the current working directory cannot be found.
Simon mentioned on IRC that, after the startup-with-shell feature has
been implemented on gdbserver, it is not possible to specify a
filename-only binary, like:
$ gdbserver :1234 a.out
/bin/bash: line 0: exec: a.out: not found
During startup program exited with code 127.
Exiting
This happens on systems where the current directory "." is not listed
in the PATH environment variable. Although including "." in the PATH
variable is a possible workaround, this can be considered a regression
because before startup-with-shell it was possible to use only the
filename (due to reason that gdbserver used "exec*" directly).
The idea of the patch is to verify if the program path provided by the
user (or by the remote protocol) contains a directory separator
character. If it doesn't, it means we're dealing with a filename-only
binary, so we call "gdb_abspath" to properly expand it and transform
it into a full path. Otherwise, we leave the program path untouched.
This mimicks the behaviour seen on GDB (look at "openp" and
"attach_inferior", for example).
I am also submitting a testcase which exercises the scenario described
above. This test requires gdbserver to be executed in a different CWD
than the original, so I also created a helper function, "with_cwd" (on
testsuite/lib/gdb.exp), which takes care of cd'ing into and out of the
specified dir.
Built and regtested on BuildBot, without regressions.
gdb/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
Simon Marchi <simon.marchi@polymtl.ca>
* common/common-utils.c: Include "sys/stat.h".
(is_regular_file): Move here from "source.c"; change return
type to "bool".
* common/common-utils.h (is_regular_file): New prototype.
* common/pathstuff.c (contains_dir_separator): New function.
* common/pathstuff.h (contains_dir_separator): New prototype.
* source.c: Don't include "sys/stat.h".
(is_regular_file): Move to "common/common-utils.c".
gdb/gdbserver/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* server.c: Include "filenames.h" and "pathstuff.h".
(program_name): Delete variable.
(program_path): New anonymous class.
(get_exec_wrapper): Use "program_path" instead of
"program_name".
(handle_v_run): Likewise.
(captured_main): Likewise.
(process_serial_event): Likewise.
gdb/testsuite/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.server/abspath.exp: New file.
* lib/gdb.exp (with_cwd): New procedure.
This commit moves the path manipulation routines found on utils.c to a
new common/pathstuff.c, and updates the Makefile.in's accordingly.
The routines moved are "gdb_realpath", "gdb_realpath_keepfile" and
"gdb_abspath".
This will be needed because gdbserver will have to call "gdb_abspath"
on my next patch, which implements a way to expand the path of the
inferior provided by the user in order to allow specifying just the
binary name when starting gdbserver, like:
$ gdbserver :1234 a.out
With the recent addition of the startup-with-shell feature on
gdbserver, this scenario doesn't work anymore if the user doesn't have
the current directory listed in the PATH variable.
I had to do a minor adjustment on "gdb_abspath" because we don't have
access to "tilde_expand" on gdbserver, so now the function is using
"gdb_tilde_expand" instead. Otherwise, the code is the same.
Regression tested on the BuildBot, without regressions.
gdb/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add "common/pathstuff.c".
(HFILES_NO_SRCDIR): Add "common/pathstuff.h".
(COMMON_OBS): Add "pathstuff.o".
* auto-load.c: Include "common/pathstuff.h".
* common/common-def.h (current_directory): Move here.
* common/gdb_tilde_expand.c (gdb_tilde_expand_up): New
function.
* common/gdb_tilde_expand.h (gdb_tilde_expand_up): New
prototype.
* common/pathstuff.c: New file.
* common/pathstuff.h: New file.
* compile/compile.c: Include "common/pathstuff.h".
* defs.h (current_directory): Move to "common/common-defs.h".
* dwarf2read.c: Include "common/pathstuff.h".
* exec.c: Likewise.
* guile/scm-safe-call.c: Likewise.
* linux-thread-db.c: Likewise.
* main.c: Likewise.
* nto-tdep.c: Likewise.
* objfiles.c: Likewise.
* source.c: Likewise.
* symtab.c: Likewise.
* utils.c: Include "common/pathstuff.h".
(gdb_realpath): Move to "common/pathstuff.c".
(gdb_realpath_keepfile): Likewise.
(gdb_abspath): Likewise.
* utils.h (gdb_realpath): Move to "common/pathstuff.h".
(gdb_realpath_keepfile): Likewise.
(gdb_abspath): Likewise.
gdb/gdbserver/ChangeLog:
2018-02-28 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add "$(srcdir)/common/pathstuff.c".
(OBJS): Add "pathstuff.o".
* server.c (current_directory): New global variable.
(captured_main): Initialize "current_directory".
When we kill an inferior, the inferior is not deleted. What is more, it
is reused when the new process is created, so we need to reset inferior's
state when it exits.
gdb:
2018-02-15 Yao Qi <yao.qi@linaro.org>
PR gdb/22849
* inferior.c (exit_inferior_1): Reset inf->control.
The error is triggered by including python-internal.h, and the
error message is:
In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0,
from build-gnulib/import/math.h:27,
from d:/usr/Python26/include/pyport.h:235,
from d:/usr/Python26/include/Python.h:58,
from python/python-internal.h:94,
from python/py-arch.c:24:
d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared
using ::hypot;
^~~~~
This happens because Python headers define 'hypot' to expand to
'_hypot' in the Windows builds.
gdb/ChangeLog:
2018-01-27 Eli Zaretskii <eliz@gnu.org>
* python/python-internal.h (_hypot) [__MINGW32__]: Define back to
'hypoth'. This avoids a compilation error.
(cherry picked from commit b2a426e2c5632644b6b8bc0dde4cd32d42d548e2)
GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):
make check RUNTESTFLAGS=prettyprinters.exp=80276.cc
in a loop. Sometimes you get this:
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
I.e., this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>
instead of this:
type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>
Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:
if self.type_obj == type_obj:
return strip_inline_namespaces(self.name)
This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.
Running the testcase manually under Valgrind finds the problem in GDB:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==6118== Conditional jump or move depends on uninitialised value(s)
==6118== at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
==6118== by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
==6118== by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
==6118== by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
==6118== by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
==6118== by 0x63D7E6C: PyObject_RichCompare (object.c:961)
==6118== by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
==6118== by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That "bcmp" call is really a memcmp call in check_types_equal. The
problem is that gdb is memcmp'ing two objects that are equal in value:
(top-gdb) p *TYPE_RANGE_DATA (type1)
$1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
(top-gdb) p *TYPE_RANGE_DATA (type2)
$2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
flag_bound_evaluated = 0}
but differ in padding. Notice the 4-byte hole:
(top-gdb) ptype /o range_bounds
/* offset | size */ type = struct range_bounds {
/* 0 | 16 */ struct dynamic_prop {
/* 0 | 4 */ dynamic_prop_kind kind;
/* XXX 4-byte hole */
/* 8 | 8 */ union dynamic_prop_data {
/* 8 */ LONGEST const_val;
/* 8 */ void *baton;
/* total size (bytes): 8 */
} data;
which is filled with garbage:
(top-gdb) x /40bx TYPE_RANGE_DATA (type1)
0x2fa7ea0: 0x01 0x00 0x00 0x00 0x43 0x01 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x2fa7ea8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7eb0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x2fa7eb8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x2fa7ec0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) x /40bx TYPE_RANGE_DATA (type2)
0x20379b0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0x20379b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379c0: 0x01 0x00 0x00 0x00 0xfe 0x7f 0x00 0x00
0x20379c8: 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20379d0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
$3 = -187
In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset. E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.
At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere. But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.
So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.
This fixes the random FAILs in GCC's testcase.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
gdb/ChangeLog:
2018-01-24 Pedro Alves <palves@redhat.com>
GCC PR libstdc++/83906
* gdbtypes.c (operator==(const dynamic_prop &,
const dynamic_prop &)): New.
(operator==(const range_bounds &, const range_bounds &)): New.
(check_types_equal): Use them instead of memcmp.
* gdbtypes.h (operator==(const dynamic_prop &,
const dynamic_prop &)): Declare.
(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
(operator==(const range_bounds &, const range_bounds &)): Declare.
(operator!=(const range_bounds &, const range_bounds &)): Declare.
Following my recent transition from Imagination Technologies to the
reincarnated MIPS company update MAINTAINERS entries accordingly.
binutils/
* MAINTAINERS: Update my company e-mail address.
gdb/
* MAINTAINERS: Update my company e-mail address.
sim/
* MAINTAINERS: Update my company e-mail address.
(cherry picked from commit d65ce302abcb260e14ca5f201b78e8e6d4a2e720)
Compiling GDB with a recent GCC exposes a problem:
../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
real_type = value_rtti_type (val, &full, &top, &using_enc);
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The warning is correct. There are indeed code paths that use
uninitialized 'val', leading to crashes. Inside the
value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:
if (opts.objectprint)
{
if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
&& (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
real_type = value_rtti_type (val, &full, &top, &using_enc);
}
We reach those calls above with "set print object on", and then with
any of:
(gdb) whatis struct some_structure_type
(gdb) whatis struct some_structure_type *
(gdb) whatis struct some_structure_type &
because "whatis" with a type argument enters this branch:
/* The behavior of "whatis" depends on whether the user
expression names a type directly, or a language expression
(including variable names). If the former, then "whatis"
strips one level of typedefs, only. If an expression,
"whatis" prints the type of the expression without stripping
any typedef level. "ptype" always strips all levels of
typedefs. */
if (show == -1 && expr->elts[0].opcode == OP_TYPE)
{
which does not initialize VAL. Trying the above triggers crashes like
this:
(gdb) set print object on
(gdb) whatis some_structure_type
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
2388 int instance_flags = TYPE_INSTANCE_FLAGS (type);
...
This is a regression caused by a recent-ish refactoring of the code on
'whatis_exp', introduced by:
commit c973d0aa4a2c737ab527ae44a617f1c357e07364
Date: Mon Aug 21 11:34:32 2017 +0100
Fix type casts losing typedefs and reimplement "whatis" typedef stripping
Fix this by setting VAL to NULL in the "whatis TYPE" case, and
skipping fetching the dynamic type if there's no value to fetch it
from.
New tests included.
gdb/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
case.
gdb/testsuite/ChangeLog:
2018-01-22 Pedro Alves <palves@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/whatis.exp: Add tests for 'set print object on' +
'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.
This fixes a GCC warning that happens when compiling
gdb/compile/compile.c on some GCC versions (e.g., "gcc (GCC) 7.2.1
20180104 (Red Hat 7.2.1-6)"):
../../gdb/compile/compile.c: In function 'void eval_compile_command(command_line*, const char*, compile_i_scope_types, void*)':
../../gdb/compile/compile.c:548:19: warning: 'triplet_rx' may be used uninitialized in this function [-Wmaybe-uninitialized]
error_message = compiler->fe->ops->set_arguments_v0 (compiler->fe, triplet_rx,
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
argc, argv);
~~~~~~~~~~~
../../gdb/compile/compile.c:466:9: note: 'triplet_rx' was declared here
char *triplet_rx;
^~~~~~~~~~
It's a simple patch that converts "triplet_rx" from "char *" to
"std::string", thus guaranteeing that it will be always initialized.
I've regtested this patch and did not find any regressions. OK to
apply on both master and 8.1 (after creating a bug for it)?
gdb/ChangeLog:
2018-01-17 Sergio Durigan Junior <sergiodj@redhat.com>
* compile/compile.c (compile_to_object): Convert "triplet_rx"
to "std::string".
Make <sys/types.h> be included prior to including <sys/user.h>.
glibc versions older than 2.14 use __uintNN_t types within certain
structures defined in <sys/user.h> probably assuming these types are
defined prior to including the header. This results in the following
`configure` feature test compilation error that makes it think that
`struct user_regs_struct` doesn't have `fs_base`/`gs_base` fields,
althouh it does.
configure:13617: checking for struct user_regs_struct.fs_base
configure:13617: gcc -c -g -O2 -I/linux/include conftest.c >&5
In file included from conftest.c:158:0:
/usr/include/sys/user.h:32:3: error: unknown type name '__uint16_t'
__uint16_t cwd;
^
/usr/include/sys/user.h:33:3: error: unknown type name '__uint16_t'
__uint16_t swd;
^
/usr/include/sys/user.h:34:3: error: unknown type name '__uint16_t'
__uint16_t ftw;
^
/usr/include/sys/user.h:35:3: error: unknown type name '__uint16_t'
__uint16_t fop;
^
/usr/include/sys/user.h:36:3: error: unknown type name '__uint64_t'
__uint64_t rip;
^
/usr/include/sys/user.h:37:3: error: unknown type name '__uint64_t'
__uint64_t rdp;
^
/usr/include/sys/user.h:38:3: error: unknown type name '__uint32_t'
__uint32_t mxcsr;
^
/usr/include/sys/user.h:39:3: error: unknown type name '__uint32_t'
__uint32_t mxcr_mask;
^
/usr/include/sys/user.h:40:3: error: unknown type name '__uint32_t'
__uint32_t st_space[32]; /* 8*16 bytes for each FP-reg = 128 bytes */
^
/usr/include/sys/user.h:41:3: error: unknown type name '__uint32_t'
__uint32_t xmm_space[64]; /* 16*16 bytes for each XMM-reg = 256 bytes */
^
/usr/include/sys/user.h:42:3: error: unknown type name '__uint32_t'
__uint32_t padding[24];
^
configure:13617: $? = 1
configure: failed program was:
| /* confdefs.h */
...
| /* end confdefs.h. */
| #include <sys/user.h>
|
| int
| main ()
| {
| static struct user_regs_struct ac_aggr;
| if (ac_aggr.fs_base)
| return 0;
| ;
| return 0;
| }
Recent glibc versions don't use typedef'ed int types in <sys/user.h>,
thus allowing it to be included as is
(glibc commit d79a9c949c84e7f0ba33e87447c47af833e9f11a).
However there're still some distros alive that use older glibc,
for instance, RHEL/CentOS 6 package glibc 2.12.
Also affects PR gdb/21559:
../../gdb/regcache.c:1087: internal-error: void regcache_raw_supply(regcache, int, const void): Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
As noted by Andrew Paprocki, who submitted the PR
(https://sourceware.org/bugzilla/show_bug.cgi?id=21559#c3):
> It should be noted that modifying `configure` to force on
> `HAVE_STRUCT_USER_REGS_STRUCT_FS_BASE` and
> `HAVE_STRUCT_USER_REGS_STRUCT_GS_BASE` fixes this issue. For some
> reason the `configure` tests for `fs_base` and `gs_base` fail
> even though `sys/user.h` on RHEL5 has the fields defined in
> `user_regs_struct`.
Note that this patch does NOT fix the root cause of PR gdb/21559,
although now that `configure` properly detects the presence of the
fields and sets HAVE_XXX accordingly, the execution takes another
path, which doesn't lead to the assertion failure in question.
gdb/ChangeLog:
2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com>
PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2018-01-17 Eldar Abusalimov <eldar.abusalimov@jetbrains.com>
PR gdb/21559
* configure.ac: Include <sys/types.h> prior to <sys/user.h> when
checking for fs_base/gs_base fields in struct user_regs_struct.
* configure: Regenerate.
Nowadays, if we use "compile" on aarch64-linux, we'll get the following
error,
(gdb) compile code -- ;
aarch64-none-linux-gnu-gcc: error: unrecognized command line option '-m64'
because the default gcc_target_options returns "-m64" and
"-mcmodel=large", neither is useful to aarch64-linux.
gdb:
2018-01-17 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_gcc_target_options): New
function.
(aarch64_linux_init_abi): Install it to gdbarch hook
gcc_target_options.
One test in gdb.compile/compile.exp passes on one fedora builder,
bt
#0 0x00007ffff7ff43f6 in _gdb_expr (__regs=0x7ffff7ff2000) at gdb
command line:1^M
#1 <function called from gdb>^M
#2 main () at /home/gdb-buildbot/fedora-x86-64-1/fedora-x86-64/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) PASS: gdb.compile/compile.exp: bt
but fails on my machine with gcc trunk,
bt^M
#0 _gdb_expr (__regs=0x7ffff7ff3000) at gdb command line:1^M
#1 <function called from gdb>^M
#2 main () at gdb/testsuite/gdb.compile/compile.c:106^M
(gdb) FAIL: gdb.compile/compile.exp: bt
The test should be tweaked to match both cases (pc in the start of line
vs pc in the middle of line). Note that I am not clear that why libcc1
emits debug info this way so that the address is in the middle of line.
gdb/testsuite:
2018-01-17 Yao Qi <yao.qi@linaro.org>
* gdb.compile/compile.exp: Match the address printed for
frame in the output of command "bt".
In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.
What happens is that on x86, this:
set sp_reg [get_integer_valueof "\$sp" 0]
... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":
print /d $sp
$1 = -11496
Then later the test suite does:
gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
"= $sp_reg" \
"seek to \$sp"
... expecting this value to be identical to the saved $sp_reg value.
However it gets:
guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
= 4294955800
"print" is just a wrapper for guile's format:
gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"
The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.
Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.
2018-01-15 Tom Tromey <tom@tromey.com>
* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
compute sp_reg.
This adds a testcase for the previous commit. The regression was
related to in-line step overs. The reason we didn't see it on native
x86-64/s390 GNU/Linux testing is that native debugging uses displaced
stepping by default (because native debugging defaults to "maint set
target-non-stop on"), unlike remote debugging.
So in order to trigger the bug with native debugging as well, the
testcase disables displaced stepping explicitly.
Also, instead of using watchpoints to trigger the regression, the
testcase uses a breakpoint at address 0, which should be more
portable.
gdb/testsuite/ChangeLog:
2018-01-12 Pedro Alves <palves@redhat.com>
* gdb.base/continue-after-aborted-step-over.c: New.
* gdb.base/continue-after-aborted-step-over.exp: New.
Since this commit --
Fix PR18360 - internal error when using "interrupt -a"
(https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55)
-- the testsuite shows long delays on s390 with native-gdbserver when
executing certain tests, such as watchpoints.exp. These hangs have been
discussed before in the context of buildbot problems, see here:
https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html
The problem can easily be triggered by stopping on a breakpoint, then
setting impossible watchpoints, and finally doing "continue". Then, after
having set the step-over state (in keep_going_pass_signal in infrun.c),
GDB tries to insert breakpoints and watchpoints into the inferior. This
fails, and the "continue" command is aborted. But the step-over state is
not cleared in this case, which causes future step-over attempts to be
skipped since GDB thinks that "we already have an in-line step-over
operation ongoing" (see start_step_over in infrun.c). Thus the next
"continue" just goes on to wait for events from the remote, which will
never occur.
The problem can also be reproduced on amd64 with native-gdbserver, using
the following change to watchpoints.exp:
-- >8 --
--- a/gdb/testsuite/gdb.base/watchpoints.exp
+++ b/gdb/testsuite/gdb.base/watchpoints.exp
@@ -61,2 +61,3 @@ with_test_prefix "before inferior start" {
gdb_test "watch ival3" ".*" ""
+ gdb_test "watch *(char \[256\] *) main"
-- >8 --
To fix the hang, this patch clears the step-over info when
insert_breakpoints has failed. Of course, with native-gdbserver the
watchpoints.exp test case still causes many FAILs on s390, because
gdbserver does not support watchpoints for that target. This is a
separate issue.
gdb/ChangeLog:
2018-01-12 Andreas Arnez <arnez@linux.vnet.ibm.com>
* infrun.c (keep_going_pass_signal): Clear step-over info when
insert_breakpoints fails.
As Maciej reported at
<https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this
commit:
commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e
Date: Thu Nov 16 18:44:43 2017 +0000
Subject: Don't ever Quit out of resume
caused regressions on software single-set targets, specifically:
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break)
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind
FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind
and indeed detailed logs indicate a breakpoint is left lingering, e.g.:
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
maint info breakpoints 0
Num Type Disp Enb Address What
0 sw single-step keep y 0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1
stop only in thread 1
(gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
vs:
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break)
maint info breakpoints 0
No breakpoint or watchpoint matching '0'.
(gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind
as at commit d930703d68ae^.
Before commit d930703d68ae, we had a cleanup installed in 'resume'
that would delete single-step breakpoints on error:
/* Resuming. */
/* Things to clean up if we QUIT out of resume (). */
static void
resume_cleanups (void *ignore)
{
if (!ptid_equal (inferior_ptid, null_ptid))
delete_single_step_breakpoints (inferior_thread ());
normal_stop ();
}
That whole function was removed by d930703d68ae mainly to eliminate
the normal_stop call:
~~~~
Note that the exception called from within resume ends up calling
normal_stop via resume_cleanups. That's very borked though, because
normal_stop is going to re-handle whatever was the last reported
event, possibly even re-running a hook stop...
~~~~
But as the regression shows, removing resume_cleanups completely went
a bit too far, as the delete_single_step_breakpoints call is still
necessary.
So fix the regression by reinstating the
delete_single_step_breakpoints call on error. However, since we're
trying to eliminate cleanups, restore it in a different form (using
TRY/CATCH).
Tested on x86-64 GNU/Linux both top of master and on top of a series
that implements software single-step on x86.
gdb/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR gdb/22583
* infrun.c (resume): Rename to ...
(resume_1): ... this.
(resume): Reimplement as wrapper around resume_1.
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>,
Maciej reported that commit:
commit 5cd63fda035d4ba949e6478406162c4673b3c9ef
Date: Wed Oct 4 18:21:10 2017 +0100
Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors
made GDB stop working with older stubs. Any attempt to continue
execution after the initial connection fails with:
[...]
Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670
Listening on port 2346
target remote [...]:2346
Remote debugging using [...]:2346
Reading symbols from .../lib64/ld.so.1...done.
[Switching to Thread <main>]
(gdb) continue
Cannot execute this command without a live selected thread.
(gdb)
The problem is:
(gdb) c
Cannot execute this command without a live selected thread.
(gdb) info threads
Id Target Id Frame
1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2
The current thread <Thread ID 2> has terminated. See `help thread'.
^^^^^^^^^^^
(gdb)
Note, thread _2_. There's really only one thread in the inferior
(it's still at the entry point), but still GDB added a bogus second
thread.
The reason GDB started adding a second thread after 5cd63fda035d is
this hunk:
+ if (event->ptid == null_ptid)
+ {
+ const char *thr = strstr (p1 + 1, ";thread:");
+ if (thr != NULL)
+ event->ptid = read_ptid (thr + strlen (";thread:"),
+ NULL);
+ else
+ event->ptid = magic_null_ptid;
+ }
Note the else branch that falls back to magic_null_ptid. We reach
that when we process the initial stop reply sent back in response to
the the "?" (status) packet early in the connection setup:
Sending packet: $?#3f...Ack
Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000;
And note that that response does not include a ";thread:XXX" part.
This stop reply is processed after listing threads with qfThreadInfo /
qsThreadInfo :
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m3915
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
meaning, when we process that stop reply, we treat the event as coming
from a thread with ptid == magic_null_ptid, which is not yet in the
thread list, so we add it then:
(top-gdb) p ptid
$1 = {m_pid = 42000, m_lwp = -1, m_tid = 1}
(top-gdb) bt
#0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269
#1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0)
at src/gdb/remote.c:1838
#2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0)
at src/gdb/remote.c:1921
#3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00)
at src/gdb/remote.c:7217
#4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/remote.c:7380
#5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446
#6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138
#7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/target.c:2179
#8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0)
at src/gdb/infrun.c:3589
#9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707
#10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212
things go downhill from this.
We don't see the problem with current master gdbserver, because that
version always sends the ";thread:" part in the initial stop reply:
Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3;
Years ago I had added a "--disable-packet=" command line option to
gdbserver which comes in handy for testing this, since the existing
"--disable-packet=Tthread" precisely makes gdbserver not send that
";thread:" part in stop replies. The testcase added by this commit
emulates old gdbserver making use of that.
I've compared a testrun at 5cd63fda035d^ (before regression) with
'current master+patch', against old gdbserver at f8b73d13b7ca^. I
hacked out --once, and "monitor exit" to be able to test. The results
are a bit too unstable to tell accurately, but it looked like there
were no regressions. Maciej confirmed this worked for him as well.
No regressions on master (against master gdbserver).
gdb/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* remote.c (remote_parse_stop_reply): Default to the last-set
general thread instead of to 'magic_null_ptid'.
gdb/testsuite/ChangeLog:
2018-01-11 Pedro Alves <palves@redhat.com>
PR remote/22597
* gdb.server/stop-reply-no-thread.c: New file.
* gdb.server/stop-reply-no-thread.exp: New file.
Rename language_get_symbol_name_matcher -> get_symbol_name_matcher,
since the function is no longer a straight "language method".
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
* language.h (language_get_symbol_name_matcher): Rename ...
(get_symbol_name_matcher): ... this.
* language.c (language_get_symbol_name_matcher): Ditto.
* dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All
callers adjusted.
A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.
For example, this is what happens if we use "print" instead of
"break":
(gdb) p <MixedCaseFunc>
$1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>
Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it. If you try it before having started the inferior, you'd get the
following (expected) error:
(gdb) print <MixedCaseFunc>
You can't do that without a process to debug.
The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.
Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language. We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.
I'm not entirely happy with the "current_language" reference (though I
think that it's harmless). I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names. I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it. Maybe
something different will be better. Meanwhile, this gets us going.
I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* dwarf2read.c
(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
Adjust to use language_get_symbol_name_matcher instead of
language_defn::la_get_symbol_name_matcher.
* language.c (language_get_symbol_name_matcher): If in Ada mode
and the lookup name is a verbatim match, return Ada's matcher.
* language.h (language_get_symbol_name_matcher): Adjust comment.
(ada_lookup_name_info::verbatim_p):: New method.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C
functions too. Test setting breakpoints and printing C functions
with no debug info too.
* gdb.ada/bp_c_mixed_case/qux.c: New file.
This patch fixes the regression covered by the test added by:
commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d
Date: Thu Jan 4 03:30:37 2018 -0500
Subject: Add "complete break ada" test to gdb.ada/complete.exp
The regression had been introduced by:
commit b5ec771e60c1a0863e51eb491c85c674097e9e13
Date: Wed Nov 8 14:22:32 2017 +0000
Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching
The gist of it is that linespec completion in Ada mode is generating
additional matches that should not appear in the match list
(internally generated symbols, or symbols that should be enclosed
between "<...>"). These extraneous entries have uppercase characters, such as:
break ada__stringsS
break ada__strings__R11s
[etc]
These matches come from minimal symbols. The problem is that Ada
minsyms end up with no language set (language_auto), and thus we end
up using the generic symbol name matcher for those instead of Ada's.
We already had a special case for in compare_symbol_name to handle
this, but it was limited to expressions, while the case at hand is
completing a linespec. Fix this by applying the special case to
linespec completion as well. I.e., remove the EXPRESSION check from
compare_symbol_name. That alone turns out to not be sufficient still
-- GDB would still show a couple entries that shouldn't be there:
~~
break ada__exceptions__exception_data__append_info_exception_name__2Xn
break ada__exceptions__exception_data__exception_name_length__2Xn
~~
The reason is that these minimal symbols end up with their language
set to language_cplus / C++, because those encoded names manage to
demangle successfully as C++ symbols (using an old C++ mangling
scheme):
$ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt
Xn::ada__exceptions__exception_data__append_info_exception_name(void)
It's unfortunate that Ada's encoding scheme doesn't start with some
unique prefix like "_Z" in the C++ Itanium ABI mangling scheme. For
now, paper over that by treating C++ minsyms as Ada minsyms.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* ada-lang.c (ada_collect_symbol_completion_matches): If the
minsym's language is language_auto or language_cplus, pass down
language_ada instead.
* symtab.c (compare_symbol_name): Don't frob symbol language here.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/complete.exp ("complete break ada"): Replace kfail with
a fail.
The problem here is that we are using the user-provided lookup name
literally for name comparisons. I.e., "<MixedCase>" with the "<>"s
included.
This commit fixes the minsym lookup case. psymbol/symbol lookup will
be fixed in a follow up.
In the minsym case, we're using using the user-provided lookup name
literally for linkage name comparisons. That obviously can't work
since the "<>" are not really part of the linkage name.
The original idea was that we'd use the symbol's language to select
the right symbol name matching algorithm, but that doesn't work for
Ada because it's not really possible to unambiguously tell from the
linkage name alone whether we're dealing with Ada symbols, so Ada
minsyms end up with no language set, or sometimes C++ set.
So fix this by treating Ada mode specially when determining the
linkage name to match against.
gdb/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* minsyms.c (linkage_name_str): New function.
(iterate_over_minimal_symbols): Use it.
gdb/testsuite/ChangeLog:
2018-01-10 Pedro Alves <palves@redhat.com>
PR gdb/22670
* gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
Add PIE support for hurd, by faking an AT_ENTRY auxv entry. That value
is expected to be read by svr4_exec_displacement, which will propagate
the executable displacement.
gdb/ChangeLog:
* gdb/gnu-nat.c: Include <elf.h> and <link.h>.
(gnu_xfer_auxv): New function.
(gnu_xfer_partial): Call gnu_xfer_auxv when `object' is
TARGET_OBJECT_AUXV.
When we set bfd/development.sh:$development to false, GDBserver failed to
build,
selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/gdbserver/../common/selftest.c:97:undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status
selftest.o shouldn't be compiled and linked when $development is false.
With this patch, in release mode, GDBserver doesn't nothing with option
--selftest,
$ ./gdbserver --selftest=foo
Selftests are not available in a non-development build.
$ ./gdbserver --selftest
Selftests are not available in a non-development build.
gdb/gdbserver:
2018-01-08 Yao Qi <yao.qi@linaro.org>
Simon Marchi <simon.marchi@ericsson.com>
* Makefile.in (OBS): Remove selftest.o.
* configure.ac: Set srv_selftest_objs if $development is true.
(GDBSERVER_DEPFILES): Append $srv_selftest_objs.
* configure: Re-generated.
* server.c (captured_main): Wrap variable selftest_filter with
GDB_SELF_TEST.
gdb/testsuite:
2018-01-08 Simon Marchi <simon.marchi@ericsson.com>
* gdb.server/unittest.exp: Match the output in non-development
mode.
We don't build GDB selftests bits when $development is false. However, if
we turn bfd/development.sh:$development to false, common/selftest.c is
compiled which is not expected. It causes the build failure,
selftest.o: In function `selftests::run_tests(char const*)':
binutils-gdb/gdb/common/selftest.c:97: undefined reference to `selftests::reset()'
collect2: error: ld returned 1 exit status
I fix this issue by putting selftest.o selftest-arch.o into CONFIG_OBS
only when $development is true. After this is fixed, there are other
build failures in maint.c, this patch fixes them as well.
In the release mode, the output of these commands are:
(gdb) maintenance selftest
Selftests are not available in a non-development build.
(gdb) maintenance selftest foo
Selftests are not available in a non-development build.
(gdb) maintenance info selftests
Selftests are not available in a non-development build.
gdb:
2018-01-08 Yao Qi <yao.qi@linaro.org>
Simon Marchi <simon.marchi@ericsson.com>
* Makefile.in (COMMON_SFILES): Remove selftest-arch.c and
common/selftest.c.
(COMMON_OBS): Remove selftest.o.
* configure.ac: Append selftest-arch.c and common/selftest.c to
CONFIG_SRCS. Append selftest-arch.o and selftest.o to COMMON_OBS.
* configure: Re-generated.
* maint.c (maintenance_selftest): Wrap selftests::run_tests with
GDB_SELF_TEST.
(maintenance_info_selftests): Likewise.
gdb/testsuite:
2018-01-08 Simon Marchi <simon.marchi@ericsson.com>
* gdb.gdb/unittest.exp: Match output in non-development mode.
At https://sourceware.org/bugzilla/show_bug.cgi?id=18653#c7, Andrew
reports that the fix for PR gdb/18653 made GDB useless if you preload
libSegFault.so, because GDB internal-errors on startup:
$ LD_PRELOAD=libSegFault.so gdb
src/gdb/common/signals-state-save-restore.c:64: internal-error: unexpected signal handler
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Aborted (core dumped)
$
The internal error comes from the code saving the signal dispositions
inherited from gdb's parent:
(top-gdb) bt
#0 0x000000000056b001 in internal_error(char const*, int, char const*, ...) (file=0xaf5f38 "src/gdb/common/signals-state-save-restore.c", line=64, fmt=0xaf5f18 "unexpected signal handler") at src/gdb/common/errors.c:54
#1 0x00000000005752c9 in save_original_signals_state() () at src/gdb/common/signals-state-save-restore.c:64
#2 0x00000000007425de in captured_main_1(captured_main_args*) (context=0x7fffffffd860)
at src/gdb/main.c:509
#3 0x0000000000743622 in captured_main(void*) (data=0x7fffffffd860) at src/gdb/main.c:1145
During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
#4 0x00000000007436f9 in gdb_main(captured_main_args*) (args=0x7fffffffd860) at src/gdb/main.c:1171
#5 0x0000000000413acd in main(int, char**) (argc=1, argv=0x7fffffffd968) at src/gdb/gdb.c:32
This commit downgrades the internal error to a warning. You'll get
instead:
~~~
$ LD_PRELOAD=libSegFault.so gdb
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)
won't be propagated to spawned programs.
GNU gdb (GDB) 8.0.50.20171213-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
(gdb)
~~~
This also moves the location where save_original_signals_state is
called a bit further below (to after option processing), so that "-q"
disables the warning:
~~~
$ LD_PRELOAD=libSegFault.so gdb -q
(gdb)
~~~
New testcase included.
gdb/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* common/signals-state-save-restore.c
(save_original_signals_state): New parameter 'quiet'. Warn if we
find a custom handler preinstalled, instead of internal erroring.
But only warn if !quiet.
* common/signals-state-save-restore.h
(save_original_signals_state): New parameter 'quiet'.
* main.c (captured_main_1): Move save_original_signals_state call
after option handling, and pass QUIET.
gdb/gdbserver/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* server.c (captured_main): Pass quiet=false to
save_original_signals_state.
gdb/testsuite/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/18653
* gdb.base/libsegfault.exp: New.
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00298.html>, Joel
wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Consider the following code which first declares a tagged type (the
equivalent of a class in Ada), and then a procedure which takes a
pointer (access) to this type's 'Class.
package Pck is
type Top_T is tagged record
N : Integer := 1;
end record;
procedure Inspect (Obj: access Top_T'Class);
end Pck;
Putting a breakpoint in that procedure and then running to it triggers
an internal error:
(gdb) break inspect
(gdb) continue
Breakpoint 1, pck.inspect (obj=0x63e010
/[...]/gdb/stack.c:621: internal-error: void print_frame_args(symbol*, frame_info*, int, ui_file*): Assertion `nsym != NULL' failed.
What's special about this subprogram is that it takes an access to
what we call a 'Class type, and for implementation reasons, the
compiler adds an extra argument named "objL". If you are curious why,
it allows the compiler for perform dynamic accessibility checks that
are mandated by the language.
If we look at the location where we get the internal error (in
stack.c), we find that we are looping over the symbol of each
parameter, and for each parameter, we do:
/* We have to look up the symbol because arguments can have
two entries (one a parameter, one a local) and the one we
want is the local, which lookup_symbol will find for us.
[...]
nsym = lookup_symbol (SYMBOL_LINKAGE_NAME (sym),
b, VAR_DOMAIN, NULL).symbol;
gdb_assert (nsym != NULL);
The lookup_symbol goes through the lookup structure, which means the
symbol's linkage name ("objL") gets transformed into a
lookup_name_info object (in block_lookup_symbol), before it gets fed
to the block symbol dictionary iterators. This, in turn, triggers the
symbol matching by comparing the "lookup" name which, for Ada, means
among other things, lowercasing the given name to "objl". It is this
transformation that causes the lookup find no matches, and therefore
trip this assertion.
Going back to the "offending" call to lookup_symbol in stack.c, what
we are trying to do, here, is do a lookup by linkage name. So, I
think what we mean to be doing is a completely literal symbol lookup,
so maybe not even strcmp_iw, but actually just plain strcmp???
In the past, in practice, you could get that effect by doing a lookup
using the C language. But that doesn't work, because we still end up
somehow using Ada's lookup_name routine which transforms "objL".
So, ideally, as I hinted before, I think what we need is a way to
perform a literal lookup so that searches by linkage names like the
above can be performed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This commit fixes the problem by implementing something similar to
Joel's literal idea, but with some important differences.
I considered adding a symbol_name_match_type::LINKAGE and supporting
searching by linkage name for any language, but the problem with that
is that the dictionaries only work with SYMBOL_SEARCH_NAME, because
that's what is used for hashing. We'd need separate dictionaries for
hashed linkage names.
So with the current symbol tables infrastructure, it's not literal
linkage names that we want to pass down, but instead literal _search_
names (SYMBOL_SEARCH_NAME, etc.).
However, psymbols have no overload/function parameter info in C++, so
a straight strcmp doesn't work properly for C++ name matching.
So what we do is be a little less aggressive then and add a new
symbol_name_match_type::SEARCH_SYMBOL instead that takes as input a
non-user-input search symbol, and then we skip any decoding/demangling
steps and make:
- Ada treat that as a verbatim match,
- other languages treat it as symbol_name_match_type::FULL.
This also fixes the new '"maint check-psymtabs" for Ada' testcase for
me (gdb.ada/maint_with_ada.exp). I've not removed the kfail yet
because Joel still sees that testcase failing with this patch.
That'll be fixed in follow up patches.
gdb/ChangeLog:
2018-01-05 Pedro Alves <palves@redhat.com>
PR gdb/22670
* ada-lang.c (literal_symbol_name_matcher): New function.
(ada_get_symbol_name_matcher): Use it for
symbol_name_match_type::SEARCH_NAME.
* block.c (block_lookup_symbol): New parameter 'match_type'. Pass
it down instead of assuming symbol_name_match_type::FULL.
* block.h (block_lookup_symbol): New parameter 'match_type'.
* c-valprint.c (print_unpacked_pointer): Use
lookup_symbol_search_name instead of lookup_symbol.
* compile/compile-object-load.c (get_out_value_type): Pass down
symbol_name_match_type::SEARCH_NAME.
* cp-namespace.c (cp_basic_lookup_symbol): Pass down
symbol_name_match_type::FULL.
* cp-support.c (cp_get_symbol_name_matcher): Handle
symbol_name_match_type::SEARCH_NAME.
* infrun.c (insert_exception_resume_breakpoint): Use
lookup_symbol_search_name.
* p-valprint.c (pascal_val_print): Use lookup_symbol_search_name.
* psymtab.c (maintenance_check_psymtabs): Use
symbol_name_match_type::SEARCH_NAME and SYMBOL_SEARCH_NAME.
* stack.c (print_frame_args): Use lookup_symbol_search_name and
SYMBOL_SEARCH_NAME.
* symtab.c (lookup_local_symbol): Don't demangle the lookup name
if symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_in_language): Pass down
symbol_name_match_type::FULL.
(lookup_symbol_search_name): New.
(lookup_language_this): Pass down
symbol_name_match_type::SEARCH_NAME.
(lookup_symbol_aux, lookup_local_symbol): New parameter
'match_type'. Pass it down.
* symtab.h (symbol_name_match_type::SEARCH_NAME): New enumerator.
(lookup_symbol_search_name): New declaration.
(lookup_symbol_in_block): New 'match_type' parameter.
gdb/testsuite/ChangeLog:
2018-01-05 Joel Brobecker <brobecker@adacore.com>
PR gdb/22670
* gdb.ada/access_tagged_param.exp: New file.
* gdb.ada/access_tagged_param/foo.adb: New file.
