Tom Tromey [Wed, 8 Jan 2025 20:05:16 +0000 (13:05 -0700)]
Rename two Ada test suite functions
I happened to notice that the Ada compiler emitted a warning when
compiling a couple of DAP tests. This wasn't intentional, and this
patch renames the functions to match the filename.
GDB, gdbserver: Convert regcache_register_size function to method
The regcache_register_size function has one implementation in GDB, and
one in gdbserver. Both of them have a gdb::checked_static_cast to their
corresponding regcache class. This can be avoided by defining a
pure virtual register_size method in the
reg_buffer_common class, which is then implemented by the reg_buffer
class in GDB, and by the regcache class in gdbserver.
Calls to the register_size () function from methods of classes in the
reg_buffer_common hierarchy need to be changed to calls to the newly
defined method, otherwise the compiler complains that a matching method
cannot be found.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3
Tom de Vries [Wed, 8 Jan 2025 15:24:11 +0000 (16:24 +0100)]
[gdb/testsuite] Check gnatmake version in gdb.ada/scalar_storage.exp
On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into:
...
(gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE
get_compiler_info: gcc-14-2-0
print V_BE^M
$2 = (value => 126, another_value => 12, color => red)^M
(gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE
...
The test-case contains a corresponding kfail:
...
# This requires a compiler fix that is in GCC 14.
if {[gcc_major_version] < 14} {
setup_kfail "DW_AT_endianity on enum types" *-*-*
}
...
which doesn't trigger because it checks the gcc version rather than the
gnatmake version.
Fix this by checking the gnatmake version instead.
Tom de Vries [Wed, 8 Jan 2025 15:07:08 +0000 (16:07 +0100)]
[gdb/testsuite] Require can_spawn_for_attach in gdb.base/gstack.exp
I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope
set to 1 and ran into:
...
PASS: gdb.base/gstack.exp: spawn gstack
ptrace: Operation not permitted.^M
GSTACK-END^M
PASS: gdb.base/gstack.exp: gstack exits with no error
PASS: gdb.base/gstack.exp: gstack's exit status is 0
FAIL: gdb.base/gstack.exp: got backtrace
...
Tom de Vries [Wed, 8 Jan 2025 11:48:08 +0000 (12:48 +0100)]
[gdb/testsuite] Require supports_process_record in gdb.reverse/test_ioctl_TCSETSW.exp
I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got:
...
(gdb) record full^M
Process record: the current architecture doesn't support record function.^M
(gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full
...
Tom de Vries [Wed, 8 Jan 2025 09:06:28 +0000 (10:06 +0100)]
[gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp for !supports_catch_syscall
I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got:
...
(gdb) catch syscall write^M
The feature 'catch syscall' is not supported on this architecture yet.^M
(gdb) FAIL: $exp: mode=syscall: catch syscall write
...
Fix 32085 Source file not recognized for gcc 11.4.0-compiled code
gprofng cannot read compressed section.
In the next release we plan to use libbfd everywhere instead of our ELF reader.
But in this release I use bfd_get_full_section_contents() only
when bfd_is_section_compressed() returns true.
gprofng/ChangeLog
2025-01-06 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/32085
* src/Elf.cc: Use bfd_get_full_section_contents to decompress a section.
* src/Elf.h: Define SEC_DECOMPRESSED.
Liwei Xu [Wed, 8 Jan 2025 03:38:48 +0000 (11:38 +0800)]
Support Intel AMX-FP8
In this patch, we will support AMX-FP8 feature. Since in the
foreseeable future, only AMX-MOVRS will also use VEX_MAP5, we
currently will not add a table of 256 entries and handle just
like MAP7.
Tom Tromey [Sun, 5 Jan 2025 22:20:50 +0000 (15:20 -0700)]
Rename two maint commands
This renames two maint commands, removing a hyphen from
"check-symtabs" and "check-psymtabs"; that is, moving them under the
existing "maint check" prefix.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Tom de Vries <tdevries@suse.de> Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Mon, 6 Jan 2025 20:34:47 +0000 (13:34 -0700)]
Fix crash in DWARF indexer
Iain pointed out a crash in the DWARF indexer when run on a certain D
program. The DWARF in this case has a nameless enum class; this
causes an assertion failure.
This patch arranges to simply ignore such types. The fact that an
enum class is nameless in this case appears to be a compiler bug.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518 Approved-By: Tom de Vries <tdevries@suse.de>
testsuite: adapt to new --debug command line option
Since commit "gdbserver: allow the --debug command line option to take a
value", gdbserver no longer supports
--debug
--remote-debug
--event-loop-debug.
Instead, --debug now takes a comma separated list of components.
The make check parameter GDBSERVER_DEBUG doesn't support these changes
yet. This patch fixes this, by adding the --debug gdbserver arguments,
as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for
GDBSERVER_DEBUG. Replay logging is still enabled by adding the
"replay" GDBSERVER_DEBUG argument. We can also configure "all" to
enable all of the available options.
Now, for instance, we can use it as follows:
make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
or simply
make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp"
Tom Tromey [Fri, 20 Dec 2024 20:16:17 +0000 (13:16 -0700)]
Clarify documentation of signal numbers
A user was confused by the meaning of signal numbers in the gdb CLI.
For instance, when using "signal 3", exactly which signal is
delivered? Is it always 3, or is it always SIGQUIT?
This patch attempts to clarify the documentation here.
Clément Chigot [Mon, 9 Dec 2024 10:00:07 +0000 (11:00 +0100)]
ld/testsuite: move board flags to ld_link
Both CFLAGS and LDFLAGS provided by dejagnu board configuration could be
required to perform a link.
Up to now, those flags were pulled with run_cc_link_tests and
run_ld_link_exec_tests and then passed to ld_link process as arguments.
This means that calling `ld_link` outside those functions must remember
to manually pass them.
Clément Chigot [Tue, 10 Dec 2024 13:08:44 +0000 (14:08 +0100)]
ld/testsuite/lto: replace manual links by ld_link helper
Some tests are calling run_host_cmd in order to retrieve the
errors/warnings messages generated.
ld_link is also making them available through exec_output global
variable but as the advantages of taking the board configuration into
account unlike run_host_cmd.
Jan Beulich [Mon, 6 Jan 2025 15:25:17 +0000 (16:25 +0100)]
x86/APX: simplify ENQCMD[,S} opcode table entries
APX_F() makes sense to use only for dual VEX/EVEX templates; ENQCMD{,S}
are legacy encoded though in their original forms. Make the entries
match the MOVDIR{I,64B} sibling ones.
Rainer Orth [Mon, 6 Jan 2025 15:24:14 +0000 (16:24 +0100)]
Fix procfs.c compilation
procfs.c compilation is currently broken on Solaris:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2067 | wait_retval = gdb::wait (&wstat);
| ^~~~
In file included from ../gnulib/import/sys/wait.h:28,
from /usr/include/stdlib.h:16,
from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
from <command-line>:
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2154 | int temp = gdb::wait (&wstat);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
2566 | gdb::wait (NULL);
| ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
85 | extern pid_t wait(int *);
| ^~~~
Jan Beulich [Mon, 6 Jan 2025 15:01:47 +0000 (16:01 +0100)]
x86/Intel: don't accept memory operands with J*CXZ and LOOP*
PR gas/31887
Like for, in particular, J<cc> such should be rejected. Simplify the
respective conditional in i386_intel_operand(), leveraging that
JumpAbsolute will never occur in the first template of a mnemonic-
specific group (thus making it unnecessary to exclude that one case).
At this occasion do the same simplification later in the function as
well: The resulting two operands will uniformly be invalid for all
mnemonics other than CALL and JMP (and their AT&T counterparts, which
we've been wrongly accepting in Intel syntax) anyway.
Jan Beulich [Mon, 6 Jan 2025 15:01:07 +0000 (16:01 +0100)]
gas: special-case division / modulo by ±1
Dividing the largest possible negative value by -1 generally is UB, for
the result not being representable at least in commonly used binary
notation. This UB on x86, for example, is a Floating Point Exception on
Linux, i.e. resulting in an internal error (albeit only when
sizeof(valueT) == sizeof(void *); the library routine otherwise involved
apparently deals with the inputs quite okay).
Leave original values unaltered for division by 1; this may matter down
the road, in case we start including X_unsigned and X_extrabit in
arithmetic. For the same reason treat modulo by 1 the same as modulo by
-1.
The quad and octa tests have more relaxed expecations than intended, for
X_unsigned and X_extrabit not being taken into account [yet]. The upper
halves can wrongly end up as all ones (for .octa, when !BFD64, even the
upper three quarters). Yet it makes little sense to address this just
for div/mod by ±1. quad-div2 is yet more special, to cover for most
32-bit targets being unable to deal with forward-ref expressions in
.quad even when BFD64; even ones being able to (like x86) then still
don't get the values right.
Tom Tromey [Tue, 17 Dec 2024 19:35:44 +0000 (12:35 -0700)]
Don't lex floating-point number in Rust field expression
Consider this Rust tuple:
let tuple_tuple = ((23i32, 24i32), 25i32);
Here, the value is a tuple whose first element is also a tuple.
You should be able to print this with:
(gdb) print tuple_tuple.0.1
However, currently the Rust lexer sees "0.1" as a floating-point
number.
This patch fixes the problem by introducing a special case in the
lexer: when parsing a field expression, the parser informs the lexer
that a number should be handled as a decimal integer only.
This change then lets us remove the decimal integer special case from
lex_number.
v2: I realized that the other DECIMAL_INTEGER cases aren't needed any
more.
Tom de Vries [Mon, 6 Jan 2025 08:53:26 +0000 (09:53 +0100)]
[gdb/build] Use const_cast in fd_copy
Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did:
...
fd_copy (fd_set *dst, const fd_set *src, int n)
{
FD_ZERO (dst);
for (int i = 0; i < n; ++i)
- if (FD_ISSET (i, src))
+ if (FD_ISSET (i, (fd_set *)src))
...
but according to [1] only const_cast may be used to cast away constness.
Alan Modra [Sun, 5 Jan 2025 11:14:06 +0000 (21:44 +1030)]
ar and foreign object files
ar is supposed to make archives containing any sort of file, and it
generally does that. It also tries to make archives suited to target
object files stored. Some targets have peculiar archives.
In one particular case we get into trouble trying to suit archives to
object files: where the target object file is recognised but that
target doesn't happen to support archives, and the default target has
a special archive format. For example, we'll get failures on
rs6000-aix if trying to add tekhex objects to a new archive. What
happens in that the tekhex object is recognised and its target vector
used to create an empty archive, ie. with _bfd_generic_mkarchive and
_bfd_write_archive_contents. An attempt is then made to open the
newly created archive. The tekhex target vector does not have a
check_format function to recognise generic archives, nor as it happens
do any of the xcoff or other targets built for rs6000-aix.
It seems to me the simplest fix is to not use any target vector to
create archives where that vector can't also recognise them. That's
what this patch does, and to reinforce that I've removed target vector
support for creating empty archives from such targets.
bfd/
* i386msdos.c (i386_msdos_vec): Remove support for creating
empty archives.
* ihex.c (ihex_vec): Likewise.
* srec.c (srec_vec, symbolsrec_vec): Likewise.
* tekhex.c (tekhex_vec): Likewise.
* wasm-module.c (wasm_vec): Likewise.
* ptrace-core.c (core_ptrace_vec): Tidy.
* targets.c (bfd_target_supports_archives): New inline function.
* bfd-in2.h: Regenerate.
binutils/
* ar.c (open_inarch): Don't select a target from the first
object file that can't read archives. Set output_filename
earlier.
* testsuite/binutils-all/ar.exp (thin_archive_with_nested):
Don't repeat --thin test using T.
(foreign_object): New test.
* testsuite/binutils-all/tek1.obj,
* testsuite/binutils-all/tek2.obj: New files.
Tom Tromey [Thu, 19 Dec 2024 01:49:45 +0000 (18:49 -0700)]
Fix latent bug in Ada import symbol handling
The code in dwarf2/read.c:new_symbol that handles Ada 'import' symbols
has a bug. It uses the current scope, which by default this is the
file scope -- even for a global symbol like:
This disagrees with the scope computed by the DWARF indexer.
Now, IMO new_symbol and its various weirdness really has to go. And,
ideally, this information would come from the indexer rather than
perhaps being erroneously recomputed. But meanwhile, this patch fixes
the issue at hand.
This came up while working on another change that exposes the bug.
A recent discussion about what commands are allowed during
gdb.Breakpoint.stop, made me wonder if there would be less restrictions if
we'd do those commands as part of a breakpoint command list instead.
Attribute gdb.Breakpoint.commands is a string with gdb commands, so I
tried implementing a new class PyCommandsBreakpoint, derived from
gdb.Breakpoint, that supports a py_commands method.
My original idea was to forbid setting PyCommandsBreakpoint.commands, and do:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
gdb.execute("continue")
...
but as it turns out 'gdb.execute("continue")' does not behave the same way as
continue. I've filed PR python/32454 about this.
So the unsatisfactory solution is to first execute
PyCommandsBreakpoint.py_commands:
...
def py_commands(self):
print("VAR: %d" % self.var)
self.var += 1
...
and then:
...
self.commands = "continue"
...
I was hoping for a better outcome, but having done the work of writing this, I
suppose it has use as a test-case, perhaps also as an example of how to work
around PR python/32454.
Tom de Vries [Sat, 4 Jan 2025 10:31:02 +0000 (11:31 +0100)]
[gdb/tdep] Fix gdb.base/finish-pretty.exp on s390x
On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into:
...
(gdb) finish
Run till exit from #0 foo () at finish-pretty.c:28
main () at finish-pretty.c:40
40 return v.a + v.b;
Value returned has type: struct s. Cannot determine contents
(gdb) FAIL: $exp: finish foo prettyprinted function result
...
The function being finished is foo, which returns a value of type struct s.
The ABI [1] specifies:
- that the value is returned in a storage buffer allocated by the caller, and
- that the address of this buffer is passed as a hidden argument in r2.
GDB fails to print the value when finishing foo, because it doesn't know the
address of the buffer.
Implement the gdbarch_get_return_buf_addr hook for s390x to fix this.
This is based on ppc_sysv_get_return_buf_addr, the only other implementation
of gdbarch_get_return_buf_addr. For readability I've factored out
dwarf_reg_on_entry.
There is one difference with ppc_sysv_get_return_buf_addr: only
NO_ENTRY_VALUE_ERROR is caught. If this patch is approved, I intend to submit
a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well.
The hook is not guaranteed to work, because it attempts to get the value r2
had at function entry.
The hook can be called after function entry, and the ABI doesn't guarantee
that r2 is the same throughout the function.
Using -fvar-tracking adds debug information, which allows the hook to succeed
more often, and indeed after adding this to the test-case, it passes.
Running selftest help_doc_invariants.
help doc broken invariant: command 'signal-event' help doc has over-long line
Self test failed: self-test failed at unittests/command-def-selftests.c:121
The reason is that doc string of 'signal-event' doesn't have
newlines at end of its line. Fix by adding newlines.
Tom de Vries [Sat, 4 Jan 2025 09:19:37 +0000 (10:19 +0100)]
[gdb/cli] Warn about forced return from signal trampoline
The Linaro CI reported a regression on arm-linux in test-case
gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply
workaround for PR gas/31115 a bit more") [1]:
...
(gdb) return^M
Make __default_sa_restorer return now? (y or n) n^M
Not confirmed^M
(gdb) FAIL: $exp: return from handleri: \
leave signal trampoline (got interactive prompt)
...
After installing package glibc-debuginfo and adding --with-separate-debug-dir
to the configure flags, I managed to reproduce the FAIL.
The regression seems to be a progression in the sense that the function name
for the signal trampoline is found.
After reading up on the signal trampoline [2] and the return command [3], my
understanding is that forced returning from the signal trampoline is
potentially unsafe, given that for instance the process signal mask won't be
restored.
Fix this by:
- rather than using the name, using "signal trampoline" in the query, and
- adding a warning about returning from a signal trampoline,
giving us:
...
(gdb) return^M
warning: Returning from signal trampoline does not fully restore pre-signal \
state, such as process signal mask.^M
Make signal trampoline return now? (y or n) y^M
87 dummy = 0; dummy = 0; while (!done);^M
(gdb) PASS: $exp: return from handleri: leave signal trampoline (in main)
...
Alan Modra [Sat, 4 Jan 2025 03:09:20 +0000 (13:39 +1030)]
ELF sec_info memory leaks
Use the bfd's objalloc memory so we don't need to free anything
attached to elf_section_data sec_info. Other uses of sec_info that
need to allocate memory already use bfd_alloc.
Alan Modra [Sat, 4 Jan 2025 06:27:48 +0000 (16:57 +1030)]
_bfd_write_ar_hdr
This has been broken since commit 8f95b6e44955 in 2010, and apparently
nobody has noticed. How we write archive headers depends on the
archive, not the contents.
Fangrui Song [Sun, 29 Dec 2024 22:57:44 +0000 (14:57 -0800)]
skip -gfile: call fnmatch without FNM_FILE_NAME
fnmatch is called with the FNM_FILE_NAME flag so that `skip -gfi /usr/*`
doesn't match /usr/include/*. This makes the file matching feature not
useful for STL headers that reside in multiple directories. In
addition, the user cannot use a single `*` to match multiple leading
path components.
Let's drop the FNM_FILE_NAME flag and remove the assertion from
gdb_filename_fnmatch (originally for the auto-load feature).
Alan Modra [Fri, 3 Jan 2025 23:10:21 +0000 (09:40 +1030)]
bfd_set_input_error
My recent change to closing archives showed some problems with the way
we stash errors for archive elements. The most obvious thing found
by oss-fuzz, is that if output archive elements are closed during
bfd_close of an archive, then we can't access the element filename
when printing the element. So change bfd_set_input_error to stash the
entire error message instead of input bfd and input error.
H.J. Lu [Thu, 2 Jan 2025 22:25:57 +0000 (06:25 +0800)]
nesting[123].d: Replace Sone with Some in comment
* testsuite/gas/macros/nesting1.d: Replace Sone with Some in
comment.
* testsuite/gas/macros/nesting2.d: Likewise.
* testsuite/gas/macros/nesting3.d: Likewise.
H.J. Lu [Wed, 1 Jan 2025 22:09:30 +0000 (06:09 +0800)]
gas: Revert PR 32391 related commits to fix 3 regressions
9f2e3c21f65 Fix the handling or arguments and macro pseudo-variables inside nested assembler macros.
introduced 3 regressions of PR gas/32484, PR gas/32486 and PR gas/32487.
Revert all PR 32391 related commits and add tests for PR gas/32484,
PR gas/32486, PR gas/32487.
Alan Modra [Wed, 1 Jan 2025 12:22:59 +0000 (22:52 +1030)]
readelf memory leaks
This fixes multiple readelf memory leaks:
- The check functions used to validate separate debug info files
opened and read file data but didn't release the memory nor close
the file.
- A string table was being re-read into a buffer, leaking the old
contents.
- Decompressed section contents leaked.
* dwarf.c (check_gnu_debuglink): Always call close_debug_file.
(check_gnu_debugaltlink): Likewise.
* readelf.c (process_section_headers): Don't read string_table
again if we already have it.
(maybe_expand_or_relocate_section): Add decomp_buf param to
return new uncompressed buffer.
(dump_section_as_strings, filedata->string_table): Free any
uncompressed buffer.
(process_file): Call close_debug_file rather than freeing
various filedata components.
Alan Modra [Wed, 1 Jan 2025 12:22:06 +0000 (22:52 +1030)]
Close elements of output archive
When cleaning up an archive, close all its elements. This fixes a
number of ar memory leaks.
bfd/
* archive.c (_bfd_archive_close_and_cleanup): Close elements
of an archive open for writing.
binutils/
* objcopy.c (copy_archive): Don't close output archive
elements here.
* dlltool.c (gen_lib_file): Likewise.
ld/
* pe-dll.c (pe_dll_generate_implib): Don't close output
archive elements here.
Alan Modra [Wed, 1 Jan 2025 12:21:44 +0000 (22:51 +1030)]
bfdtest1 loop check
Add a check that next_archived_file doesn't return the same element.
Seen with the following, which I think shows a bug with "ar r" and
thin archives as you get two copies of artest.a in artest2.a.
Alan Modra [Wed, 1 Jan 2025 12:20:17 +0000 (22:50 +1030)]
gas obj-elf.c memory leaks
* config/obj-elf.c (obj_elf_section): Use notes_memdup for
linked_to_symbol_name.
(obj_elf_find_and_add_versioned_name): Use notes_alloc for
versioned_name.
Alan Modra [Wed, 1 Jan 2025 12:19:04 +0000 (22:49 +1030)]
gas tc_gen_reloc memory leaks
This makes all the tc_gen_reloc functions and the associated array in
write.c:write_relocs use notes_alloc rather than malloc. tc-hppa.c
tc_gen_reloc gets a few more changes, deleting some dead code, and
tidying code that duplicates prior initialisation.
Alan Modra [Wed, 1 Jan 2025 12:17:16 +0000 (22:47 +1030)]
gas dw2gencfi memory leaks
Some of these could have remained as malloc'd memory, but that would
require quite a bit of code to traverse frch_cfi_data for example, and
would rely on matching cfi directives (ie. valid input). Just put
them on the notes obstack instead.
* dw2gencfi.c (alloc_fde_entry): Use notes_calloc.
(alloc_cfi_insn_data): Likewise.
(cfi_end_fde): Don't free frch_cfi_data.
(cfi_add_label): Use notes_strdup.
(cfi_add_CFA_remember_state): Use notes_alloc.
(cfi_add_CFA_restore_state): Don't free.
(dot_cfi_escape): Use notes_alloc.
(cfi_finish): Free cies after each pass, not before. Clear
out static vars too.
Alan Modra [Wed, 1 Jan 2025 12:08:44 +0000 (22:38 +1030)]
gas include_dirs memory leak
This is the first of a series of patches aimed at making it possible
to configure with CFLAGS="-g -O2 -fsanitize=address,undefined" and run
the binutils and gas testsuite on x86_64-linux without using
ASAN_OPTIONS=detect_leaks=0. ie. the patch series is aimed at fixing
common gas, ar, objcopy, objdump, and readelf leaks.
* config/tc-tic54x.c (md_begin): Make use of notes_strdup rather
than xstrdup to copy entries added to include_dirs.
* read.c (read_end): Free include_dirs array.
Alan Modra [Wed, 1 Jan 2025 12:01:50 +0000 (22:31 +1030)]
PR 32507, PRIx64 in error messages on 32-bit mingw
People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety. (We
handled %ll OK, editing it to %I64 on such hosts.)
PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.
Tom Tromey [Thu, 19 Dec 2024 00:36:09 +0000 (17:36 -0700)]
Use 'flags' when expanding symtabs in gdbpy_lookup_static_symbols
This changes gdbpy_lookup_static_symbols to pass the 'flags' parameter
to expand_symtabs_matching. This should refine the search somewhat.
Note this is "just" a performance improvement, as the loop over
symtabs already checks 'flags'.
v2 also removes 'SEARCH_GLOBAL_BLOCK' and updates py-symbol.exp to
verify that this works properly. Thanks to Tom for this insight.
Jan Beulich [Fri, 27 Dec 2024 10:37:05 +0000 (11:37 +0100)]
ld/testsuite: replace aarch64 uses of load_lib
Using $srcdir/$subdir directly doesn't work, at least not with expect
5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
aspect which is crucial here). Make use of load_file instead.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:45 +0000 (12:41 +0800)]
LoongArch: Reword message for unresolvable relocs
For PDE, "recompiling with -fPIE" just makes no sense.
For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.
If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols. A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:44 +0000 (12:41 +0800)]
LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE
In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility. This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":
$ cat t.c
int x (void) __attribute__ ((weak));
int
main (void)
{
__builtin_printf("%p\n", x);
}
$ gcc t.c -static-pie -mdirect-extern-access
$ ./a.out
0x7ffff1d64000
Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.
But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols. Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk. (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)
While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.
Xi Ruoyao [Wed, 25 Dec 2024 04:41:43 +0000 (12:41 +0800)]
LoongArch: Fix resolution of undefined weak hidden/protected symbols
An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0. So
in PIE or DSO the runtime address would be incorrect.
Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.
Alan Modra [Wed, 25 Dec 2024 08:47:24 +0000 (19:17 +1030)]
buffer overflow in gas/app.c
This testcase:
.irp x x x "
.end #
.endr
manages to access lex[EOF].
xxx: Warning: end of file in string; '"' inserted
xxx:1: Warning: missing closing `"'
gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
Following that there is a buffer overflow.
Stop this happening, and in other similar places, by checking for EOF.
Andrew Burgess [Fri, 15 Dec 2023 13:03:26 +0000 (13:03 +0000)]
gdb/testsuite: add some xfail in gdb.base/startup-with-shell.exp
There are two tests that fail in gdb.base/startup-with-shell.exp when
using the native-extended-remote board. I plan to fix these issues,
and I've posted a series that does just that:
Andrew Burgess [Mon, 21 Oct 2024 15:41:54 +0000 (16:41 +0100)]
gdb/freebsd: port core file context parsing to FreeBSD
This commit implements the gdbarch_core_parse_exec_context method for
FreeBSD.
This is much simpler than for Linux. On FreeBSD, at least the
version (13.x) that I have installer, there are additional entries in
the auxv vector that point directly to the argument and environment
vectors, this makes it trivial to find this information.
If these extra auxv entries are not available on earlier FreeBSD, then
that's fine. The fallback behaviour will be for GDB to act as it
always has up to this point, you'll just not get the extra
functionality.
Other differences compared to Linux are that FreeBSD has
AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is
the full path to the executable. On Linux AT_EXECFN is the command
the user typed, so this can be a relative path.
This difference is handy as on FreeBSD we don't parse the mapped files
from the core file (are they even available?). So having the EXECPATH
means we can use that as the absolute path to the executable.
However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be
the absolute path to the symlink, not to the underlying file. This is
probably a good thing, but it does mean there is one case we test on
Linux that fails on FreeBSD.
On Linux if we create a symlink to an executable, then run the symlink
and generate a corefile. Now delete the symlink and load the core
file. On Linux GDB will still find (and open) the original
executable. This is because we use the mapped file information to
find the absolute path to the executable, and the mapped file
information only stores the real file names, not symlink names.
This is a total edge case, I only added the deleted symlink test
originally because I could see that this would work on Linux. Though
it is neat that Linux finds this, I don't feel too bad that this fails
on FreeBSD.
Other than this, everything seems to work on x86-64 FreeBSD (13.4)
which is all I have setup right now. I don't see why other
architectures wouldn't work too, but I haven't tested them.
Andrew Burgess [Thu, 2 May 2024 14:37:42 +0000 (15:37 +0100)]
gdb: improve GDB's ability to auto-load the exec for a core file
GDB already has a limited mechanism for auto-loading the executable
corresponding to a core file, this can be found in the function
locate_exec_from_corefile_build_id in corelow.c.
However, this approach uses the build-id of the core file to look in
either the debug directory (for a symlink back to the executable) or
by asking debuginfod. This is great, and works fine if the core file
is a "system" binary, but often, when I'm debugging a core file, it's
part of my development cycle, so there's no build-id symlink in the
debug directory, and debuginfod doesn't know about the binary either,
so GDB can't auto load the executable....
... but the executable is right there!
This commit builds on the earlier commits in this series to make GDB
smarter.
On GNU/Linux, when we parse the execution context from the core
file (see linux-tdep.c), we already grab the command pointed to by
AT_EXECFN. If this is an absolute path then GDB can use this to
locate the executable, a build-id check ensures we've found the
correct file. With this small change GDB suddenly becomes a lot
better at auto-loading the executable for a core file.
But we can do better! Often the AT_EXECFN is not an absolute path.
If it is a relative path then we check for this path relative to the
core file. This helps if a user does something like:
In this case the core file in the current directory will have an
AT_EXECFN value of './build/bin/some_prog', so if we look for that
path relative to the location of the core file this might result in a
hit, again, a build-id check ensures we found the right file.
But we can do better still! What if the user moves the core file? Or
the user is using some tool to manage core files (e.g. the systemd
core file management tool), and the user downloads the core file to a
location from which the relative path no longer works?
Well in this case we can make use of the core file's mapped file
information (the NT_FILE note). The executable will be included in
the mapped file list, and the path within the mapped file list will be
an absolute path. We can search for mapped file information based on
an address within the mapped file, and the auxv vector happens to
include an AT_ENTRY value, which is the entry address in the main
executable. If we look up the mapped file containing this address
we'll have the absolute path to the main executable, a build-id check
ensures this really is the file we're looking for.
It might be tempting to jump straight to the third approach, however,
there is one small downside to the third approach: if the executable
is a symlink then the AT_EXECFN string will be the name of the
symlink, that is, the thing the user asked to run. The mapped file
entry will be the name of the actual file, i.e. the symlink target.
When we auto-load the executable based on the third approach, the file
loaded might have a different name to that which the user expects,
though the build-id check (almost) guarantees that we've loaded the
correct binary.
But there's one more thing we can check for!
If the user has placed the core file and the executable into a
directory together, for example, as might happen with a bug report,
then neither the absolute path check, nor the relative patch check
will find the executable. So GDB will also look for a file with the
right name in the same directory as the core file. Again, a build-id
check is performed to ensure we find the correct file.
Of course, it's still possible that GDB is unable to find the
executable using any of these approaches. In this case, nothing
changes, GDB will check in the debug info directory for a build-id
based link back to the executable, and if that fails, GDB will ask
debuginfod for the executable. If this all fails, then, as usual, the
user is able to load the correct executable with the 'file' command,
but hopefully, this should be needed far less from now on.
Andrew Burgess [Thu, 24 Oct 2024 21:04:10 +0000 (22:04 +0100)]
gdb/testsuite: make some of the core file / build-id tests harder
We have a few tests that load core files, which depend on GDB not
auto-loading the executable that matches the core file. One of these
tests (corefile-buildid.exp) exercises GDB's ability to load the
executable via the build-id links in the debug directory, while the
other two tests are just written assuming that GDB hasn't auto-loaded
the executable.
In the next commit, GDB is going to get better at finding the
executable for a core file, and as a consequence these tests could
start to fail if the testsuite is being run using a compiler that adds
build-ids by default, and is on a target (currently only Linux) with
the improved executable auto-loading.
To avoid these test failures, this commit updates some of the tests.
coredump-filter.exp and corefile.exp are updated to unload the
executable should it be auto-loaded. This means that the following
output from GDB will match the expected patterns. If the executable
wasn't auto-loaded then the new step to unload is harmless.
The corefile-buildid.exp test needed some more significant changes.
For this test it is important that the executable be moved aside so
that GDB can't locate it, but we do still need the executable around
somewhere, so that the debug directory can link to it. The point of
the test is that the executable _should_ be auto-loaded, but using the
debug directory, not using GDB's context parsing logic.
While looking at this test I noticed two additional problems, first we
were creating the core file more times than we needed. We only need
to create one core file for each test binary (total two), while we
previously created one core file for each style of debug info
directory (total four). The extra core files should be identical, and
were just overwriting each other, harmless, but still pointless work.
The other problem is that after running an earlier test we modified
the test binary in order to run a later test. This means it's not
possible to manually re-run the first test as the binary for that test
is destroyed.
As part of the rewrite in this commit I've addressed these issues.
This test does change many of the test names, but there should be no
real changes in what is being tested after this commit. However, when
the next commit is added, and GDB gets better at auto-loading the
executable for a core file, these tests should still be testing what
is expected.
Andrew Burgess [Sat, 8 Jun 2024 10:06:02 +0000 (11:06 +0100)]
gdb: parse and set the inferior environment from core files
Extend the core file context parsing mechanism added in the previous
commit to also store the environment parsed from the core file.
This environment can then be injected into the inferior object.
The benefit of this is that when examining a core file in GDB, the
'show environment' command will now show the environment extracted
from a core file.
Consider this example:
$ env -i GDB_TEST_VAR=FOO ./gen-core
Segmentation fault (core dumped)
$ gdb -c ./core.1669829
...
[New LWP 1669829]
Core was generated by `./gen-core'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb) show environment
GDB_TEST_VAR=foo
(gdb)
Andrew Burgess [Thu, 25 Apr 2024 08:36:43 +0000 (09:36 +0100)]
gdb: add gdbarch method to get execution context from core file
Add a new gdbarch method which can read the execution context from a
core file. An execution context, for this commit, means the filename
of the executable used to generate the core file and the arguments
passed to the executable.
In later commits this will be extended further to include the
environment in which the executable was run, but this commit is
already pretty big, so I've split that part out into a later commit.
Initially this new gdbarch method is only implemented for Linux
targets, but a later commit will add FreeBSD support too.
Currently when GDB opens a core file, GDB reports the command and
arguments used to generate the core file. For example:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./gen-core abc def'.
However, this information comes from the psinfo structure in the core
file, and this struct only allows 80 characters for the command and
arguments combined. If the command and arguments exceed this then
they are truncated.
Additionally, neither the executable nor the arguments are quoted in
the psinfo structure, so if, for example, the executable was named
'aaa bbb' (i.e. contains white space) and was run with the arguments
'ccc' and 'ddd', then when this core file was opened by GDB we'd see:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./aaa bbb ccc ddd'.
It is impossible to know if 'bbb' is part of the executable filename,
or another argument.
However, the kernel places the executable command onto the user stack,
this is pointed to by the AT_EXECFN entry in the auxv vector.
Additionally, the inferior arguments are all available on the user
stack. The new gdbarch method added in this commit extracts this
information from the user stack and allows GDB to access it.
The information on the stack is writable by the user, so a user
application can start up, edit the arguments, override the AT_EXECFN
string, and then dump core. In this case GDB will report incorrect
information, however, it is worth noting that the psinfo structure is
also filled (by the kernel) by just copying information from the user
stack, so, if the user edits the on stack arguments, the values
reported in psinfo will change, so the new approach is no worse than
what we currently have.
The benefit of this approach is that GDB gets to report the full
executable name and all the arguments without the 80 character limit,
and GDB is aware which parts are the executable name, and which parts
are arguments, so we can, for example, style the executable name.
Another benefit is that, now we know all the arguments, we can poke
these into the inferior object. This means that after loading a core
file a user can 'show args' to see the arguments used. A user could
even transition from core file debugging to live inferior debugging
using, e.g. 'run', and GDB would restart the inferior with the correct
arguments.
Now the downside: finding the AT_EXECFN string is easy, the auxv entry
points directly too it. However, finding the arguments is a little
trickier. There's currently no easy way to get a direct pointer to
the arguments. Instead, I've got a heuristic which I believe should
find the arguments in most cases. The algorithm is laid out in
linux-tdep.c, I'll not repeat it here, but it's basically a search of
the user stack, starting from AT_EXECFN.
If the new heuristic fails then GDB just falls back to the old
approach, asking bfd to read the psinfo structure for us, which gives
the old 80 character limited answer.
For testing, I've run this series on (all GNU/Linux) x86-64. s390,
ppc64le, and the new test passes in each case. I've done some very
basic testing on ARM which does things a little different than the
other architectures mentioned, see ARM specific notes in
linux_corefile_parse_exec_context_1 for details.
Alan Modra [Tue, 24 Dec 2024 00:58:46 +0000 (11:28 +1030)]
arc: add_to_decodelist
Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three
entries to decodelist for each instruction disassembled. That can
waste a lot of cpu when the list grows large. What's more,
decodelist is static and nothing clears the list. So the list
persists from one file to the next if objdump is disassembling
multiple files in one invocation. Wrong disassembly might result.
To fix this problem, I've moved decodelist to the arc private_data and
made it an array. I believe that init_disassemble_data will be
called, clearing private_data, for each file disassembled. That's
certainly true for objdump, and if I can see my way around gdb
constructors, it's also true for gdb. I don't think there is a
possibility of info.disassembler_options changing unless there is
first a call to init_disassebled_data. That means all of the option
parsing and bfd mach and e_flags decoding need only be done when
initialising the arc private_data.
projects / thirdparty / binutils-gdb.git / log
