Add the `is_prototyped` and `set_is_prototyped` methods on `struct
type`, in order to remove the `TYPE_PROTOTYPED` macro. In this patch,
the macro is changed to use the getter, so all the call sites of the
macro that are used as a setter are changed to use the setter method
directly. The next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_prototyped, set_is_prototyped>:
New methods.
(TYPE_PROTOTYPED): Use type::is_prototyped, change all write
call sites to use type::set_is_prototyped.
Change-Id: I6ba285250fae413f7c1bf2ffcb5a2cedc8e743da
Add the `target_is_stub` and `set_target_is_stub` methods on `struct
type`, in order to remove the `TYPE_TARGET_STUB` macro. In this patch,
the macro is changed to use the getter, so all the call sites of the
macro that are used as a setter are changed to use the setter method
directly. The next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <target_is_stub, set_target_is_stub>:
New methods.
(TYPE_TARGET_STUB): Use type::is_stub, change all write call
sites to use type::set_target_is_stub.
Change-Id: I9c71a89adc7ae8d018db9ee156f41c623be0484a
Add the `is_stub` and `set_is_stub` methods on `struct type`, in order
to remove the `TYPE_STUB` macro. In this patch, the macro is changed to
use the getter, so all the call sites of the macro that are used as a
setter are changed to use the setter method directly. The next patch
will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_stub, set_is_stub>: New methods.
(TYPE_STUB): Use type::is_stub, change all write call sites to
use type::set_is_stub.
Change-Id: Ie935e8fe72c908afd8718411e83f4ff00c386bf3
Add the `has_no_signedness` and `set_has_no_signednes` methods on `struct
type`, in order to remove the `TYPE_NOSIGN` macro. In this patch, the macro is
changed to use the getter, so all the call sites of the macro that are used as
a setter are changed to use the setter method directly. The next patch will
remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <has_no_signedness,
set_has_no_signedness>: New methods.
(TYPE_NOSIGN): Use type::has_no_signedness, change all write
call sites to use type::set_has_no_signedness.
Change-Id: I80d8e774316d146fbd814b2928ad5392bada39d5
Add the `is_unsigned` and `set_is_unsigned` methods on `struct type`, in
order to remove the `TYPE_UNSIGNED` macro. In this patch, the
`TYPE_UNSIGNED` macro is changed to use `type::is_unsigned`, so all the
call sites that are used to set this property on a type are changed to
use the new method. The next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_unsigned, set_is_unsigned>: New
methods.
(TYPE_UNSIGNED): Use type::is_unsigned. Change all write call
sites to use type::set_is_unsigned.
Change-Id: Ib09ddce84eda160a801a8f288cccf61c8ef136bc
For Cortex-M targets using floating-point, eg the Cortex-M4F, its not possible
to get any call-stack backtrace if setting a breakpoint in ISR.
The exception stack unwinder for Cortex-M does not consider if floating-point
registers was stacked or not, further the Cortex-M has two stack pointers: MSP
(Main Stack Pointer) and PSP (Process Stack Pointer).
This is not handled when GDB tries to backtrace in the exception stack
unwinder.
This patch fixes this, and gives a correct call-stack backtrace from
breakpoints set in a handler or ISR.
gdb/ChangeLog:
* arm-tdep.c (arm_m_exception_cache): Try use correct stack
pointer and stack frame offset when unwinding.
When running the rust test-cases with release 1.36.0 and LLVM version 7.0, I
run into:
...
(gdb) UNTESTED: gdb.rust/traits.exp: could not read \
outputs/gdb.rust/traits/traits with readelf
PATH: gdb.rust/traits.exp: could not read \
outputs/gdb.rust/traits/traits with readelf
...
Fix the PATH warning by printing [file tail $binfile] instead $binfile.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-14 Tom de Vries <tdevries@suse.de>
* gdb.rust/traits.exp: Fix PATH warning.
The testcase has GDB call my_getenv in the inferior, and that fails
with Clang, because Clang optimizes out my_getenv completely, since it
isn't called anywhere (in the program).
This commit fixes it.
gdb/testsuite/ChangeLog:
* gdb.base/share-env-with-gdbserver.c (main): Call my_getenv
instead of getenv.
If a board file wants to customize how gdb is launched, the obvious
way is to have the board override gdb_spawn. However, that doesn't
work for either gdb.mi/ testcases or gdb.base/dbx.exp, because
default_mi_gdb_start and dbx_gdb_start don't use gdb_spawn currently.
That is fixed by this patch.
gdb/testsuite/
* gdb.base/dbx.exp (dbx_gdb_start): Adjust to use gdb_spawn
instead of spawning GDB with remote_spawn.
* lib/mi-support.exp (default_mi_gdb_start): Adjust to use
gdb_spawn instead of spawning GDB with remote_spawn.
gdb.dwarf2/atomic-type.exp and gdb.dwarf2/ada-linkage-name.exp fail
when testing with "clang -flto" as compiler, like:
$ make check TESTS="gdb.dwarf2/ada-linkage-name.exp" RUNTESTFLAGS="CC_FOR_TARGET='clang -flto'"
because with -flto, functions that aren't referenced anywhere are not
emitted in the final binary. Fix it by adding uses of the functions.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/ada-linkage-name.c (main): Move to the bottom of the
file and add calls to first and second.
* gdb.dwarf2/atomic.c (main): Move to the bottom of the file and
add call to f.
Currently -break-insert always creates a wildmatching breakpoint, and
there's no way to ask for a fullname match. To address that, this
patch adds the equivalent of "break -qualified" to MI:
"-break-insert --qualified".
For the testcase, curiously, it doesn't look like we have _any_
testcase that tests a breakpoint with multiple locations, and, the
existing mi_create_breakpoint / mi_make_breakpoint procedures are only
good for breakpoints with a single location. This patch thus adds a
few new companion routines to mi-support.exp for breakpoints with
multiple locations: mi_create_breakpoint_multi,
mi_make_breakpoint_loc, mi_make_breakpoint_multi.
gdb/ChangeLog:
* NEWS: Document "-break-insert --qualified".
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Handle "--qualified".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Breakpoint Commands): Document
"-break-insert --qualified" and "-dprintf-insert --qualified".
gdb/testsuite/ChangeLog:
* gdb.mi/mi-break-qualified.cc: New file.
* gdb.mi/mi-break-qualified.exp: New file.
* lib/mi-support.exp (mi_create_breakpoint_multi)
(mi_make_breakpoint_loc, mi_make_breakpoint_multi): New
procedures.
(mi_create_breakpoint_1): New, factored out from
mi_create_breakpoint.
gdb.cp/misc.cc seems to have been originally copied from
gdb.cp/classes.cc. The testcases that use it, misc.exp and
inherit.exp don't reference the "register" bits anywhere. Remove
them, since they trigger warnings with newer GCCs, given "register" is
being removed in C++17.
gdb/testsuite/ChangeLog:
* gdb.cp/inherit.exp: No longer pass -Wno-deprecated-register.
* gdb.cp/misc.exp: No longer pass -Wno-deprecated-register.
* gdb.cp/misc.cc (class small, small::method, marker_reg1)
(register_class): Delete.
(main): Don't call register_class.
The gdb.cp/classes.exp testcase has one test that tries to exercise
the case of calling a method on a variable that has been put in a
register.
See the declaration of small in classes.cc:
/* Try to get the compiler to allocate a class in a register. */
class small {
public:
int x;
int method ();
};
and the comment in classes.exp:
# This class is so small that an instance of it can fit in a register.
# When gdb tries to call a method, it gets embarrassed about taking
# the address of a register.
#
# TODO: I think that message should be a PASS, not an XFAIL.
# gdb prints an informative message and declines to do something
# impossible.
#
# The method call actually succeeds if the compiler allocates very
# small classes in memory instead of registers. So this test does
# not tell us anything interesting if the call succeeds.
#
# -- chastain 2003-12-31
And these comments:
https://gcc.gnu.org/legacy-ml/gcc/2010-05/msg00116.htmlhttps://gcc.gnu.org/legacy-ml/gcc/2010-05/msg00117.html
"register keyword has other uses, e.g. for -O0 code variables
declared with register keyword can be put into registers, while
variables declared without it always get stack slots."
"I think it does, without optimization. There's some unique GDB
tests that use this. It causes them to be live between statements in
a machine register instead of always stored in stack slots."
The "register" keyword seems to be ignored by the compiler nowadays
even at -O0, though. With or without the register keyword, the
variable is given a stack slot, at least on x86-64 with GCC 9.
However, if we use the GCC extension to put the variable
in a specific variable:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html#Local-Register-Variables
diff --git c/gdb/testsuite/gdb.cp/classes.cc w/gdb/testsuite/gdb.cp/classes.cc
index 5ea360e4d06..6dcf34689b8 100644
--- c/gdb/testsuite/gdb.cp/classes.cc
+++ w/gdb/testsuite/gdb.cp/classes.cc
@@ -629,7 +629,7 @@ register_class ()
/* We don't call any methods for v, so gcc version cygnus-2.3.3-930220
might put this variable in a register. This is a lose, though, because
it means that GDB can't call any methods for that variable. */
- register small v;
+ register small v asm ("rax");
then it works, and we get an XFAIL:
print v.method ()
Address requested for identifier "v" which is in register $rax
(gdb) XFAIL: gdb.cp/classes.exp: calling method for small class (PRMS 2972)
I think that what we should do here is move this test into its own
file, use that GCC syntax to force it to a register, and do as the
comment says -- issue a pass instead of an XFAIL.
That's what this commit does.
Note that we don't need -Wno-deprecated-register (nor -Wno-register)
anymore in the new testcase, because GNU register-asm local variables
don't trigger the warning, with either GCC or Clang.
gdb/testsuite/ChangeLog:
* gdb.cp/classes.exp: No longer pass -Wno-deprecated-register.
(do_tests): Remove "calling method for small class" test.
* gdb.cp/classes.cc (class small, small::method, marker_reg1)
(register_class): Delete.
(main): Don't call register_class.
* gdb.cp/call-method-register.exp: New file, based on bits removed
from classes.exp.
* gdb.cp/call-method-register.cc: New file, based on bits removed
from classes.cc.
Currently, with a program built from these sources:
$ cat extern.c
void foo () {}
$ cat static.c
static void foo () {}
$ cat main.c
int main () { return 0; }
... if you set a breakpoint on "foo", like:
(gdb) break foo
.. when there's debug info, GDB creates a breakpoint with two
locations, one for each of the external and static functions.
But, when there's no debug info, GDB creates a breakpoint with a
single location, for the external foo. Vis:
$ gcc extern.c static.c main.c -o classify.nodebug
$ gcc extern.c static.c main.c -o classify.debug -g
$ gdb classify.nodebug
Reading symbols from classify.nodebug...
(No debugging symbols found in classify.nodebug)
(gdb) b foo
Breakpoint 1 at 0x40048b
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000000040048b <foo+4>
(gdb)
$ gdb classify.debug
Reading symbols from classify.debug...
(gdb) b foo
Breakpoint 1 at 0x40048b: foo. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x000000000040048b in foo at extern.c:1
1.2 y 0x0000000000400492 in foo at static.c:1
GDB drops the static function is search_minsyms_for_name, where at the
very end of that function we pick only the locations with highest
classification, according to classify_type.
The classify_type logic was introduced here:
https://sourceware.org/pipermail/gdb-patches/2011-December/087864.html
which said:
"Previously, linespec was trying to filter out minsyms as they were
seen. However, this isn't faithful to gdb's historical approach,
which is to priority-order minsyms; see lookup_minimal_symbol."
lookup_minimal_symbol's intro says, in the .c file:
/* Look through all the current minimal symbol tables and find the
first minimal symbol that matches NAME. If OBJF is non-NULL, limit
the search to that objfile. If SFILE is non-NULL, the only file-scope
symbols considered will be from that source file (global symbols are
still preferred). Returns a pointer to the minimal symbol that
matches, or NULL if no match is found.
Note: One instance where there may be duplicate minimal symbols with
the same name is when the symbol tables for a shared library and the
symbol tables for an executable contain global symbols with the same
names (the dynamic linker deals with the duplication).
It's also possible to have minimal symbols with different mangled
names, but identical demangled names. For example, the GNU C++ v3
ABI requires the generation of two (or perhaps three) copies of
constructor functions --- "in-charge", "not-in-charge", and
"allocate" copies; destructors may be duplicated as well.
Obviously, there must be distinct mangled names for each of these,
but the demangled names are all the same: S::S or S::~S. */
struct bound_minimal_symbol
lookup_minimal_symbol (const char *name, const char *sfile,
struct objfile *objf)
{
If you look inside this function, you'll see:
/* External symbols are best. */
...
/* File-local symbols are next best. */
...
/* Symbols for shared library trampolines are next best. */
...
While this logic is good when you're looking for the single "best"
symbol by name, I question it for linespecs, since we want to set
breakpoints in all the multiple locations that match. I see no point
in hidding static functions.
Now, for breakpoints, it does make sense to filter out PLT/trampoline
symbols if we find the actual global matching function symbol.
Otherwise, if we did no filtering (i.e., just removed the
classify_type logic), you would end up with e.g.:
(gdb) b printf
Breakpoint 1 at 0x413a60 (2 locations)
(top-gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000413a60 <printf@plt>
1.2 y 0x00007ffff4653640 in __printf at printf.c:28
instead of this (which is what we get currently) before the shared
library is loaded (a location set in the PLT):
(gdb) b printf
Breakpoint 1 at 0x413a60
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000413a60 <printf@plt>
and this after the library is loaded (only one location, no breakpoint
in the PLT):
(gdb) b printf
Breakpoint 1 at 0x7ffff4653640: file printf.c, line 28.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x00007ffff4653640 in __printf at printf.c:28
This patch fixes the missing breakpoint locations issue by replacing
the classify_type logic in linespec.c with a different logic.
Instead, discard a trampoline symbol if we also found a
global/external symbol with the same name. The patch adds a couple of
testcases testing locations in external vs static functions vs
trampolines/PLTs.
We now get:
For the msym-bp.exp testcase (extern vs static), without debug info:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x000000000040048b <foo+4> ### missing before patch
1.2 y 0x000000000040049d <foo+4>
For the msym-bp.exp testcase (extern vs static), with debug info:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x000000000040048b in foo at src/gdb/testsuite/gdb.base/msym-bp.c:21
1.2 y 0x000000000040049d in foo at src/gdb/testsuite/gdb.base/msym-bp-2.c:21
For the msym-bp-shl.exp testcase (static vs plt), without debug info, before running to main:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004004e0 <foo@plt> ### missing before patch
1.2 y 0x00000000004005db <foo+4>
For the msym-bp-shl.exp testcase (static vs plt), without debug info, after running to main:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004005db <foo+4> ### missing before patch
1.2 y 0x00007ffff7bd65de <foo+4>
For the msym-bp-shl.exp testcase (static vs plt), with debug info, before running to main:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004004e0 <foo@plt> ### missing before patch
1.2 y 0x00000000004005db in foo at src/gdb/testsuite/gdb.base/msym-bp-shl-main-2.c:21
For the msym-bp-shl.exp testcase (static vs plt), with debug info, after running to main:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x00000000004005db in foo at src/gdb/testsuite/gdb.base/msym-bp-shl-main-2.c:21
1.2 y 0x00007ffff7bd65de in foo at src/gdb/testsuite/gdb.base/msym-bp-shl-lib.c:21
gdb/ChangeLog:
* linespec.c (classify_mtype, compare_msyms): Delete.
(search_minsyms_for_name): Remove classification logic. Instead
filter out trampoline symbols if we also found an external
function of the same name.
gdb/testsuite/ChangeLog:
* gdb.base/msym-bp-2.c: New.
* gdb.base/msym-bp-shl-lib.c: New file.
* gdb.base/msym-bp-shl-main-2.c: New file.
* gdb.base/msym-bp-shl-main.c: New file.
* gdb.base/msym-bp-shl.exp: New file.
* gdb.base/msym-bp.c: New file.
* gdb.base/msym-bp.exp: New file.
Now that the GDB 10 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 10 branch created (8087c3fa8b):
* version.in: Bump version to 11.0.50.DATE-git.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Change $_gdb_major to 11.
I noticed this while testing the GDB in the context of the upcoming
GDB 10 release branching, because part of the process involves setting
development to False, which in turn changes the default for including
unittest to false as well. As a result, without this patch, we get
compilation errors in infrun.c such as:
infrun.c:9219:5: error: `scoped_mock_context' was not declared in this scope
This patch fixes it by bracketing the unitttest in namespace selftest
with an #if GDB_SELF_TEST.
gdb/ChangeLog:
* infrun.c (namespace selftests): Only define #if GDB_SELF_TEST.
Tested on x86_64-linux, with and without self-tests.
This adds support for the bfloat16 datatype, which can be seen as a short
version of FP32, skipping the least significant 16 bits of the mantissa.
Since the datatype is currently only supported by the AVX512 registers,
the printing of bfloat16 values is only supported for xmm, ymm and zmm
registers.
gdb/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdbarch.sh: Added bfloat16 type.
* gdbarch.c: Regenerated.
* gdbarch.h: Regenerated.
* gdbtypes.c (floatformats_bfloat16): New struct.
(gdbtypes_post_init): Add builtin_bfloat16.
* gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member.
(floatformats_bfloat16): New struct.
* i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16"
(i386_ymm_type): Add field "v16_bfloat16"
(i386_gdbarch_init): Add set_gdbarch_bfloat16_format.
* target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16.
* gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16.
* gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16.
* features/i386/64bit-avx512.xml: Add bfloat16 type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add bfloat16 type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* x86-avx512bf16.c: New file.
* x86-avx512bf16.exp: Likewise.
* lib/gdb.exp (skip_avx512bf16_tests): New function.
gdb/Changelog:
2020-07-02 Felix Willgerodt <felix.willgerodt@intel.com>
* i386-tdep.c (i386_zmm_type): Fix field names.
(i386_ymm_type): Fix field names.
The options for the "breakpoint condition-evaluation" setting are
"host", "target", and "auto". The help message mentions the option
"gdb" at one point instead of "host". Fix this typo. Also add a period.
gdb/ChangeLog:
2020-09-11 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.c: Fix typo in the help message of the
"set breakpoint condition-evaluation" command.
Remove a stale command that is apparently forgotten after a copy-paste
from 'gdb.base/break-main-file-remove-fail.exp'.
gdb/testsuite/ChangeLog:
2020-09-11 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/bp-cmds-execution-x-script.exp: Remove a stale comment.
gcc commit 387d0773f3 changed the D demangler, with the following
commit log:
libiberty: Add support for `in' and `in ref' storage classes.
The storage class `in' is now a first-class citizen with its own mangle
symbol, of which also permits `in ref'. Previously, `in' was an alias
to `const [scope]', which is a type constructor.
The mangle symbol repurposed for this is `I', which was originally used
by identifier types. However, while TypeIdentifier is part of the
grammar, it must be resolved to some other entity during the semantic
passes, and so shouldn't appear anywhere in the mangled name.
Old tests that are now no longer valid have been removed.
This patch makes the same changes to the gdb testsuite as were made to
the upstream gcc libiberty testsuite.
gdb/testsuite/
PR 26597
* gdb.dlang/demangle.exp: Update tests as per gcc commit 387d0773f3.
No functional change as the same functionality inlined in nbsd-nat.c
is offered in gdb/nat/netbsd-nat.c.
gdb/ChangeLog:
* nbsd-nat.c: Include "nat/netbsd-nat.h".
* (nbsd_nat_target::pid_to_exec_file)
(nbsd_nat_target::thread_alive, nbsd_nat_target::thread_name)
(nbsd_nat_target::post_startup_inferior)
(nbsd_nat_target::post_attach, nbsd_nat_target::xfer_partial)
(nbsd_add_threads): Switch local code to common gdb/nat functions.
* (nbsd_pid_to_cmdline): Call sysctl from the global namespace.
* (nbsd_thread_lister): Remove.
Do not free the last execd pathname as it will be used in
prepare_resume_reply(), after attaching a client side.
gdb/ChangeLog:
* fork-inferior.c (startup_inferior): Avoid double free.
Add generic function to enable debugger events in a process.
gdb/ChangeLog:
* netbsd-nat.h (netbsd_nat::enable_proc_events): Add.
* netbsd-nat.c: Include <sys/ptrace.h>.
* (netbsd_nat::enable_proc_events): Add.
I believe ada-lang.c:remove_extra_symbols has a latent bug. This
function loops over a vector of symbols, removing duplicates according
to some criteria.
At the end of the loop it does:
if (remove_p)
syms->erase (syms->begin () + i);
i += 1;
However, this seems wrong to me -- when removing the i'th element,
this code still increments "i", thus skipping an element.
At first I thought this was a regression from the patches to remove
cleanups from ada-lang.c (this was when std::vector was introduced);
but I found that instead the bug seems to be older:
if (remove_p)
{
for (j = i + 1; j < nsyms; j += 1)
syms[j - 1] = syms[j];
nsyms -= 1;
}
i += 1;
No test, as I don't know how to write one.
As this is Ada-specific, and was already reviewed internally by Joel,
I am checking it in.
gdb/ChangeLog
2020-09-09 Tom Tromey <tromey@adacore.com>
* ada-lang.c (remove_extra_symbols): Do not increment when
removing an element
The previous patch introduced an uninitialized warning in
gdb_bfd_open. The problem was that "abfd" was being used without
being initialized.
This patch fixes the problem by calling bfd_fopen in the branch where
"fstat" has failed.
gdb/ChangeLog
2020-09-08 Tom Tromey <tromey@adacore.com>
* gdb_bfd.c (gdb_bfd_open): Call bfd_fopen when fstat fails.
gdb caches BFDs that come from ordinary files. This code turns out to
have a bug where the hash table can become corrupted, causing gdb to
crash.
When gdb_bfd_open opens the BFD, it uses fstat to get the BFD's mtime.
This is used when inserting the entry into gdb_bfd_cache. Then, the
function creates the gdb_bfd_data object as a side effect of calling
new_reference. This object is used when finding objects in the hash
table, and its constructor uses bfd_get_mtime. So, if the file
changes between the time the BFD is put into the cache and the time
that this object is created, the hash table will be incorrect. When
the BFD is later deleted, its entry in the hash table will not be
found, and at this point the hash table will point to invalid memory.
This patch fixes the bug by ensuring that the mtime, and other
relevant attributes comgin from stat, that are used for insertion are
also used when creating the gdb_bfd_data.
This obsoletes an earlier patch that had split this into two parts
(surrounding a patch to use bfd_stat more consistently). This version
merges the two patches, in the interest of correctness.
gdb/ChangeLog
2020-09-08 Tom Tromey <tromey@adacore.com>
PR win32/25302:
* gdb_bfd.c (gdb_bfd_data): Add "st" parameter.
(gdb_bfd_init_data): New function.
(gdb_bfd_open, gdb_bfd_ref): Use gdb_bfd_init_data.
I'm running into the following FAIL:
...
(gdb) starti ^M
Starting program: frame-inlined-in-outer-frame frame^M
^M
^M
Program stopped.^M
0x0000000000401000 in _start ()^M
(gdb) PASS: gdb.dwarf2/frame-inlined-in-outer-frame.exp: frame
frame^M
(gdb) FAIL: gdb.dwarf2/frame-inlined-in-outer-frame.exp: step into foo
stepi^M
0x0000000000401001 in foo ()^M
...
The problem is that the .exp file issues a gdb_starti_cmd without consuming
the resulting prompt. Consequently, the gdb_test issuing the frame command
consumes that prompt, and things are out-of-sync from that point onwards.
Fix this by consuming the gdb prompt after gdb_starti_cmd.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-08 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/frame-inlined-in-outer-frame.exp: Consume gdb prompt
after gdb_starti_cmd.
Use the available `switch_to_target_no_thread` function to switch the
target. This is a refactoring.
gdb/ChangeLog:
2020-09-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (fetch_inferior_event): Use
`switch_to_target_no_thread` to switch the target.
dwarf2_free_objfile no longer exists, so this patch removes its
declaration from symfile.h.
gdb/ChangeLog
2020-09-06 Tom Tromey <tom@tromey.com>
* symfile.h (dwarf2_free_objfile): Don't declare.
In the test cases complex.exp,pointer-to-pointer.exp,vla-ptr-info.exp
fortran.exp routines are not used, which are to determine the type/kind
string. Due to this these test incorrectly fail for Flang.
Now test cases are modified to use fortran.exp routines. fortran.exp
file is modified to add absent routines fortran_complex8 and
fortran_complex16.
gdb/testsuite/ChangeLog
* lib/fortran.exp (fortran_complex8): New proc.
(fortran_complex16): New proc.
* gdb.fortran/complex.exp: Use routines from fortran.exp
* gdb.fortran/pointer-to-pointer.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
Currently GDB is not able to print correct value for real/complex type
from binary generated from Flang compiler. This is due to GDB not able
to recognise and determine correct format floatformats_ia64_quad and
instead falling back to default_floatformat_for_type. This leads
incorrect output.
Now function i386_floatformat_for_type is fixed to correctly identify
Flang generated 16 byte real/complex type.
gdb/ChangeLog
* gdb/i386-tdep.c (i386_floatformat_for_type): Added conditions
to match 16 byte real/complex type generated by Flang compiler.
When adding:
...
if ![runto_main] then {
fail "can't run to main"
return 0
}
...
to test-case gdb.base/label-without-address.exp and running it with target
board unix/-fPIE/-pie, we run into:
...
(gdb) break main:L1^M
Breakpoint 2 at 0x555555554000: file label-without-address.c, line 22.^M
...
That is, for a label with optimized-out address, we set a breakpoint at the
relocation base.
The root cause is that the dwarf reader, despite finding that attribute
DW_AT_low_pc is missing, still tags the L1 symbol as having LOC_LABEL, which
means it has a valid address, which defaults to 0.
Fix this by instead tagging the L1 symbol with LOC_OPTIMIZED_OUT.
Tested on x86_64-linux.
gdb/ChangeLog:
2020-09-03 Tom de Vries <tdevries@suse.de>
PR breakpoint/26546
* dwarf2/read.c (new_symbol): Tag label symbol without DW_AT_low_pc as
LOC_OPTIMIZED_OUT instead of LOC_LABEL.
gdb/testsuite/ChangeLog:
2020-09-03 Tom de Vries <tdevries@suse.de>
PR breakpoint/26546
* gdb.base/label-without-address.exp: Runto main first.
Since the "maintenance info sections" helper functions are not used
through a callback with a void* parameter anymore, the
maint_print_section_data is not needed anymore. Remove it, replace it
with regular parameters.
Break out the index digits computation in its own function.
gdb/ChangeLog:
* maint.c (index_digits): New function.
(struct maint_print_section_data): Remove.
(print_bfd_section_info): Remove print_data parameter, add arg
and index_digits.
(print_objfile_section_info): Likewise.
(print_bfd_section_info_maybe_relocated): Likewise (plus
objfile).
(maintenance_info_sections): Adjust calls.
Change-Id: Idfeca5e7e0a95e72fade15cb1488058865c0258e
The Ada varobj code automatically dereferences access types. This is
often handy, but it also does so for null pointers -- showing children
with empty values.
These children are weird, but even weirder when a variant type is
involved, because only the non-varying parts of the type are
displayed. This behavior conflicts a bit with my ongoing quest to
move the Ada code to use DWARF rather than gnat encodings, in that
reproducing this behavior with the DWARF code seems rather hacky.
So, this patch instead changes the Ada varobj code so that it does not
automatically dereference null pointers.
As this patch only affects Ada, and it was already reviewed internally
by Joel, I am checking it in.
2020-09-02 Tom Tromey <tromey@adacore.com>
* ada-varobj.c (ada_varobj_get_ptr_number_of_children): Return 0
for null pointers.
(ada_varobj_adjust_for_child_access): Special-case null pointers.
gdb/testsuite/ChangeLog
2020-09-02 Tom Tromey <tromey@adacore.com>
* gdb.ada/mi_var_access.exp: Test children of access variable.
* gdb.ada/mi_var_access/mi_access.adb: Add new stop markers.
* gdb.ada/mi_var_array.exp: Update.
It is currently an int, but it is used as a bool.
gdb/ChangeLog:
* bcache.h (struct bcache) <insert>: Change type of `added` to
pointer to bool.
* bcache.c (bcache::insert): Likewise.
* gdbtypes.c (check_types_worklist): Adjust.
* psymtab.c (add_psymbol_to_bcache): Adjust.
Change-Id: I06b1041636c656782a89cb6106c9ae2593f61616
When testing on docker using the AUFS storage driver, loading a core
file will often print a number of warnings. Here's an example (with
the pathname shortened somewhat):
warning: Can't open file /var/lib/docker/aufs/diff/d07..e21/lib/x86_64-linux-gnu/libc-2.27.so during file-backed mapping note processing
The "warning-free" test in gdb.base/corefile.exp will fail if any
warnings are printed, but this particular warning is unavoidable when
running in the docker environment. Fortunately, the path mentions
both "docker" and "aufs", making it easy to XFAIL this case.
gdb/testsuite/ChangeLog:
* gdb.base/corefile.exp (warning-free): XFAIL test when running
on docker w/ AUFS storage driver.
Luis Machado reported some regressions after I pushed recent core file
related patches fixing BZ 25631:
FAIL: gdb.base/corefile.exp: backtrace in corefile.exp
FAIL: gdb.base/corefile.exp: core-file warning-free
FAIL: gdb.base/corefile.exp: print func2::coremaker_local
FAIL: gdb.base/corefile.exp: up in corefile.exp
FAIL: gdb.base/corefile.exp: up in corefile.exp (reinit)
This commit fixes these regressions. Thanks to Luis for testing
an earlier version of the patch. (I was unable to reproduce these
regressions in various test environments that I created.)
Luis is testing in a docker container which is using the AUFS storage
driver. It turns out that the kernel is placing docker host paths in
the NT_FILE note instead of paths within the container.
I've made a similar docker environment (though apparently not similar
enough to reproduce the regressions). This is one of the paths that
I see mentioned in the warning messages printed while loading the
core file during NT_FILE note processing - note that I've shortened
the path component starting with "d07c4":
/var/lib/docker/aufs/diff/d07c4...21/lib/x86_64-linux-gnu/ld-2.27.so
This is a path on the docker host; it does not exist in the
container. In the docker container, this is the path:
/lib/x86_64-linux-gnu/ld-2.27.so
My first thought was to disable all NT_FILE mappings when any path was
found to be bad. This would have caused GDB to fall back to accessing
memory using the file stratum as it did before I added the NT_FILE
note loading code. After further consideration, I realized that we
could do better than this. For file-backed memory access, we can
still use the NT_FILE mappings when available, and then attempt to
access memory using the file stratum constrained to those address
ranges corresponding to the "broken" mappings.
In order to test it, I made some additions to corefile2.exp in which
the test case's executable is renamed. The core file is then loaded;
due to the fact that the executable has been renamed, those mappings
will be unavailable. After loading the core file, the executable is
renamed back to its original name at which point it is loaded using
GDB's "file" command. The "interesting" tests are then run. These
tests will print out values in file-backed memory regions along with
mmap'd regions placed within/over the file-backed regions. Despite
the fact that the executable could not be found during the NT_FILE
note processing, these tests still work correctly due to the fact that
memory is available from the file stratum combined with the fact that
the broken NT_FILE mappings are used to prevent file-backed access
outside of the "broken" mappings.
gdb/ChangeLog:
* corelow.c (unordered_set): Include.
(class core_target): Add field 'm_core_unavailable_mappings'.
(core_target::build_file_mappings): Print only one warning
per inaccessible file. Add unavailable/broken mappings
to m_core_unavailable_mappings.
(core_target::xfer_partial): Call...
(core_target::xfer_memory_via_mappings): New method.
gdb/testsuite/ChangeLog:
* gdb.base/corefile2.exp (renamed binfile): New tests.
