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)
Carl Love [Thu, 3 Aug 2023 17:55:51 +0000 (13:55 -0400)]
Fix gdb.ada/O2_float_param.exp for PowerPC
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.
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.
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/enqueued-cu-base-addr.exp with cc-with-gnu-debuglink
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".
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/testsuite] Improve failure mode in gdb.dwarf2/enqueued-cu-base-addr.exp
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.
Tom de Vries [Thu, 10 Aug 2023 13:46:30 +0000 (15:46 +0200)]
[gdb/symtab] Fix assertion in write_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 542a33e348a ("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.
David Faust [Wed, 9 Aug 2023 18:44:38 +0000 (11:44 -0700)]
bpf: use w regs in 32-bit non-fetch atomic pseudo-c
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.
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>
Alan Modra [Mon, 7 Aug 2023 05:10:35 +0000 (14:40 +0930)]
Rename bfd_bread and bfd_bwrite
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).
Alan Modra [Sun, 6 Aug 2023 22:58:55 +0000 (08:28 +0930)]
PR30724, cygwin ld performance regression since 014a602b86
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.
Rainer Orth [Tue, 8 Aug 2023 08:13:58 +0000 (10:13 +0200)]
Guard against killing unrelated processes in amd64-disp-step.exp
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>
Tom de Vries [Tue, 8 Aug 2023 08:08:04 +0000 (10:08 +0200)]
[gdb/build] Fix build breaker with -std=c++11
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>
Jan Beulich [Mon, 7 Aug 2023 09:56:50 +0000 (11:56 +0200)]
RISC-V: move comment describing rules for riscv_opcodes[]
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.
Richard Bunt [Mon, 7 Aug 2023 08:12:53 +0000 (09:12 +0100)]
gdb/fortran: Align intrinsic/variable precedence
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.
Tom de Vries [Sat, 5 Aug 2023 15:57:13 +0000 (17:57 +0200)]
[gdb/symtab] Find main language without symtab expansion
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 d3214198119 ("[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.
Tom Tromey [Fri, 4 Aug 2023 11:58:35 +0000 (05:58 -0600)]
Consolidate calls to bfd_set_cacheable
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.
Nick Clifton [Fri, 4 Aug 2023 13:19:28 +0000 (14:19 +0100)]
Fix potential infinite loop in bfd_cache_close_all.
PR 15545 * cache.c (bfd_cache_close_all): Extend description to note that all files will be closed, even those that are not cacheable. Add code to prevent a possible infinite loop.
The race happens when issuing the "file $exec" command.
The race is between:
- a worker thread writing the index cache, and in the process reading
dwarf2_per_cu_data::is_debug_type, and
- the main thread writing to dwarf2_per_cu_data::files_read.
The two bitfields dwarf2_per_cu_data::files_read and
dwarf2_per_cu_data::is_debug_type share the same bitfield container.
Fix this by making dwarf2_per_cu_data::files_read a packed<bool, 1>.
The race happens when issuing the "file $exec" command.
The race is between:
- a worker thread writing the index cache, and in the process reading
dwarf2_per_cu_data::is_debug_type, and
- the main thread writing to dwarf2_per_cu_data::mark.
The two bitfields dwarf2_per_cu_data::mark and
dwarf2_per_cu_data::is_debug_type share the same bitfield container.
Fix this by making dwarf2_per_cu_data::mark a packed<unsigned int, 1>.
Tom de Vries [Fri, 4 Aug 2023 13:02:43 +0000 (15:02 +0200)]
[gdb/testsuite] Extend gdb.base/index-cache.exp
The test-case gdb.base/index-cache.exp uses only one source file, which
contains main.
While doing "file $exec", in set_initial_language a symbol lookup of "main" is
done, causing the symtab containing main to be expanded.
Handling of main is special, and a future optimization may skip the lookup and
expansion.
Reliably exercise:
- the lookup of main, expanding the symtab containing main, by doing
"ptype main", and
- the lookup of another symbol, expanding a symtab not containing main, by:
- adding another source file containing function foo, and
- doing "ptype foo".
This triggered a segfault with target board native-extended-gdbserver, filed
as PR symtab/30712, but that seems to be fixed by a previous commit in this
series.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30712
The race happens when issuing the "file $exec" command.
The race is between:
- a worker thread writing the index cache, and in the process reading
dwarf2_per_cu_data::is_debug_type, and
- the main thread writing to dwarf2_per_cu_data::m_header_read_in.
The two bitfields dwarf2_per_cu_data::m_header_read_in and
dwarf2_per_cu_data::is_debug_type share the same bitfield container.
Fix this by making dwarf2_per_cu_data::m_header_read_in a packed<bool, 1>.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30392
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
The race happens when issuing the "file $exec" command.
The race is between:
- a worker thread writing the index cache, and in the process reading
dwarf2_per_cu_data::is_debug_type, and
- the main thread expanding the CU containing main, and in the process setting
dwarf2_per_cu_data::queued.
The two bitfields dwarf2_per_cu_data::queue and
dwarf2_per_cu_data::is_debug_type share the same bitfield container.
Fix this by making dwarf2_per_cu_data::queued a packed<bool, 1>.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30392
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
The race happens when issuing the "file $exec" command.
The race is between:
- a worker thread getting the build id while writing the index cache, and in
the process reading bfd::format, and
- the main thread calling find_main_name, and in the process setting
bfd::cacheable.
The two bitfields bfd::cacheable and bfd::format share the same bitfield
container.
Fix this by capturing the build id in the main thread, and using the captured
value in the worker thread.
Likewise for the dwz build id, which likely suffers from the same issue.
While we're at it, also move the creation of the cache directory to
the index_cache_store_context constructor, to:
- make sure there's no race between subsequent file commands, and
- issue any related warning or error messages during the file command.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30392
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30392
Location is global 'global_index_cache' of size 48 at 0x00000321f520 (gdb+0x00000321f540)
...
SUMMARY: ThreadSanitizer: data race gdb/dwarf2/index-cache.c:76 in index_cache::enable()
...
The race happens when issuing a "file $exec" command followed by a
"set index-cache enabled on" command.
The race is between:
- a worker thread reading index_cache::m_enabled to determine whether an
index-cache entry for $exec needs to be written
(due to command "file $exec"), and
- the main thread setting index_cache::m_enabled
(due to command "set index-cache enabled on").
Fix this by capturing the value of index_cache::m_enabled in the main thread,
and using the captured value in the worker thread.
Alan Modra [Fri, 4 Aug 2023 08:07:12 +0000 (17:37 +0930)]
ppc: sanity check writing relocs
Check for output buffer overruns.
* elf32-ppc.c (swap_reloc_out, count_and_swap_reloc_out): New
functions. Use throughout file.
* elf64-ppc.c (swap_reloc_out, count_and_swap_reloc_out): Likewise.
Alan Modra [Fri, 4 Aug 2023 05:39:53 +0000 (15:09 +0930)]
PR30697, ppc32 mix of local-dynamic and global-dynamic TLS
This fixes miscounting of dynamic relocations on GOT entries when
a) there are both local-dynamic and global-dynamic tls accesss for a
given symbol, and
b) the symbol is global with non-default visibility, and
c) the __tls_get_addr calls aren't optimised away.
PR 30697
bfd/
* elf32-ppc.c (allocate_dynrelocs): Correct local-dynamic
reloc count.
ld/
* testsuite/ld-powerpc/tls32ldgd.d,
* testsuite/ld-powerpc/tls32ldgd.s: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.
Bruno Larsen [Fri, 14 Jul 2023 08:06:03 +0000 (10:06 +0200)]
gdb/testsuite: Disable gdb.compile when testing with clang
Attempting to test the gdb.compile with clang as the compiler results in
over 300 unexpected errors, due to a segmentation fault and several
handshake failures. Since the whole feature is designed around a gcc
plugin, and even the gcc testing is shaky at best, this commit restricts
those tests to only running under gcc. If that gets fixed, this commit
can be reverted.
Tom de Vries [Thu, 3 Aug 2023 16:35:23 +0000 (18:35 +0200)]
[gdb/symtab] Remove superfluous handling of Ada main in write_cooked_index
I filed PR29179 about the following FAIL in test-case
gdb.ada/O2_float_param.exp with target board cc-with-gdb-index:
...
(gdb) break increment^M
Function "increment" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: gdb_breakpoint: \
set breakpoint at increment
...
The FAIL was a regression since commit 2cf349be0e3 ("Do not put linkage names
into .gdb_index").
Before that commit we had:
...
$ readelf -w foo > READELF
$ grep callee.*increment READELF
[1568] callee__increment: 5 [global, function]
[3115] callee.increment: 5 [global, function]
...
but after only:
...
$ grep callee.*increment READELF
[3115] callee.increment: 5 [global, function]
...
The regression was fixed by commit 67e83a0deef ("Fix regression in
c-linkage-name.exp with gdb index"), which got us again:
...
$ grep callee.*increment READELF
[1568] callee__increment: 5 [global, function]
[3115] callee.increment: 5 [global, function]
...
The commit however did not claim that particular PR. A subsequent commit,
commit 5fea9794325 ("Improve Ada support in .gdb_index") did claim to fix it,
together with commit dd05fc7071a ("Change .gdb_index de-duplication
implementation").
The commit 5fea9794325 contained the following addition in write_cooked_index:
...
+ if (entry->per_cu->lang () == language_ada)
+ {
+ /* We want to ensure that the Ada main function's name
+ appears verbatim in the index. However, this name will
+ be of the form "_ada_mumble", and will be rewritten by
+ ada_decode. So, recognize it specially here and add it
+ to the index by hand. */
+ if (entry->tag == DW_TAG_subprogram
+ && strcmp (main_for_ada, name) == 0)
+ {
+ /* Leave it alone. */
+ }
+ else
+ {
+ /* In order for the index to work when read back into
+ gdb, it has to use the encoded name, with any
+ suffixes stripped. */
+ std::string encoded = ada_encode (name, false);
+ name = obstack_strdup (&symtab->m_string_obstack,
+ encoded.c_str ());
+ }
+ }
...
The code contains some special handling related to the Ada main function, so
let's look at that one: foo. Before commit 67e83a0deef we have:
...
$ grep foo.*function READELF
[3733] foo: 7 [global, function]
...
and after:
...
$ grep foo.*function READELF
[2738] _ada_foo: 7 [global, function]
[3733] foo: 7 [global, function]
...
so that looks identical to the callee.increment case.
At commit 5fea9794325, we have slightly different index numbers:
...
$ grep foo.*function READELF
[1658] foo: 7 [global, function]
[2738] _ada_foo: 7 [global, function]
...
but otherwise the same result.
If we disable the special handling of the Ada main function like so:
...
- if (entry->tag == DW_TAG_subprogram
+ if (false && entry->tag == DW_TAG_subprogram
...
we still have the exact same result because:
...
(gdb) p main_for_ada
$1 = 0x352e6a0 "_ada_foo"
...
and ada_encode ("_ada_foo", false) == "_ada_foo".
The comment seems to be copied from debug_names::insert, which does indeed use
ada_decode, while the code in write_cooked_index uses ada_encode instead.
Remove the superfluous special handling of Ada main in write_cooked_index.
Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.
This can be seen currently in the logs of the bt-nodebug.exp test
case.
What is happening is that FrameDecorator falls back on returning the
PC when the frame's function symbol cannot be found, relying on the
gdb core to look up the minsym and print its name.
This can actually yield the wrong answer sometimes, because it falls
into the get_frame_pc / get_frame_address_in_block problem -- if the
frame is at a call to a noreturn function, the PC in this case might
appear to be in the next function in memory. For more on this, see:
However, there's a different approach we can take: the code here can
simply use Frame.name. This handles the PC problem correctly, and
gets us the information we need.
gdb: don't always print breakpoint location after failed condition check
and is a result of feedback received here[1].
The original commit addressed a problem where, if a breakpoint
condition included an inferior function call, and if the inferior
function call failed, then GDB would announce the stop twice. Here's
an example of GDB's output before the above commit that shows the
problem being addressed:
(gdb) break foo if (some_func ())
Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
(gdb) r
Starting program: /tmp/bpcond
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in some_func () at bpcond.c:5
5 return *p;
Error in testing condition for breakpoint 1:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(some_func) will be abandoned.
When the function is done executing, GDB will silently stop.
Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
5 return *p;
(gdb)
The original commit addressed this issue in breakpoint.c, by spotting
that the $pc had changed while evaluating the breakpoint condition,
and inferring from this that GDB must have stopped elsewhere.
However, the way in which the original commit suppressed the second
stop announcement was to set bpstat::print to true -- this tells GDB
not to print the frame during the stop announcement, and for the CLI
this is fine, however, it was pointed out that for the MI this still
isn't really enough. Below is an example from an MI session after the
above commit was applied, this shows the problem with the above
commit:
-break-insert -c "cond_fail()" foo
^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="0",original-location="foo"}
(gdb)
-exec-run
=thread-group-started,id="i1",pid="2636270"
=thread-created,id="1",group-id="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7fd3110",to="0x00007ffff7ff2bb4"}]
^running
*running,thread-id="all"
(gdb)
=library-loaded,id="/lib64/libm.so.6",target-name="/lib64/libm.so.6",host-name="/lib64/libm.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7e59390",to="0x00007ffff7ef4f98"}]
=library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ca66b0",to="0x00007ffff7df3c5f"}]
~"\nProgram"
~" received signal SIGSEGV, Segmentation fault.\n"
~"0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24\n"
~"24\t return *p;\t\t\t/* Crash here. */\n"
*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x0000000000401116",func="cond_fail",args=[],file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="24",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="9"
&"Error in testing condition for breakpoint 1:\n"
&"The program being debugged was signaled while in a function called from GDB.\n"
&"GDB remains in the frame where the signal was received.\n"
&"To change this behavior use \"set unwindonsignal on\".\n"
&"Evaluation of the expression containing the function\n"
&"(cond_fail) will be abandoned.\n"
&"When the function is done executing, GDB will silently stop.\n"
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000040111e",func="foo",file="/tmp/mi-condbreak-fail.c",fullname="/tmp/mi-condbreak-fail.c",line="30",thread-groups=["i1"],cond="cond_fail()",times="1",original-location="foo"}
*stopped
(gdb)
Notice that we still see two '*stopped' lines, the first includes the
full frame information, while the second has no frame information,
this is a result of bpstat::print having been set. Ideally, the
second '*stopped' line should not be present.
By setting bpstat::print I was addressing the problem too late, this
flag really only changes how interp::on_normal_stop prints the stop
event, and interp::on_normal_stop is called (indirectly) from the
normal_stop function in infrun.c. A better solution is to avoid
calling normal_stop at all for the stops which should not be reported
to the user, and this is what I do in this commit.
This commit has 3 parts:
1. In breakpoint.c, revert the above commit,
2. In fetch_inferior_event (infrun.c), capture the stop-id before
calling handle_inferior_event. If, after calling
handle_inferior_event, the stop-id has changed, then this indicates
that somewhere within handle_inferior_event, a stop was announced to
the user. If this is the case then GDB should not call normal_stop,
and we should rely on whoever announced the stop to ensure that we
are in a PROMPT_NEEDED state, which means the prompt will be
displayed once fetch_inferior_event returns. And,
3. In infcall.c, do two things:
(a) In run_inferior_call, after making the inferior call, ensure
that either async_disable_stdin or async_enable_stdin is called
to put the prompt state, and stdin handling into the correct
state based on whether the inferior call completed successfully
or not, and
(b) In call_thread_fsm::should_stop, call async_enable_stdin
rather than changing the prompt state directly. This isn't
strictly necessary, but helped me understand this code more.
This async_enable_stdin call is only reached if normal_stop is
not going to be called, and replaces the async_enable_stdin call
that exists in normal_stop. Though we could just adjust the
prompt state if felt (to me) much easier to understand when I
could see this call and the corresponding call in normal_stop.
With these changes in place now, when the inferior call (from the
breakpoint condition) fails, infcall.c leaves the prompt state as
PROMPT_NEEDED, and leaves stdin registered with the event loop.
Back in fetch_inferior_event GDB notices that the stop-id has changed
and so avoids calling normal_stop.
And on return from fetch_inferior_event GDB will display the prompt
and handle input from stdin.
As normal_stop is not called the MI problem is solved, and the test
added in the earlier mentioned commit still passes just fine, so the
CLI has not regressed.
Tom Tromey [Sun, 30 Jul 2023 16:26:07 +0000 (10:26 -0600)]
Remove PEI_HEADERS define
I noticed a few files double-included libcoff.h, and digging deeper I
found that the PEI_HEADERS define is a sort of external include guard.
This patch adds include guards to the few files in include/coff that
were missing one, and then removes the PEI_HEADERS workaround and the
redundant includes.
I didn't see anything in these files that indicated that
double-inclusion would be useful, so it seems to me that this approach
is ok.
Tested by rebuilding with --enable-targets=all.
2023-08-02 Tom Tromey <tromey@adacore.com>
* pei-x86_64.c (PEI_HEADERS): Do not define.
* pei-loongarch64.c (PEI_HEADERS): Do not define.
* pei-aarch64.c (PEI_HEADERS): Do not define.
* pe-x86_64.c (PEI_HEADERS): Do not define.
* pe-aarch64.c (PEI_HEADERS): Do not define.
* libpei.h (_LIBPEI_H): Add include guard.
* coff-x86_64.c (PEI_HEADERS): Do not check.
* coff-loongarch64.c (PEI_HEADERS): Do not check.
* coff-aarch64.c (PEI_HEADERS): Do not check.
include/ChangeLog
2023-08-02 Tom Tromey <tromey@adacore.com>
* coff/x86_64.h (COFF_X86_64_H): Add include guard.
* coff/loongarch64.h (COFF_LOONGARCH64_H): Add include guard.
* coff/aarch64.h (COFF_AARCH64_H): Add include guard.
Alan Modra [Wed, 2 Aug 2023 01:57:27 +0000 (11:27 +0930)]
readelf sprintf optimisation
This replaces sprintf and strcat calls with stpcpy, and makes use of
sprintf return value rather than using strlen, for get_machine_flags.
decode_NDS32_machine_flags made use of snprintf, which is arguably the
"correct" way to do things if there can be a buffer overflow. In this
case I don't think there can be, the buffer is 1k in size which is at
least 5 times more than needed. What's more, snprintf returns the
count of chars that would be output given no buffer limit, which means
code like
r += snprintf (buf + r, size - r, ...);
r += snprintf (buf + r, size - r, ...);
is just wrong. There needs to be a check on the return value in order
to prevent buf + r being out of bounds for the second snprintf call.
BTW, if you look closely you'll see the return value of the decode
functions is unused. I admit to getting a little carried away with
writing "out = stpcpy (out, ...):" in each of the decode functions and
didn't notice that until get_machine_flags was trimmed down to a much
smaller size. When I did notice, I decided it's not such a bad thing.
* readelf.c (decode_ARC_machine_flags, decode_ARM_machine_flags),
(decode_AVR_machine_flags, decode_NDS32_machine_flags),
(decode_AMDGPU_machine_flags): Use stpcpy and sprintf return
value. Return end of string.
(decode_BLACKFIN_machine_flags, decode_FRV_machine_flags),
(decode_IA64_machine_flags, decode_LOONGARCH_machine_flags),
(decode_M68K_machine_flags, decode_MeP_machine_flags),
(decode_MIPS_machine_flags, decode_MSP430_machine_flags),
(decode_PARISC_machine_flags, decode_RISCV_machine_flags),
(decode_RL78_machine_flags, decode_RX_machine_flags),
(decode_SH_machine_flags, decode_SPARC_machine_flags),
(decode_V800_machine_flags, decode_V850_machine_flags),
(decode_Z80_machine_flags): New functions, split out from..
(get_machine_flags): ..here. Similarly use stpcpy.
Alan Modra [Thu, 3 Aug 2023 03:02:40 +0000 (12:32 +0930)]
binutils sprintf optimisation
Avoid the use of sprintf with a "%s" format string, replacing with
strcpy or stpcpy. Use sprintf return value rather than a later
strlen. Don't use strcat where we can keep track of the end of a
string output buffer.
* dlltool.c (look_for_prog): memcpy prefix and strcpy prog_name.
* dllwrap.c (look_for_prog): Likewise.
* resrc.c (look_for_default): Likewise. Add quotes with memmove
rather than allocating another buffer.
* size.c (size_number): Use sprintf return value.
* stabs.c (parse_stab_argtypes): Likewise.
* windmc.c (write_bin): Likewes, and use stpcpy.
* wrstabs.c: Similarly throughout.
Alan Modra [Thu, 3 Aug 2023 02:56:46 +0000 (12:26 +0930)]
cris: sprintf optimisation
Since I was poking at cris-dis.c to avoid the sanitizer warning,
I figure I might as well make use of stpcpy and sprintf return value
in other places in this file.
* cris-dis.c (format_hex): Use sprintf return value.
(format_reg): Use stpcpy and sprintf return, avoiding strlen.
(format_sup_reg): Likewise.
Alan Modra [Wed, 2 Aug 2023 23:10:12 +0000 (08:40 +0930)]
ld: sprintf sanitizer null destination pointer
* configure.ac (stpcpy): AC_CHECK_DECLS.
* sysdep.h (stpcpy): Add fallback declaraion.
* config.in: Regenerate.
* configure: Regenerate.
* emultempl/pe.em (open_dynamic_archive): Use
stpcpy rather than sprintf plus strlen.
* emultempl/pep.em (open_dynamic_archive): Likewise.
* emultempl/xtensaelf.em (elf_xtensa_before_allocation): Use
auto rather than malloc'd buffer. Use sprintf count.
* ldelf.c (ldelf_search_needed): Use memcpy in place of sprintf.
* pe-dll.c (pe_process_import_defs): Use string already formed
for alias match rather than recreating.
Alan Modra [Wed, 2 Aug 2023 22:29:47 +0000 (07:59 +0930)]
cris: sprintf sanitizer null destination pointer
Simplify the sprintf calls, and use sprintf return value. Older code
in binutils avoided using the sprintf return count of chars printed,
because with some older C libraries it wasn't reliable. Nowadays it
should be OK to use (and we already use the return value elsewhere).
sprintf can't return an error status of -1 here.
* cris-dis.c (format_dec): Avoid sanitizer warning. Use sprintf
return value rather than calling strlen.
Seen on Ubuntu 23.04 x86_64-linux using gcc-12.2 and gcc-12.3 with
CFLAGS="-m32 -g -O2 -fsanitize=address,undefined".
CC objdump.o
In file included from /usr/include/stdio.h:906,
from /home/alan/src/binutils-gdb/binutils/sysdep.h:24,
from /home/alan/src/binutils-gdb/binutils/objdump.c:51:
In function 'sprintf',
inlined from 'display_utf8' at /home/alan/src/binutils-gdb/binutils/objdump.c:621:14,
inlined from 'sanitize_string.part.0' at /home/alan/src/binutils-gdb/binutils/objdump.c:742:11:
/usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The warning is bogus of course. xmalloc is guaranteed to return
non-NULL, but apparently this isn't seen in display_utf6. The same
doesn't happen with -m64, maybe due to inlining differences, I haven't
investigated fully. Easily avoided as we hardly need to use sprintf
for a single char, or a two char string.
* objdump.c (display_utf8): Avoid bogus sprintf sanitizer warning.
Use hex ESC to switch back to default colour.
(sanitize_string): Comment. Bump buffer size by one. Fix overlong
line.
* nm.c (display_utf8, sanitize_string): As above.
Andrew Burgess [Tue, 18 Jul 2023 12:52:20 +0000 (13:52 +0100)]
gdb: fix possible nullptr dereference in a remote_debug_printf call
While working on another patch I triggered a segfault from within the
function remote_target::discard_pending_stop_replies. Turns out this
was caused by a cut&paste error introduced in this commit:
gdb, gdbserver: detach fork child when detaching from fork parent
This commit adds a remote_debug_printf call that was copied from
earlier in the function, however, the new call wasn't updated to use
the appropriate local variable. The local variable that it is using
might be nullptr, in which case we trigger undefined behaviour, and
could crash, which is what I was seeing.
Fixed by updating to use the correct local variable.
Tsukasa OI [Thu, 3 Aug 2023 05:35:53 +0000 (05:35 +0000)]
RISC-V: Add support for 'Zvfh' and 'Zvfhmin'
This commit adds support for recently ratified vector FP16 extensions:
'Zvfh' and 'Zvfhmin'.
This is based on:
<https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point>
<https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#zvfh-vector-extension-for-half-precision-floating-point>
Despite not having any new instructions, it will be necessary since those
extensions are already implemented in GCC.
Note that however, in this commit, following dependencies are implemented.
1. 'Zvfhmin' -> 'Zve32f'
2. 'Zvfh' -> 'Zvfhmin' (not 'Zvfh' -> 'Zve32f' as in the documentation)
3. 'Zvfh' -> 'Zfhmin'
This is because the instructions and configurations supported by the
'Zvfh' extension is a strict superset of the 'Zvfhmin' extension and
'Zvfh' -> 'Zve32f' dependency is indirectly derived from that fact.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_implicit_subsets): Add implications
related to 'Zvfh' and 'Zvfhmin' extensions.
(riscv_supported_std_z_ext) Add 'Zvfh' and 'Zvfhmin' to the list.
Tsukasa OI [Wed, 2 Aug 2023 23:50:27 +0000 (23:50 +0000)]
RISC-V: Imply 'Zicsr' from 'Zve32x'
Further clarification is made so that 'Zve32x' implies 'Zicsr' (the same
implication is already implemented in LLVM).
See related issue (the author raised) on the vector specification:
<https://github.com/riscv/riscv-v-spec/issues/908>
and its resolution:
<https://github.com/riscv/riscv-v-spec/issues/909>
Tom Tromey [Tue, 1 Aug 2023 14:33:42 +0000 (08:33 -0600)]
Avoid failures in fixed_points.exp with older GCC
Tom de Vries pointed out that my recent change to fixed_points.exp
failed with older versions of GCC. This patch fixes the problem by
skipping the new test in this situation.
Tom Tromey [Thu, 27 Jul 2023 20:27:05 +0000 (14:27 -0600)]
Implement DAP "source" request
This implements the DAP "source" request. I renamed the
"loadedSources" function from "sources" to "loaded_sources" to avoid
any confusion. I also moved the loadedSources test to the new
sources.exp.
Tom Tromey [Thu, 27 Jul 2023 20:04:31 +0000 (14:04 -0600)]
Introduce sourceReference handling in DAP
This changes the gdb DAP implementation to emit a real
sourceReference, rather than emitting 0. Sources are tracked in some
maps in sources.py, and a new helper function is introduced to compute
the "Source" object that can be sent to the client.
Tom Tromey [Tue, 25 Jul 2023 16:13:52 +0000 (10:13 -0600)]
Implement ValueFormat for DAP
This patch implements ValueFormat for DAP. Currently this only means
supporting "hex".
Note that StackFrameFormat is defined to have many more options, but
none are currently recognized. It isn't entirely clear how these
should be handled. I'll file a new gdb bug for this, and perhaps an
upstream DAP bug as well.
New in v2:
- I realized that the "hover" context was broken, and furthermore
that we only had tests for "hover" failing, not for it succeeding.
This version fixes the oversight and adds a test.
Tom Tromey [Thu, 27 Jul 2023 19:06:38 +0000 (13:06 -0600)]
Respect supportsMemoryReferences in DAP
I noticed that the support for memoryReference in the "variables"
output is gated on the client "supportsMemoryReferences" capability.
This patch implements this and makes some other changes to the DAP
memory reference code:
* Remove the memoryReference special case from _SetResult.
Upstream DAP fixed this oversight in response to
https://github.com/microsoft/debug-adapter-protocol/issues/414
* Don't use the address of a variable as its memoryReference -- only
emit this for pointer types. There's no spec support for the
previous approach.
* Use strip_typedefs to handle typedefs of pointers.
Tom Tromey [Mon, 24 Jul 2023 19:28:58 +0000 (13:28 -0600)]
Do not send "new breakpoint" event when breakpoint is set
When the DAP client sets a breakpoint, gdb currently sends a "new
breakpoint" event. However, Vladimir Makaev discovered that this
causes VSCode to think there are two breakpoints.
This patch changes gdb to suppress the event in this case.
Tom Tromey [Tue, 25 Jul 2023 13:04:45 +0000 (07:04 -0600)]
Move DAP breakpoint event code to breakpoint.py
A subsequent patch will add the ability to suppress breakpoint events
to DAP. My first attempt at this ended up with recurse imports,
causing Python failures. So, this patch moves all the DAP breakpoint
event code to breakpoint.py in preparation for the change.
I've renamed breakpoint_descriptor here as well, because it can now be
private to breakpoint.py.
Tom Tromey [Mon, 24 Jul 2023 14:48:00 +0000 (08:48 -0600)]
Full paths in DAP stackTrace responses
Vladimir Makaev noticed that, in some cases, a DAP stackTrace response
would include a relative path name for the "path" component.
This patch changes the frame decorator code to add a new DAP-specific
decorator, and changes the DAP entry point to frame filters to use it.
This decorator prefers the symtab's full name, and does not fall back
to the solib's name.
I'm not entirely happy with this patch, because if a user frame filter
uses FrameDecorator, it may still do the wrong thing. It would be
better to have frame filters return symtab-like objects instead, or to
have a separate method to return the full path to the source file.
I also tend to think that the solib fallback behavior of
FrameDecorator is a mistake. If this is ever needed, it seems to me
that it should be a separate method.
Tom Tromey [Mon, 24 Jul 2023 14:41:23 +0000 (08:41 -0600)]
Rename private member of FrameDecorator
In Python, a member name starting with "__" is specially handled to
make it "more private" to the class -- it isn't truly private, but it
is renamed to make it less likely to be reused by mistake. This patch
ensures that this is done for the private method of FrameDecorator.
Simon Farre [Mon, 5 Jun 2023 12:56:54 +0000 (14:56 +0200)]
Add thread exited event
Reports a thread exit according to the DAP spec:
https://microsoft.github.io/debug-adapter-protocol/specification#Events_Thread
This patch requires the ThreadExitedEvent to be checked in,
in order to work. That patch is found here https://sourceware.org/pipermail/gdb-patches/2023-June/200071.html
Nick Clifton [Tue, 1 Aug 2023 13:37:04 +0000 (14:37 +0100)]
Fix "--only-keep-debug for ELF relocatables" binutils test for compilers which add .debug_macro sections to object files.
PR 30699
* binutils/testsuite/binutils-all/objcopy.exp (keep_debug_symbols_for_elf_relocatable): Do not add sections containing the string "debug_" to the list of non-debug sections.
Jan Beulich [Tue, 1 Aug 2023 10:39:44 +0000 (12:39 +0200)]
gas: rework timestamp preservation on doc/asconfig.texi
PR 28909
Sadly "cp -p", doing more than just preserving the time stamp, can fail
e.g. upon trying to preserve ownership (which we don't care about), as
can be observed on e.g. Cygwin. Replace the use of -p by a use of touch,
this way also only preserving modification time.
projects / thirdparty / binutils-gdb.git / log
