The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC. The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.
The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.
The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:
Expecting: ^(-var-update A_String_Access[
]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
]+[(]gdb[)]
[ ]*)
-var-update A_String_Access
^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
(gdb)
FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)
The patch adds a second possible result string for the test
$re_varobj_update_result_type to match the case when type_changed is true.
Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
is true on PowerPC and false on X86-64.
Fixes 2 failures on PowerPC.
Approved-By: Tom Tromey <tom@tromey.com>
GDB's Python documentation claims that range types have two fields,
but this is not true, and attempts to access them hit this error:
"Type is not a structure, union, enum, or function type."
This patch fixes the documentation.
While working on a GNAT bug, I wanted to also test
arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is
ready, I plan to add a new case here.
Tested on x86-64 Fedora 36. I am checking this in.
Before actual vlen handling, fix the riscv_gdbarch_features hashing
function based on the actual valid range of vlen. In bytes, vlen is 0,
or 4 <= xlen <= 8192.
Before actual vlen handling, this commit fixes its description to allow vlen
less than 16 (but 4 or greater), to support vector subset extensions for
embedded environment ('Zve32*').
This fixes the compilation warnings introduced by my bfdio.c patch.
The removed bfd_seeks in coff_symfile_read date back to 1994, commit
7f4c859520, prior to which the file used stdio rather than bfd to read
symbols. Since it now uses bfd to read the file there should be no
need to synchronise to bfd's idea of the file position. I also fixed
a potential uninitialised memory access.
Approved-By: Andrew Burgess <aburgess@redhat.com>
In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same.
This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result.
It's not documented anyway, and having it makes no sense anymore with
obj_elf_section_word() now being TC_SPARC-only. In any event the x86
backing function was dead code.
The table constantly growing in two dimensions (number of table entries
times number of ISA extension flags) doesn't scale very well. Use a more
compact representation: Only identifiers which need to combine with
other identifiers retain individual flag bits. All others are combined
into an enum, with a new helper added to transform the table entries
into the original i386_cpu_flags layout. This way the table in the final
binary shrinks by almost a third (the generated source code shrinks by
about half), and isn't likely to grow again in that dimension any time
soon.
While moving the 3DNow! fields, drop the stray inner 'a' from their
names.
Their check_func should be "match_never", not "match_opcode". The reasons
this error did not cause any disassembler errors are:
1. The problem will not reproduce if "no-aliases" is specified
(because macro instructions are handled as aliases).
2. If not, all affected compressed instructions or their aliases
precede before "vmsge{,u}.vx" macro instructions.
However, it'll easily break if we reorder opcode entries. This commit
fixes this issue before the *accident* occurs.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Make sure that we never match to
vmsge{,u}.vx instructions unless specified in the assembler.
Since this "extension" does not exist (on the other hand, 'Zve64d' exists)
and it's not useful if we keep it (as other code portions just ignore
"zve32d"), this commit just removes it.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d'
extension from the list.
Test-case gdb.dwarf2/pr13961.exp contains:
...
<1><25>: Abbrev Number: 8 (DW_TAG_class_type)
<26> DW_AT_specification: <0x2a>
<1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
<2b> DW_AT_name : foo
<2f> DW_AT_byte_size : 4
<30> DW_AT_decl_file : 1
<31> DW_AT_decl_line : 1
<32> DW_AT_sibling : <0x44>
...
The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
DIE indexing in the cooked_index, by adding it to m_deferred_entries.
The resulting cooked index entries are:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x333b630)
name: foo
canonical: foo
qualified: foo::foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x333b5d0) [foo]
...
Notice that 0x2a is the parent of 0x25, and that this is why the qualified
name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".
The parent is set here in cooked_indexer::make_index:
...
for (const auto &entry : m_deferred_entries)
{
void *obj = m_die_range_map.find (entry.spec_offset);
cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
entry.name, parent, m_per_cu);
}
...
and AFAICT, we store in m_die_range_map the parent of the respective
spec_offset DIE (though that's not clear from the comment describing it).
So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
m_die_range_map.find (0x2a) == 0x2a.
This is an off-by-one error, fixed in cooked_indexer::recurse by:
...
- CORE_ADDR start = form_addr (parent_entry->die_offset,
+ CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
...
which gives us:
...
[12] ((cooked_index_entry *) 0x41e21f0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0)
[13] ((cooked_index_entry *) 0x41e2190)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30739
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739
When doing "maint print objfiles" for the exec of test-case
gdb.dwarf2/pr13961.exp, we get:
...
[25] ((cooked_index_entry *) 0x37b25d0)
name: foo
canonical: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x37b2630)
name: foo
canonical: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x37b25d0) [foo]
...
By following the parent links in the text, we can conclude that the qualified
name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).
But it's not evident, and also hard to verify in a test-case.
Add dumping of the qualified name, such that we have:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x333b630)
name: foo
canonical: foo
qualified: foo::foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x333b5d0) [foo]
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
The frame command on Power pc prints the address in hex between the
#0 and in calle.increment. For example
(gdb) frame
#0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19 procedure Increment (Val : in out Float; Msg: String) is
The printing of the address for the frame is done by function
print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame,
function frame_show_address returns true and print_frame prints the
address. Currently, SAL.IS is false on PowerPC and true on X86-64.
Update the set re string to accept the hex address if it exits.
Fixes two failures on PowerPC.
Patch tested on Power10 with no new regressions.
Approved-By: Tom Tromey <tom@tromey.com>
gdbserver does not notify gdb of new threads when they are created.
I'm not sure if this is documented anywhere, but it is mentioned on
this page:
https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
Search for "Finding new threads in the inferior".
This behavior is a bit unfortunate -- I would think that it would be
better to arrange for such notification if something on the gdb side
is interested.
Meanwhile, this patch fixes py-thread-exited.exp to work around this
problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677
This changes add_thread_with_info to accept a unique_ptr, making it
clear that it takes ownership of the passed-in pointer.
I can't test the AIX or Darwin changes, but I think they are
relatively obvious.
This patch adds support for the Cortex-A520 CPU to gas.
No regressions on aarch64-none-elf.
gas/ChangeLog:
* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A520.
* doc/c-aarch64.texi: Update docs.
When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-gnu-debuglink, I run into:
...
(gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
maint print symbols -objfile enqueued-cu-base-addr^M
(gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The problem is that the CU we're trying to print is in objfile
enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.
Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".
Tested on x86_64-linux.
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-debug-names, and ran into:
...
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The first FAIL is a known issue, PR symtab/29572.
The following FAIL is a consequence of the first FAIL, so require for the
second test that the first test passes.
Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
When running test-case gdb.dwarf2/pr13961.exp with target-board
cc-with-debug-names, I run into:
...
Running gdb.dwarf2/pr13961.exp ...
gdb compile failed, gdb/dwarf2/index-write.c:1305: internal-error: \
write_debug_names: Assertion `counter == per_bfd->all_units.size ()' failed.
...
This is a regression since commit 542a33e348 ("Only use the per-BFD object to
write a DWARF index"), which did:
...
- gdb_assert (counter == per_objfile->per_bfd->all_comp_units.size ());
+ gdb_assert (counter == per_bfd->all_units.size ());
...
Fix this by reverting to using all_comp_units:
...
gdb_assert (counter == per_bfd->all_comp_units.size ());
...
Tested on x86_64-linux, using target boards unix and cc-with-debug-names.
PR symtab/30741
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30741
The 32-bit non-fetching atomic instructions treat the source register as
32-bits, which means in the pseudo-c syntax the "w" registers should be
used rather than the "r" registers.
opcodes/
* bpf-opc-c (bpf_opcodes): Use %sw for AAD32, AOR32, AAND32
and AXOR32 pseudo-c dialect asm templates.
gas/
* testsuite/gas/bpf/atomic-be-pseudoc.d: Use "w" for source reg
in non-fetching 32-bit atomic instructions.
* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
Add new commands:
set debug breakpoint on|off
show debug breakpoint
This patch introduces new debugging information that prints
breakpoint location insertion and removal flow.
The debug output looks like:
~~~
(gdb) set debug breakpoint on
(gdb) disassemble main
Dump of assembler code for function main:
0x0000555555555129 <+0>: endbr64
0x000055555555512d <+4>: push %rbp
0x000055555555512e <+5>: mov %rsp,%rbp
=> 0x0000555555555131 <+8>: mov $0x0,%eax
0x0000555555555136 <+13>: pop %rbp
0x0000555555555137 <+14>: ret
End of assembler dump.
(gdb) break *0x0000555555555137
Breakpoint 2 at 0x555555555137: file main.c, line 4.
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
(gdb) c
Continuing.
[breakpoint] update_global_location_list: insert_mode = UGLL_INSERT
[breakpoint] insert_bp_location: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4
[breakpoint] insert_bp_location: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5
[breakpoint] insert_bp_location: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e
[breakpoint] insert_bp_location: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4
[breakpoint] remove_breakpoint_1: Breakpoint 2 (0x5565daddb1e0) at address 0x555555555137 in main at main.c:4 due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -2 (0x5565dab51c10) at address 0x7ffff7fd37b5 due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -5 (0x5565dab68f30) at address 0x7ffff7fe509e due to regular remove
[breakpoint] remove_breakpoint_1: Breakpoint -7 (0x5565dab694f0) at address 0x7ffff7fe63f4 due to regular remove
Breakpoint 2, 0x0000555555555137 in main () at main.c:4
4 }
~~~
Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
These were renamed from bfd_read and bfd_write back in 2001 when they
lost an unnecessary parameter. Rename them back, and get rid of a few
casts that are only needed without prototyped functions (K&R C).
According to the reporter of this bug the newlib fseek implementation
is likely slowed down by locking and fflush, only attempting to
optimise seeks when the file is opened read-only. Thus when writing
the output we get a dramatic slowdown due to commit 014a602b86.
PR 30724
* bfd.c (enum bfd_last_io): New.
(struct bfd): Add last_io field.
* bfd-in2.h: Regenerate.
* bfd-io.c (bfd_bread, bfd_bwrite): Force seek if last_io is
opposite direction.
(bfd_seek): Reinstate optimisation for seek to same position.
Use move capture in gdb_demangle when compiling for c++14 or higher, to save a
std::string copy.
Tested on x86_64-linux.
Reported-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR 30733
* ld/testsuite/ld-elf/retain7a.d: Fix XFAIL entry for hppa to match
hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.
Signed-off-by: Sam James <sam@gentoo.org>
PR 30734
* ld/testsuite/ld-elf/relocatable.d: Fix notarget entry for hppa to match
hppa{1.1,2.0}*, like hppa2.0-unknown-linux-gnu which Gentoo uses.
Signed-off-by: Sam James <sam@gentoo.org>
When testing current gdb trunk on Solaris/amd64, the whole session was
reliably terminated by make check. I could trace this to the following
entry in gdb.arch/amd64-disp-step/gdb.log:
FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get
inferior pid
Executing on target: kill -ALRM -1 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -ALRM -1
If $inferior_pid doesn't refer to a single process for some reason, this
kill would terminate either a process group or the whole session.
This patch avoids this by ensuring that the pid arg is positive.
Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
When building with -std=c++11 I run into:
...
gdb/dwarf2/cooked-index.c: In member function \
‘void cooked_index::start_writing_index(dwarf2_per_bfd*)’:
gdb/dwarf2/cooked-index.c:469:10: error: lambda capture initializers only \
available with -std=c++14 or -std=gnu++14 [-Werror]
ctx = std::move (ctx)] ()
^~~
...
Fix this by capturing a copy instead when using -std=c++11:
...
= gdb::thread_pool::g_thread_pool->post_task ([this, per_bfd, ctx] ()
...
Tested by building with and without -stdc=++11 on x86_64-linux.
Reported-By: Tom Tromey <tom@tromey.com>
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Because the 'Ztso' extension is now ratified, it has a version number of 1.0
(not 0.1). This commit updates the number.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
number of the 'Ztso' extension since it's ratified.
It makes little sense to have this comment meanwhile over a hundred
lines ahead of the array. In fact until spotting the comment, I was
wondering why those pretty important aspects aren't spelled out
anywhere.
Fortran allows variables and function to be named after language defined
intrinsics as they are not reserved keywords. For example, the abs maths
intrinsic can be hidden by a user declaring a variable called abs.
The behavior before this patch was to favour the intrinsic, which meant
that any variables named, for example "allocated", could not be
inspected by GDB.
This patch inverts this priority to bring GDB's behaviour closer to the
Fortran language, where the user defined symbol can hide the intrinsic.
Special care was need to prevent any C symbols from overriding either
Fortran intrinsics or user defined variables. This was observed to be
the case when GDB has access to symbols for abs from libm. This was
solved by only allowing symbols not marked with language_fortran to be
overridden.
In total this brings the order of precedence to the following (highest
first):
1. User defined Fortran variable or function.
2. Fortran intrinsic.
3. Symbols from languages other than Fortran.
The sizeof intrinsic is now case insensitive. This is closer to the
Fortran language. I believe this change is safe enough as it increases
the acceptance of the grammar, rather than restricts it. I.e. it should
not break any existing scripts which rely on it. Unless of course they
rely on SIZEOF being rejected.
GDB built with GCC 13.
No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
LLVM, NVHPC; Platforms: x86_64, aarch64.
Existing tests in gdb.fortran cover the invocation of intrinsics
including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp.
Approved-By: Tom Tromey <tom@tromey.com>
When loading an executable using "file a.out", the language is set according
to a.out, which can involve looking up the language of symbol "main", which
will cause the symtab expansion for the containing CU.
Expansion of lto debug info can be slow, so in commit d321419811 ("[gdb] Use
partial symbol table to find language for main") a feature was added to avoid
the symtab expansion.
This feature stopped working after commit 7f4307436fd ("Fix "start" for D,
Rust, etc").
[ The commit addresses problems related to command start, which requires finding
the main function:
- for language D, "main" was found instead of "D main", and
- for Rust, the correct function was found, but attributed the wrong name
(not fully qualified). ]
Reimplement the feature by adding
cooked_index_functions::lookup_global_symbol_language.
Tested on x86_64-linux.
PR symtab/30661
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661
I noticed that some spots in gdb call bfd_set_cacheable after opening
a BFD.
The BFD file cache is a bit odd. BFDs that are opened locally are
unconditionally registered with the cache, and their underlying file
descriptor will always be closed when bfd_cache_close_all is called.
However, only "cacheable" BFDs will be eligible for reopening when
needed -- and by default BFD decides that if a file descriptor is
passed in, then it should not be cacheable. If a non-cacheable BFD's
file descriptor is closed, there is no offical way to reopen it.
gdb needs to call bfd_cache_close_all, because some systems cannot
start an executable when it has an open file descriptor referencing
it.
However, gdb also will sometimes passes an open file descriptor to the
various BFD open functions. And, due to lazy DWARF reading, gdb may
also need to reopen these BFDs.
Rather than having all the callers figure out when exactly to set the
cacheable flag, I think it makes sense to consolidate this logic into
the gdb_bfd.c wrapper functions. It is ok to do this because gdb
always passes a filename to these open functions, so reopening should
work ok.
Regression tested on x86-64 Fedora 38.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
A local gdb test failed with this error message:
Remote communication error. Target disconnected.: Arg list too long.
The ".:" seemed weird to me. This patch removes the ".".
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
GDB Administrator
Carl Love
Tom Tromey
Tsukasa OI
Alan Modra
Aditya Vidyadhar Kamath
Jan Beulich
Tom de Vries
Tom Tromey
Richard Ball
David Faust
Mihails Strasuns
Sam James
Guinevere Larsen
Rainer Orth
Vladimir Mezentsev
Richard Bunt
David Carew