When building gdb with gcc 12 and -fsanitize=threads while renabling
background dwarf reading by setting dwarf_synchronous to false, I run into:
...
(gdb) file amd64-watchpoint-downgrade
Reading symbols from amd64-watchpoint-downgrade...
(gdb) watch global_var
==================
WARNING: ThreadSanitizer: data race (pid=20124)
Read of size 8 at 0x7b80000500d8 by main thread:
#0 cooked_index_entry::full_name(obstack*, bool) const cooked-index.c:220
#1 cooked_index::get_main_name(obstack*, language*) const cooked-index.c:735
#2 cooked_index_worker::wait(cooked_state, bool) cooked-index.c:559
#3 cooked_index::wait(cooked_state, bool) cooked-index.c:631
#4 cooked_index_functions::wait(objfile*, bool) cooked-index.h:729
#5 cooked_index_functions::compute_main_name(objfile*) cooked-index.h:806
#6 objfile::compute_main_name() symfile-debug.c:461
#7 find_main_name symtab.c:6503
#8 main_language() symtab.c:6608
#9 set_initial_language_callback symfile.c:1634
#10 get_current_language() language.c:96
...
Previous write of size 8 at 0x7b80000500d8 by thread T1:
#0 cooked_index_shard::finalize(parent_map_map const*) \
dwarf2/cooked-index.c:409
#1 operator() cooked-index.c:663
...
...
SUMMARY: ThreadSanitizer: data race cooked-index.c:220 in \
cooked_index_entry::full_name(obstack*, bool) const
==================
Hardware watchpoint 1: global_var
(gdb) PASS: gdb.arch/amd64-watchpoint-downgrade.exp: watch global_var
...
This was also reported in PR31715.
This is due do gcc PR110799 [1], generating wrong code with
-fhoist-adjacent-loads, and causing a false positive for
-fsanitize=threads.
Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13
and -fsanitize=threads.
Tested in that same configuration on x86_64-linux. Remaining ThreadSanitizer
problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and
PR32247 (gdb.trace/basic-libipa.exp).
PR gdb/31715
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31715
Tested-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
While looking at the cooked index entry for local variable l4 of function test
in test-case gdb.fortran/logical.exp:
...
$ gdb -q -batch outputs/gdb.fortran/logical/logical \
-ex "maint print objfiles"
...
[9] ((cooked_index_entry *) 0x7fc6e0003010)
name: l4
canonical: l4
qualified: l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test]
...
I noticed that while the entry does have a parent, that's not reflected in the
qualified name.
This makes it harder to write test-cases that check the parent of a cooked
index entry.
This is due to the implementation of full_name, which skips printing
parents if the language does not specify an appropriate separator.
Fix this by using "::" as default separator, getting us instead:
...
[9] ((cooked_index_entry *) 0x7f94ec0040c0)
name: l4
canonical: l4
qualified: test::l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test]
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
the way the overflow check was written wasn't understood by some
GCC versions and produced false positives for the memset call being
called potentially with object sizes that are larger than half
address-space.
if the input sections are near the max supported size (4G)
we might fail to enlarge the hash table. The error handling
for this case didn't quite work. When this happens we can
gracefully fall back to just not deduplicate this section
(and continue with further mergable sections). We were mixing
that with the case of not being able to even allocate a small
structure (in which case we can as well error out completely),
this disentables both cases.
bfd/
PR ld/32260
* merge.c (sec_merge_maybe_resize): Check overflow in ultimate
target type.
(record_section): Return three-state, use new state when unable
to enlarge hash table.
(_bfd_merge_sections): Remove current section from merging
consideration when hashtable can't be enlarged.
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
into:
...
(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
get_compiler_info: gcc-7-5-0
p Float(Another_Fixed) = Float(Another_Delta * 5)^M
No definition of "another_delta" in current context.^M
(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
...
This is a regression since commit 1411185a57 ("Introduce and use
gnat_version_compare"), which did:
...
# This failed before GCC 10.
- if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
+ if {$scenario == "all" && [gnat_version_compare < 10]} {
gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
"value of another_fixed"
}
...
Fix this by using gnat_version_compare >= 10 instead.
Tested on x86_64-linux, with gcc 7 - 13.
Building shared libraries should not be allowed for PC-relative
relocations against external symbols.
Currently LoongArch has no corresponding checks and silently
generates wrong shared libraries.
However, In the first version of the medium cmodel, pcalau12i+jirl was
used for function calls, in which case PC-relative relocations were
allowed.
This is the assertion that vars->string_ptr < vars->end_string_ptr,
ie. when it fails we've overflowed the string buffer area. Caused by
allocating space for import_name but writing symbol_name, and they can
be different.
* peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change.
The noxfail option is useful in situations like pr23658-1e which
fails on all microblaze ELF targets except microblaze-linux. This was
possible to handle by writing a small proc and use that as an xfail
predicate, or painstakingly listing all microblaze ELF targets, but
this is simpler. The patch also fixes some other FAILs and XPASSes of
the pr23658 tests.
binutils/
* testsuite/lib/binutils-common.exp (run_dump_test): Support
noxfail.
ld/
* testsuite/ld-elf/pr23658-1a.d: Don't xfail m68hc12.
* testsuite/ld-elf/pr23658-1e.d: Likewise. xfail xstormy16
and correct microblaze xfails.
Change the mmap support added with commit 9ba56acee5 to always mmap
memory with PROT_READ | PROT_WRITE. Prior to that commit most file
contents were read into a buffer allocated with bfd_alloc or
bfd_malloc and thus the memory was read/write. Even after that commit
any section contents with relocations must be read/write to apply the
relocs. Making them all read/write is not a major change, and it
should not introduce any measurable linker slowdown for contents that
are not modified. More importantly, it removes a BFD behaviour
difference that only triggers when large files are involved.
PR 32266
PR 32109
* libbfd.c (bfd_mmap_local): Remove prot param. Always mmap
with PROT_READ | PROT_WRITE. Adjust all calls.
(_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary.
(_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary.
_bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent.
(_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE
regardless of relocs.
* libbfd-in.h: Update decls to suit. Make non-USE_MMAP variants
static inline functions.
* elflink.c: Update all uses of _bfd_mmap functions.
* elf.c: Likewise.
(bfd_elf_get_str_section): Revert commit 656f8fbaae.
* libbfd.h: Regenerate.
In this patch, we will support AVX10.2 convert instructions. All
of them are new instruction forms.
Among all the instructions, vcvtbiasph2[b,h]f8[,s] needs extra care.
Since Operand 2 could indicate memory size, we do not need suffix
under ATTmode. However, we could not fold all three templates but only
XMM/YMM since the dst operand size are the same for them. Also, a new
iterator <cvt8> is added to reduce redundancy.
gas/
* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt-intel.d: New.
* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-512-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-512-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto.
opcodes/
* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F3874,
PREFIX_EVEX_MAP5_18, PREFIX_EVEX_MAP5_1B,
PREFIX_EVEX_MAP5_1E and PREFIX_EVEX_MAP5_74.
* i386-dis-evex.h: Add table pass for AVX10.2
instructions.
* i386-dis.c (MOD_EVEX_0F38B1): New.
(PREFIX_EVEX_0F3874): Ditto.
(PREFIX_EVEX_MAP5_18): Ditto.
(PREFIX_EVEX_MAP5_1B): Ditto.
(PREFIX_EVEX_MAP5_1E): Ditto.
(PREFIX_EVEX_MAP5_74): Ditto.
* i386-opc.tbl: Add AVX10.2 instructions.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Ditto.
Co-authored-by: Kong Lingling <lingling.kong@intel.com>
Co-authored-by: Haochen Jiang <haochen.jiang@intel.com>
While testing a modified GNAT, I found that this test in
fun_renaming.exp was returning 0 for GCC 13:
if {[test_compiler_info {gcc-6*}]}
This patch introduces a new, more robust way to check the GNAT
compiler version, and changes the gda.ada tests to use it. A small
update to version_compare was also needed.
Note that, in its current form, this new code won't really interact
well with non-GCC compilers (specifically gnat-llvm). This doesn't
seem like a major issue at this point, though, because gnat-llvm
doesn't properly emit debuginfo yet, and when it does, more changes
will be needed in these tests anyway.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Add relaxation support for call36 that jump to PLT entry.
Add relaxation support for call36 with IFUNC symbol.
Add relaxation support for call36 that jump to undefweak symbol.
For undefweak symbol, it can always be relaxed if it have no PLT entry.
Because we set the address of undefweak symbol without PLT entry to PC
like relocate_section.
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations
calls in update_breakpoint_locations", started checking if GDB correctly
relocates a breakpoint from inferior 1's declaration of the function
"bar" to inferior 2's declaration.
Unfortunately, inferior 2 never calls bar in its regular execution, and
because of that, clang would optimize that whole function away, making
it so there is no location for the breakpoint to be relocated to.
This commit changes the .c file so that the function is not optimized
away and the test fully passes with clang. It is important to actually
call bar instead of using __attribute__((used)) because the latter
causes the breakpoint locations to be inverted, 3.1 belongs to inferior
2 and 3.2 belongs to inferior 1, which will cause an unrelated failure.
Approved-By: Andrew Burgess <aburgess@redhat.com>
So far template expansion was limited to fields other than the insn
mnemonic. In order to be able to use <fop> also for AVX10.2 we want the
trailing mnemonic part to also be expanded. Split out the respective
piece of code into a helper function, which is then invoked twice.
Before this commit, the function frame_unwind_try_unwinder would return
an int, where 1 meant the unwinder works, and 0 it doesn't. This is just
a boolean with extra steps, so this commit updates the function to
return bool instead.
The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead
of the relocation in fixp. This can cause the second relocation
of a pair to be deleted when -mthin-add-sub is enabled. Apply the
correct macro to fix this.
Also sets the initial value of -mthin-add-sub.
gprofng does not handle DW_FORM_strx1* forms correctly.
gprofng/ChangeLog
2024-10-10 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR 32110
* src/DwarfLib.cc: Handle DW_FORM_strx* forms.
The last use of init_registers_arm_with_neon was removed in this
commit:
commit 7cc1743302
Date: Fri Jul 19 15:04:48 2019 +0100
Arm: Use read_description funcs in gdbserver
But the declaration was left around. Remove the declaration now.
This reverts commit 98bcde5e26. This
commit was causing build problems on at least sparc, ppc, and s390,
though I suspect some other targets might be impacted too.
While for executables properly aligning sections within the file can be
quite relevant, the same is of pretty little importance for relocatable
object files. Avoid passing "true" into
_bfd_elf_assign_file_position_for_section() when dealing with object
files, but compensate minimally by applying log_file_align in such
cases as a cap to the alignment put in place.
In disassembler part, for vnni instructions, we extended previous
VEX part using %XE in disassembler to promote them to EVEX by reusing
the original VEX table. For vmpsadbw, we will also use %XE. However,
it is hard to reuse the VEX table, so we are using new ones.
In assmbler part, we put the vnni table entries with previous vnni
instructions since they are just promotion from AVX-VNNI-INT{8,16}.
Since we will prefer VEX encoding, we need to use the different table
order in template <vnni>, which prefers EVEX due to earlier introduction
for AVX512_VNNI than AVX_VNNI. This means a new <vnni>. For vdpphps
and vmpsadbw, we put them at the end of the table, with future AVX10.2
instructions.
Nit: I will remove the arch requirement for avx_vnni_int{8,16} in
evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}.
gas/Changelog:
* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-256-1-intel.d: New.
* testsuite/gas/i386/avx10_2-256-1.d: Ditto.
* testsuite/gas/i386/avx10_2-256-1.s: Ditto.
* testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-512-1.d: Ditto.
* testsuite/gas/i386/avx10_2-512-1.s: Ditto.
* testsuite/gas/i386/avx10_2-promote.d: Ditto.
* testsuite/gas/i386/avx10_2-promote.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto.
opcodes/Changelog:
* i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852.
Add PREFIX_EVEX_0F3A42_W_0.
* i386-dis-evex-w.h: Adjust EVEX_W_0F3A42.
* i386-dis-evex.h: Add table pass for AVX10.2
instructions.
* i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0,
PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0.
* i386-opc.tbl: Add AVX10.2 instructions.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Ditto.
Co-authored-by: Lili Cui <lili.cui@intel.com>
On a Windows machine I built gdbserver, configured for the target
'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with
support for all target (--enable-targets=all).
On the Windows machine I start gdbserver with a small test binary:
$ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe
On the GNU/Linux machine I start GDB without the test binary, and
connect to gdbserver.
As I have not given GDB the test binary, my expectation is that GDB
would connect to gdbserver and then download the file over the remote
protocol, but instead I was presented with this message:
(gdb) target remote 192.168.129.25:54321
Remote debugging using 192.168.129.25:54321
warning: C:\some\directory\executable.exe: No such file or directory.
0x00007ffa3e1e1741 in ?? ()
(gdb)
What I found is that if I told GDB where to find the binary, like
this:
(gdb) file target:C:/some/directory/executable.exe
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading C:/some/directory/executable.exe from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading C:/some/directory/executable.exe from remote target...
Reading symbols from target:C:/some/directory/executable.exe...
(gdb)
then GDB would download the executable.
I eventually tracked the problem down to exec_file_find (solib.c).
The remote target was passing an absolute Windows filename (beginning
with "C:/" in this case), but in exec_file_find GDB was failing the
IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as
relative.
The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that
the file system kind was "unix", and as the filename didn't start with
a "/" it assumed the filename was not absolute.
But I'm connecting to a Windows target, my 'target-file-system-kind'
was set to "auto", so should be figuring out that my file-system is
"dos-based".
Looking in effective_target_file_system_kind (filesystem.c), we find
that the logic of "auto" is delegated to the current gdbarch. However
in windows-tdep.c we see:
set_gdbarch_has_dos_based_file_system (gdbarch, 1);
So if we are using a Windows gdbarch we should have "dos-based"
filesystems. What this means is that after connecting to the remote
target GDB has selected the wrong gdbarch.
What's happening is that the target description sent back by the
remote target only includes the x86-64 registers. There's no
information about which OS we're on. As a consequence, GDB picks the
first x86-64 gdbarch which can handle the provided register set, which
happens to be a GNU/Linux gdbarch.
And indeed, there doesn't appear to be anywhere in gdbserver that sets
the osabi on the target descriptions, though some target descriptions
do have their osabi set when the description is created, e.g. in:
gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate.
gdb/arch/i386.c - Likewise.
gdb/arch/tic6x.c - Always set GNU/Linux osabi.
Most target descriptions are created without an osabi, gdbserver does
nothing to fix this, and the description is returned to GDB without an
osabi included.
I propose that we always set the osabi name on the target descriptions
returned from gdbserver. We could try to do this when the description
is first created, but that would mean passing extra flags into the
tdesc creation code (or just passing the osabi string in), and I don't
think that's really necessary. If we consider the tdesc creation as
being about figuring out which registers are on the target, then it
makes sense that the osabi information is injected later.
So what I've done is require the osabi name to be passed to the
init_target_desc function. This is called, I believe, for all
targets, in the gdbserver code.
Now when I connect to the Windows remote the target description
returned includes the osabi name. With this extra information GDB
selects the correct gdbarch object, which means that GDB understands
the target has a "dos-based" file-system. With that correct GDB
understands that the filename it was given is absolute, and so fetches
the file from the remote as we'd like.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
There is a single declaration of set_tdesc_osabi that is shared
between gdbserver/ and gdb/, this declaration takes a 'const char *'
argument which is the string representing an osabi.
Then in gdb/ we have an overload of set_tdesc_osabi which takes an
'enum gdb_osabi'.
In this commit I change the shared set_tdesc_osabi to be the version
which takes an 'enum gdb_osabi', and I remove the version which takes
a 'const char *'. All users of set_tdesc_osabi are updated to pass an
'enum gdb_osabi'.
The features/ code, which is generated from the xml files, requires a
new function to be added to osabi.{c,h} which can return a string
representation of an 'enum gdb_osabi'. With that new function in
place the features/ code is regenerated.
This change is being made to support the next commit. In the next
commit gdbserver will be updated to call set_tdesc_osabi in more
cases. The problem is that gdbserver stores the osabi as a string.
The issue here is that a typo in the gdbserver/ code might go
unnoticed and result in gdbserver sending back an invalid osabi
string.
To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
set_tdesc_osabi function. With that requirement in place it seems to
make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.
There should be no user visible changes after this commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In future commits I want to call set_tdesc_osabi from gdbserver/
code. Currently the only version of set_tdesc_osabi available to
gdbserver takes a string representing the osabi.
The problem with this is that, having lots of calls to set_tdesc_osabi
which all take a string is an invite for a typo to slip in. This typo
could potentially go unnoticed until someone tries to debug the wrong
combination of GDB and gdbserver, at which point GDB will fail to find
the correct gdbarch because it doesn't understand the osabi string.
It would be better if the set_tdesc_osabi calls in gdbserver could
take an 'enum gdb_osabi' value and then convert this to the "correct"
string internally. In this way we are guaranteed to always have a
valid, known, osabi string.
This commit splits the osabi related code, which currently lives
entirely on the GDB side, between gdb/ and gdbsupport/. I've moved
the enum definition along with the array of osabi names into
gdbsupport/. Then all the functions that access the names list, and
which convert between names and enum values are also moved.
I've taken the opportunity of this move to add a '.def' file which
contains all the enum names along with the name strings. This '.def'
file is then used to create 'enum gdb_osabi' as well as the array of
osabi name strings. By using a '.def' file we know that the enum
order will always match the name string array.
This commit is just a refactor, there are no user visible changes
after this commit. This commit doesn't change how gdbserver sets the
target description osabi string, that will come in the next commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
There are two versions of the set_tdesc_osabi function in GDB:
void
set_tdesc_osabi (struct target_desc *target_desc, const char *name)
{
set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name));
}
void
set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi)
{
target_desc->osabi = osabi;
}
In the gdb/features/ files we call the second of these functions, like
this:
set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux"));
This can be replaced with a call to the first set_tdesc_osabi
function, so lets do that. I think that this makes the features/ code
slightly simpler and easier to understand.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Convert target_desc::arch and target_desc::osabi from 'const char*' to
gdb::unique_xmalloc_ptr<char>. This also allows us to remove the user
defined ~target_desc destructor.
I doubt it ever actually occurred, but in theory at least, there was a
memory leak in set_tdesc_architecture and set_tdesc_osabi where the
member variables were assigned without freeing any previous
value... but I suspect that usually these fields are only set once.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
...
(gdb) awatch a^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
rwatch b^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: continue until exit
...
Using "maint info break", we can see that the two failed attempts to set a
watchpoint each left behind a stale "watchpoint scope" breakpoint:
...
-5 watchpoint scope del y 0xf7ec569a inf 1
-5.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
-6 watchpoint scope del y 0xf7ec569a inf 1
-6.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
...
The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
same happens if we:
- have can-use-hw-watchpoints == 1,
- set one of the watchpoints, and
- continue to exit.
The problem is missing symbol info on libc which is supposed to tell which
code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV
disappears.
Extend the test-case to check the "maint info break" command before and after
the two failed attempts, to make sure that we catch the stale
"watchpoint scope" breakpoints also on x86_64-linux.
Fix this in watch_command_1 by moving creation of the "watchpoint scope"
breakpoint after the call to update_watchpoint.
Tested on x86_64-linux.
PR breakpoints/31860
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tested on aarch64-linux.
Reported-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
