arc: Update opcode related include files for ARCv3.
Add new ARCv3 CPUs and required bits to decode/encode ARCv3 ISA
opcodes. Fix 32 bit relocations which were set as signed but should be
bitfield: ARC_32_ME, ARC_GLOB_DAT, ARC_JMP_SLOT, ARC_RELATIVE. Remove
non-ABI relocation ARC_32_ME_S.
include/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
Cupertino Miranda <cupertinomiranda@gmail.com>
Bruno Mauricio <brunoasmauricio@gmail.com>
* include/elf/arc-cpu.def: Add new HS5x and HS6x CPUs.
* include/elf/arc-reloc.def: Add new ARC64 relocations.
* include/elf/arc.h (EF_ARC_CPU_ARC64): New define.
* include/opcode/arc-attrs.h (FEATURE_LIST_NAME): Update predicate.
* include/opcode/arc-func.h: Update formating.
(replace_disp8ls): New function.
(replace_disp9s): Likewise.
(replace_disp6s): Likewise.
(replace_disp7s): Likewise.
(replace_disp12s): Likewise.
* include/opcode/arc.h (ARC_OPCODE_ARC64): New define.
(ARC_OPCODE_ARC32): Likewise.
(ARC_OPERAND_FP): Likewise.
(HARD_FIELDF): Likewise.
(ARC_OPCODE_ARCVx): New macro.
(arc_flag_class): Update structure to hold new extract/insert
functions for flags.
(INSN3OP): Update macro.
(FP_SIZE, TPOF, DPOF, SOPF, COPF, CONVOPS): New enums.
The new Synopsys's ARCv3 ISA is capable to run either 64-bit or
32-bit ISA. The new 32-bit ISA is not compatible with the old
Synopsys ARCv1/ARCv2 ISA, however, it retains a lot of common
concepts. Thus, this patch is reusing the old ARC BFD backend and
adds the necessary bits for the new architecture in a similar way as
it is done for RISCV backend.
bfd/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
Cupertino Miranda <cupertinomiranda@gmail.com>
* bfd/Makefile.am: Add ARC64 files.
* bfd/Makefile.in: Regerate.
* bfd/arc-got.h (TCB_SIZE): Depends on the target architecture.
(GOT_ENTRY_SIZE): New define.
(write_in_got): Likewise.
(read_from_got): Likewise.
(align_power): Likewise.
(arc_got_entry_type_for_reloc): Use RELA_SIZE and GOT_ENTRY_SIZE.
(arc_fill_got_info_for_reloc): Update formating.
(relocate_fix_got_relocs_for_got_info): Likewise.
(arc_static_sym_data): Deleted structure.
(get_static_sym_data): Deleted function.
(relocate_fix_got_relocs_for_got_info): Use symbol static data.
(create_got_dynrelocs_for_single_entry): Update formating.
(create_got_dynrelocs_for_got_info): Likewise.
* bfd/arc-plt.c: New file.
* bfd/arc-plt.def: Add ARC64 PLT entry.
* bfd/arc-plt.h: Clean it up, move functionality to arc-plt.c file.
* bfd/archures.c: Add ARC64 target.
* bfd/config.bfd: Likewise.
* bfd/configure.ac: Likewise.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure: Likewise.
* bfd/libbfd.h: Likewise.
* bfd/cpu-arc.c: Clean it up.
* bfd/cpu-arc64.c: New file.
* bfd/elf32-arc.c: Renamed to elfnn-arc.c.
* bfd/elfnn-arc.c: New file.
* bfd/reloc.c: Add new ARC64 relocs.
* bfd/targets.c: Add ARC64 target.
Enze Li [Mon, 11 Sep 2023 14:40:43 +0000 (22:40 +0800)]
fbsd-nat: Pacify gcc with no functional changes
I see these errors on FreeBSD/aarch64 when using gcc 12 without passing
--disable-werror.
=====================================================================
CXX fbsd-nat.o
fbsd-nat.c: In member function 'void fbsd_nat_target::resume_one_process(ptid_t, int, gdb_signal)':
fbsd-nat.c:1208:11: error: unused variable 'request' [-Werror=unused-variable]
1208 | int request;
| ^~~~~~~
fbsd-nat.c: In member function 'virtual ptid_t fbsd_nat_target::wait(ptid_t, target_waitstatus*, target_wait_flags)':
fbsd-nat.c:1726:22: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
1726 | for (inferior *inf : all_non_exited_inferiors (this))
| ^~~
fbsd-nat.c:1697:17: note: shadowed declaration is here
1697 | inferior *inf = find_inferior_ptid (this, wptid);
| ^~~
fbsd-nat.c: In member function 'virtual void fbsd_nat_target::detach(inferior*, int)':
fbsd-nat.c:2044:18: error: variable 'wptid' set but not used [-Werror=unused-but-set-variable]
2044 | ptid_t wptid = wait_1 (ptid, &ws, 0);
| ^~~~~
cc1plus: all warnings being treated as errors
=====================================================================
This patch includes the following non-functional changes,
1. Remove unused variable "request".
2. Rename inf to inf_p to avoid shadowed declaration warnings.
3. Mark wptid as used when USE_SIGTRAP_SIGINFO is defined.
Tom Tromey [Tue, 19 Sep 2023 17:02:27 +0000 (11:02 -0600)]
Remove keywords from target debug printer names
I recently checked in a patch that removed the use of the "struct"
keyword in some spots. Doing this pointed out that the target
delegate code preserves this keyword -- but, with C++, it does not
really need to. This patch changes make-target-delegates.py to remove
these keywords, and updates target-debug.h to follow. This pointed
out that there was already one redudancy: both
target_debug_print_struct_inferior_p and target_debug_print_inferior_p
existed.
gprofng: 30834 improve disassembly output for call and branch instructions
This patch makes the gprofng disassembler to emit, e.g.
call fprintf@plt [ 0x401060, .-0x49c]
instead of
call 0xfffffffffffffb64
I use bfd_get_synthetic_symtab() to get function names in the .plt section.
I have not yet modified Elf-reader in gprofng to remove parsing of .symtab or
.dynsym sections. But we plan to do it.
gprofng/ChangeLog
2023-09-20 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/30834
* src/Disasm.cc: Show the function name in the call instruction
and the relative address in the branch instruction. Remove unused code.
* src/Disasm.h (map_PC_to_func, get_funcname_in_plt): New functions.
* src/Elf.cc: Get function names for the .plt section.
* src/Elf.h (get_funcname_in_plt, get_bfd_symbols): New functions.
* src/Stabs.cc: Add pltSym to SymLst. Remove the conversion to uint32_t.
Thomas Weißschuh [Thu, 21 Sep 2023 06:03:09 +0000 (08:03 +0200)]
ld: write resolved path to included file to dependency-file
In ldfile_open_command_file_1() name written to the dependency files is
the name as specified passed to the "INCLUDE" directive.
This is before include-path processing so the tracked dependency
location is most likely wrong.
Instead track the opened file at the point where the resolved path is
actually available, in try_open().
Tom Tromey [Wed, 20 Sep 2023 23:08:28 +0000 (17:08 -0600)]
Remove stray trailing "," from DAP breakpoint.py
The buildbot pointed out that the last DAP series I checked in had an
issue. Looking into it, it seems there is a stray trailing "," in
breakpoint.py. This patch removes it.
This seems to point out a test suite deficiency. I will look into
fixing that.
Tom Tromey [Wed, 20 Sep 2023 02:34:23 +0000 (20:34 -0600)]
Remove explanatory comments from includes
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Gregory Anders [Fri, 1 Sep 2023 21:02:20 +0000 (16:02 -0500)]
gdb/dap: only include sourceReference if file path does not exist
According to the DAP specification if the "sourceReference" field is
included in a Source object, then the DAP client _must_ make a "source"
request to the debugger to retrieve file contents, even if the Source
object also includes path information.
If the Source's path field is a valid path that the DAP client is able
to read from the filesystem, having to make another request to the
debugger to get the file contents is wasteful and leads to incorrect
results (DAP clients will try to get the contents from the server and
display those contents as a file with the name in "source.path", but
this will conflict with the _acutal_ existing file at "source.path").
Instead, only set "sourceReference" if the source file path does not
exist.
Gregory Anders [Fri, 1 Sep 2023 21:02:19 +0000 (16:02 -0500)]
gdb/dap: use breakpoint fullname to resolve source
If the breakpoint has a fullname, use that as the source path when
resolving the breakpoint source information. This is consistent with
other callers of make_source which also use "fullname" if it exists (see
e.g. DAPFrameDecorator which returns the symtab's fullname).
Gregory Anders [Fri, 1 Sep 2023 21:02:18 +0000 (16:02 -0500)]
gdb/dap: ignore unused keyword args in step_out
Some DAP clients may send additional parameters in the stepOut command
(e.g. "granularity") which are not used by GDB, but should nonetheless
be accepted without error.
Gregory Anders [Fri, 1 Sep 2023 21:02:17 +0000 (16:02 -0500)]
gdb/dap: check for breakpoint source before unpacking
Not all breakpoints have a source location. For example, a breakpoint
set on a raw address will have only the "address" field populated, but
"source" will be None, which leads to a RuntimeError when attempting to
unpack the filename and line number.
Before attempting to unpack the filename and line number from the
breakpoint, ensure that the source information is not None. Also
populate the source and line information separately from the
"instructionReference" field, so that breakpoints that include only an
address are still included.
gdb/tui: add 'set tui mouse-events off' to restore mouse selection
Rationale:
I use the mouse with my terminal to select and copy text. In gdb, I use
the mouse to select a function name to set a breakpoint, or a variable
name to print, for example.
When gdb is compiled with ncurses mouse support, gdb's TUI mode
intercepts mouse events. Left-clicking and dragging, which would
normally select text, seems to do nothing. This means I cannot select
text using my mouse anymore. This makes it harder to set breakpoints,
print variables, etc.
Solution:
I tried to fix this issue by editing the 'mousemask' call to only enable
buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
to not allow text to be selected. The only way I could make it work is
by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
entirely, which other people might want.
I therefore decided to make a setting in gdb called 'tui mouse-events'.
If enabled (the default), the behavior is as it is now: terminal mouse
events are given to gdb, disabling the terminal's default behavior.
If disabled (opt-in), the behavior is as it was before the year 2020:
terminal mouse events are not given to gdb, therefore the mouse can be
used to select and copy text.
Notes:
I am not attached to the setting name or its description. Feel free to
suggest better wording.
Testing:
I tested this change in gnome-terminal by performing the following steps
manually:
1. Run: gdb --args ./myprogram
2. Enable TUI: press ctrl-x ctrl-a
3. Click and drag text with the mouse. Observe no selection.
4. Input: set tui mouse-events off
5. Click and drag text with the mouse. Observe that selection works now.
6. Input: set tui mouse-events on.
7. Click and drag text with the mouse. Observe no selection.
Tom de Vries [Wed, 20 Sep 2023 14:05:55 +0000 (16:05 +0200)]
[gdb/symtab] Error out for .debug_types section in dwz file
There are two methods to factor out type information in a dwarf4 executable:
- use -fdebug-info-types to generate type units in a .debug_types section, and
- use dwz to create partial units.
The dwz method has an extra benefit: it also allows to factor out information
between executables into a newly created .dwz file, pointed to by a
.gnu_debugaltlink section.
There is nothing prohibiting a .gnu_debugaltlink file to contain a
.debug_types section.
It's just not generated by dwz or any other tool atm, and consequently gdb has
no support for it. Enhancement PR symtab/30838 is open about the lack of
support.
Make the current situation explicit by emitting a dwarf error:
...
(gdb) file struct-with-sig-2^M
Reading symbols from struct-with-sig-2...^M
Dwarf Error: .debug_types section not supported in dwz file^M
...
and add an assert in write_gdbindex:
...
+ /* See enhancement PR symtab/30838. */
+ gdb_assert (!(per_cu->is_dwz && per_cu->is_debug_types));
...
to clarify why we can use:
...
data_buf &cu_list = (per_cu->is_debug_types
? types_cu_list
: per_cu->is_dwz ? dwz_cu_list : objfile_cu_list);
...
The test-case is a modified copy from gdb.dwarf2/struct-with-sig.exp, so it
keeps the copyright years range.
Tom Tromey [Tue, 5 Sep 2023 15:13:14 +0000 (09:13 -0600)]
Handle pointers and references correctly in DAP
A user pointed out that the current DAP variable code does not let the
client deference a pointer. Oops!
Fixing this oversight is simple enough -- adding a new no-op
pretty-printer for pointers and references is quite simple.
However, doing this naive caused a regession in scopes.exp, which
expected there to be no children of a 'const char *' variable. This
problem was fixed by the preceding patches in the series, which ensure
that a C type of this kind is recognized as a string.
Tom Tromey [Tue, 5 Sep 2023 18:29:23 +0000 (12:29 -0600)]
Give a language to a type
This changes main_type to hold a language, and updates the debug
readers to set this field. This is done by adding the language to the
type-allocator object.
Note that the non-DWARF readers are changed on a "best effort" basis.
This patch also reimplements type::is_array_like to use the type's
language, and it adds a new type::is_string_like as well. This in
turn lets us change the Python implementation of these methods to
simply defer to the type.
Tom Tromey [Tue, 5 Sep 2023 19:08:29 +0000 (13:08 -0600)]
Add is_array_like and to_array to language_defn
This adds new is_array_like and to_array methods to language_defn.
This will be used in a subsequent patch that generalizes the new
Python array- and string-handling code.
Tom Tromey [Tue, 5 Sep 2023 18:54:40 +0000 (12:54 -0600)]
Regularize some DWARF type initialization
In one spot, it will be convenient for a subsequent patch if the CU is
passed to a type-creation helper function. In another spot, remove
the redundant 'objfile' parameter to another such function.
Tom Tromey [Tue, 5 Sep 2023 18:43:50 +0000 (12:43 -0600)]
Pass a type allocator to init_fixed_point_type
init_fixed_point_type currently takes an objfile and creates its own
type allocator. However, for a later patch it is more convenient if
this function accepts a type allocator. This patch makes this change.
Tom Tromey [Fri, 15 Sep 2023 18:05:57 +0000 (12:05 -0600)]
Use gdb::checked_static_cast for tracepoints
This replaces some casts to 'tracepoint *' with checked_static_cast.
Some functions are changed to accept a 'tracepoint *' now, for better
type safety.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb, breakpoint: add a destructor to the watchpoint struct
Make sure to unlink the related breakpoint when the watchpoint instance
is deleted. This prevents having a wp-related breakpoint that is
linked to a NULL watchpoint (e.g. the watchpoint instance is being
deleted when the 'watch' command fails). With the below scenario,
having such a left out breakpoint will lead to a GDB hang, and this
is due to an infinite loop when deleting all inferior breakpoints.
Scenario:
(gdb) set can-use-hw-watchpoints 0
(gdb) awatch <SCOPE VAR>
Can't set read/access watchpoint when hardware watchpoints are disabled.
(gdb) rwatch <SCOPE VAR>
Can't set read/access watchpoint when hardware watchpoints are disabled.
(gdb) <continue the program until the end>
>> HANG <<
Signed-off-by: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> Reviewed-by: Bruno Larsen <blarsen@redhat.com>
After the series that added this command was pushed, Pedro mentioned
that the news description could easily be misinterpreted, as well as
some code and test improvements that should be made.
While fixing the test, I realized that code repetition wasn't
happening as it should, so I took care of that too.
Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Tue, 5 Sep 2023 18:30:08 +0000 (12:30 -0600)]
Move val_prettyformat to valprint.h
I stumbled across an ancient FIXME comment that was easy to fix --
val_prettyformat does not need to be in defs.h, and is easily moved to
valprint.h, where (despite what the comment says) it belongs.
Tom de Vries [Sat, 16 Sep 2023 02:10:53 +0000 (04:10 +0200)]
[gdb/symtab] Fix overly large gdb-index file check for 32-bit
Add a unit test which checks that write_gdb_index_1 will throw
an error when the size of the file would exceed the maximum value
capable of being represented by 'offset_type'.
The unit test fails on 32-bit systems due to wrapping overflow. Fix this by
changing the type of total_len in write_gdbindex_1 from size_t to uint64_t.
Tested on x86_64-linux.
Co-Authored-By: Kevin Buettner <kevinb@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Wed, 6 Sep 2023 13:41:45 +0000 (09:41 -0400)]
gdb/amdgpu: add precise-memory support
The amd-dbgapi library exposes a setting called "memory precision" for
AMD GPUs [1]. Here's a copy of the description of the setting:
The AMD GPU can overlap the execution of memory instructions with other
instructions. This can result in a wave stopping due to a memory violation
or hardware data watchpoint hit with a program counter beyond the
instruction that caused the wave to stop.
Some architectures allow the hardware to be configured to always wait for
memory operations to complete before continuing. This will result in the
wave stopping at the instruction immediately after the one that caused the
stop event. Enabling this mode can make execution of waves significantly
slower.
Expose this option through a new "amdgpu precise-memory" setting.
The precise memory setting is per inferior. The setting is transferred
from one inferior to another when using the clone-inferior command, or
when a new inferior is created following an exec or a fork.
It can be set before starting the inferior, in which case GDB will
attempt to apply what the user wants when attaching amd-dbgapi. If the
user has requested to enable precise memory, but it can't be enabled
(not all hardware supports it), GDB prints a warning.
If precise memory is disabled, GDB prints a warning when hitting a
memory exception (translated into GDB_SIGNAL_SEGV or GDB_SIGNAL_BUS),
saying that the stop location may not be precise.
Note that the precise memory setting also affects memory watchpoint
reporting, but the watchpoint support for AMD GPUs hasn't been
upstreamed to GDB yet. When we do upstream watchpoint support, GDB will
produce a similar warning message when stopping due to a watchpoint if
precise memory is disabled.
Add a handful of tests. Add a util proc
"hip_devices_support_precise_memory", which indicates if all devices
used for testing support that feature.
Simon Marchi [Thu, 13 Apr 2023 20:18:34 +0000 (16:18 -0400)]
gdb: add inferior_cloned observable
The following patch makes the amdgpu port transfer a property from the
original inferior to the new inferior when using the clone-inferior
command. Add the inferior_cloned observable to help with this.
Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 15 Sep 2023 16:13:24 +0000 (10:13 -0600)]
Fix build failure with GCC 4.8
A user pointed out that the build failed with GCC 4.8. The problem
was that the form used by the std::hash specialization of ptid_t was
not accepted. This patch rewrites this code into a form that is
acceptable to the older compiler.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Fri, 15 Sep 2023 15:56:18 +0000 (11:56 -0400)]
gdb: add Lancelot Six as maintainer of the AMD GPU port
Lancelot has accepted to take the role of maintainer for the AMD GPU
port. The AMD GPU port (amdgpu as I've written in the MAINTAINERS file)
is an umbrella term for everything needed to make this work: the amdgcn
arch, the amd-dbgapi target, solib-rocm, etc.
Thanks for accepting the role, and congratulations!
arc: Fix alignment of the TLS Translation Control Block
The R_ARC_TLS_LE_32 is defined as S + A + TLS_TBSS - TLS_REL, where
- S is the base address of the symbol in the memory
- A is the symbol addendum
- TLS_TBSS is the TLS Translation Control Block size (aligned)
- TLS_REL is the base of the TLS section
Given the next code snip:
__thread int data_var = 12;
__attribute__((__aligned__(128))) __thread int data_var_128 = 128;
__thread int bss_var;
__attribute__((__aligned__(256))) __thread int bss_var_256;
Andrew Burgess [Fri, 8 Sep 2023 10:20:25 +0000 (11:20 +0100)]
gdb: small cleanup in symbol_file_add_with_addrs
While looking at how gdb::observers::new_objfile was used, I found
some code in symbol_file_add_with_addrs that I thought could be
improved.
Instead of:
if (condition)
{
...
return;
}
...
return;
Where some parts of '...' identical between the two branches. I think
it would be nicer if the duplication is removed, and we just use:
if (!condition)
...
to guard the one statement that should only happen when the condition
is not true.
There is one change in this commit though that is (possibly)
significant, there is a call to bfd_cache_close_all() that was only
present in the second block. After this commit we now call that
function for both paths.
The call to bfd_cache_close_all was added in commit:
with the purpose of ensuring that GDB doesn't hold the BFDs open
unnecessarily, thus preventing the files from being updated on some
hosts (e.g. Win32).
In the early exit case we previously didn't call bfd_cache_close_all,
with the result that GDB would continue to hold open some BFD objects
longer than needed.
After this commit, but calling bfd_cache_close_all for both paths this
problem is solved.
I'm not sure how this change could be tested, I don't believe there's
any GDB (maintenance) command that displays the BFD cache contents, so
we can't check the cache contents easily. Ideas are welcome though.
Jinyang He [Fri, 11 Aug 2023 08:10:40 +0000 (16:10 +0800)]
LoongArch: Enable gas sort relocs
The md_pre_output_hook creating fixup is asynchronous, causing relocs
may be out of order in .eh_frame. Define GAS_SORT_RELOCS so that reorder
relocs when write_relocs.
Jan Beulich [Fri, 15 Sep 2023 07:57:05 +0000 (09:57 +0200)]
x86: fold CpuLM and Cpu64
Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while
Cpu64 is solely used in insn templates, they no longer need to be
treated different from other "ordinary" flags; the only "unusual" one
left if CpuNo64. Fold both, leaving just Cpu64.
Jan Beulich [Fri, 15 Sep 2023 07:56:33 +0000 (09:56 +0200)]
x86: don't play with cpu_arch_flags.cpu{,no}64
A total four places exists where we set the two bits from flag_code, but
these values are never used. The two bits are evaluated only when coming
from insn templates.
Drop these assignments. Also make obvious that cpu_flags_check_cpu64()
is only ever used against insn templates.
gdb/testsuite: explicitly test for stderr in gdb.mi/mi-dprintf.exp
As mentioned in commit 3f5bbc3e2075ef5061a815c73fdc277218489f22, some
compilers such as clang don't add debug information about stderr by
default, leaving it to external debug packages.
This commit adds a way to check if GDB has access to stderr information
when in MI mode, and uses this new mechanism to skip the related section
of the test gdb.mi/mi-dprintf.exp. It also fixes an incorrect name for a
test in that file.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
Kevin Buettner [Sat, 9 Sep 2023 01:15:53 +0000 (18:15 -0700)]
Throw error when creating an overly large gdb-index file
The header in a .gdb_index section uses 32-bit unsigned offsets to
refer to other areas of the section. Thus, there is a size limit of
2^32-1 which is currently unaccounted for by GDB's code for outputting
these sections.
At the moment, when GDB creates an overly large section, it will exit
abnormally due to an internal error, which is caused by a failed
assert in assert_file_size, which in turn is called from
write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c.
This is what happens when that assert fails:
$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `libgraph_tool_inference.so'? (y or n) n
Not confirmed.
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x55fddb4d78b0 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x55fddb4d78b0 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x55fddb98b5d4 internal_vproblem
../../gdb/utils.c:396
0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag
../../gdb/utils.c:476
0x55fddbb71654 _Z18internal_error_locPKciS0_z
../../gdbsupport/errors.cc:58
0x55fddb5a0f23 assert_file_size
../../gdb/dwarf2/index-write.c:1069
0x55fddb5a1ee0 assert_file_size
/usr/include/c++/13/bits/stl_iterator.h:1158
0x55fddb5a1ee0 write_gdbindex_1
../../gdb/dwarf2/index-write.c:1119
0x55fddb5a51be write_gdbindex
../../gdb/dwarf2/index-write.c:1273
[...]
---------------------
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
This problem was encountered while building the python-graph-tool
package on Fedora. The Fedora bugzilla bug can be found here:
This commit prevents the internal error from occurring by calling error()
when the file size exceeds 2^32-1.
Using a gdb built with this commit, I now see this behavior instead:
$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n
Not confirmed.
Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded
(gdb)
I wish I could provide a test case, but due to the sizes of both the
input and output files, I think that testing resources would be
strained or exceeded in many environments.
So 'saved' is going to point to addresses.size () bytes of memory,
however, the std::copy will write addresses.size () number of
CORE_ADDR sized entries to the address pointed to by 'saved', this is
going to result in memory corruption.
The mistake is that we should have used XOBNEWVEC, which allocates a
vector of entries, the definition of XOBNEWVEC is:
Which means we will have set aside enough space to create a copy of
the contents of the addresses vector.
I'm not sure how to create a test for this problem, this issue cropped
up when debugging a particular i686 built binary, which just happened
to trigger a glibc assertion (likely due to random memory corruption),
debugging the same binary built for x86-64 appeared to work just fine.
Using valgrind on the failing GDB binary pointed straight to the cause
of the problem, and with this patch in place there are no longer
valgrind errors in this area.
If anyone has ideas for a test I'm happy to work on something.
Co-Authored-By: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Thu, 14 Sep 2023 18:34:00 +0000 (20:34 +0200)]
[gdb/exp] Clean up asap in value_print_array_elements
I've been running the test-suite on an i686-linux laptop with 1GB of memory,
and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
not being able to spawn for a large number of test-cases afterwards.
So I investigated the memory usage, on my usual x86_64-linux development
platform.
The test-case is compiled with -DCRASH_GDB=2097152, so this:
...
static int a[CRASH_GDB], b[CRASH_GDB];
...
with sizeof (int) == 4 represents two arrays of 8MB each.
Say we add a loop around the "print a" command and print space usage
statistics:
...
gdb_test "maint set per-command space on"
for {set i 0} {$i < 100} {incr i} {
gdb_test "print a"
}
...
This gets us:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 478248960 (+469356544 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 486629376 (+8380416 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 495009792 (+8380416 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 1308721152 (+8380416 for this command)^M
...
In other words, we start out at 8MB, and the first print costs us about 469MB,
and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
i686-linux laptop, the first print costs us 335MB. ]
The subsequent 8MBs are consistent with the values being saved into the value
history, but the usage for the initial print seems somewhat excessive.
There is a PR open about needing sparse representation of large arrays
(PR8819), but this memory usage points to an independent problem.
The function value_print_array_elements contains a scoped_value_mark to free
allocated values in the outer loop, but it doesn't prevent the inner loop from
allocating a lot of values.
Fix this by adding a scoped_value_mark in the inner loop, after which we have:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...
Note that the +0 here just means that the mallocs did not trigger an sbrk.
This is dependent on malloc (which can use either mmap or sbrk or some
pre-allocated memory) and will likely vary between different tunings, versions
and implementations, so this does not give us a reliable way detect the
problem in a minimal way.
A more reliable way of detecting the problem is:
...
void
value_free_to_mark (const struct value *mark)
{
+ size_t before = all_values.size ();
auto iter = std::find (all_values.begin (), all_values.end (), mark);
if (iter == all_values.end ())
all_values.clear ();
else
all_values.erase (iter + 1, all_values.end ());
+ size_t after = all_values.size ();
+ if (before - after >= 1024)
+ fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
...
which without the fix tells us:
...
+print a
value_free_to_mark freed 2097152 items
$1 = {0 <repeats 2097152 times>}
...
Fix a similar problem for Fortran:
...
+print array1
value_free_to_mark freed 4194303 items
$1 = (0, <repeats 2097152 times>)
...
in fortran_array_printer_impl::process_element.
The problem also exists for Ada:
...
+print Arr
value_free_to_mark freed 2097152 items
$1 = (0 <repeats 2097152 times>)
...
but is fixed by the fix for C.
Add Fortran and Ada variants of the test-case. The *.exp files are similar
enough to the original to keep the copyright years range.
While writing the Fortran test-case, I ran into needing an additional print
setting to print the entire array in repeat form, filed as PR exp/30817.
I managed to apply the compilation loop for the Ada variant as well, but with
a cumbersome repetition style. I noticed no other test-case uses gnateD, so
perhaps there's a better way of implementing this.
The regression test included in the patch is formulated in its weakest
form, to avoid false positive FAILs, which also means that smaller regressions
may not get detected.
Tom de Vries [Thu, 14 Sep 2023 18:34:00 +0000 (20:34 +0200)]
[gdb/testsuite] Modernize gdb.base/huge.exp
Rewrite test-case gdb.base/huge.exp:
- use build_executable rather than gdb_compile,
- use save_vars,
- factor out hardcoded loop limits min and max,
- handle compilation failure using require, and
- avoid using . in regexp to match $, {} and <>.
Jan Beulich [Thu, 14 Sep 2023 06:44:13 +0000 (08:44 +0200)]
x86: Vxy naming correction
Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
operand purpose isn't properly reflected in Vxy's definition. Rename
"dst" to "src", thus bringing things in line with Exy.
Jan Beulich [Thu, 14 Sep 2023 06:43:45 +0000 (08:43 +0200)]
x86: support AVX10.1 vector size restrictions
Recognize "/<number>" suffixes on both -march=+avx10.1 and the
corresponding .arch directive, setting an upper bound on the vector size
that insns may use. Such a restriction can be reset by setting a new base
architecture, by using a suffix-less form, by disabling AVX10, or by
enabling any other VEX/EVEX-based vector extension.
While for most insns we can suppress their use with too wide operands
via registers becoming unavailable (or in Intel syntax memory operand
size specifiers not being recognized), mask register insns have to have
their minimum required vector size specified in a new attribute. (Of
course this new attribute could also be used on other insns.)
Note that .insn continues to be permitted to emit EVEX{512,256} (and
VEX256 ones) encodings regardless of vector size restrictions in place.
Of course these can't be expressed using zmm (or ymm) operands then,
but need using the EVEX.512.* forms (broadcast forms may be usable right
now, but this may go away so shouldn't be relied upon). This is why no
assertions should be added to build_{e,}vex_prefix().
Jan Beulich [Thu, 14 Sep 2023 06:42:43 +0000 (08:42 +0200)]
x86: support AVX10.1/512
Since this is merely a re-branding of certain AVX512* features, there's
little code to be added.
The main aspect here are new testcases. In order to be able to re-use
some of the existing testcases, several of them need their start symbols
adjusted. Note that 256- and 128-bit tests want adding here, as these
need to work right away. Subsequently they'll gain vector length
constraints.
Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
test.
Jan Beulich [Thu, 14 Sep 2023 06:40:58 +0000 (08:40 +0200)]
x86: make AES/PCMULQDQ respectively prereqs of VAES/VPCMULQDQ
These probably should have been put in place already anyway, but they're
very much wanted in order to then put AVX10.1 support on top. Note that
to avoid reverse dependencies towards SSE (just like we already do for
AVX and XOP), add_isa_dependencies() needs some further tweaking.
While there also address a related anomaly: Disabling AES but neither
AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
VEX-encoded forms available. Note that for this the VAES insns are moved
past the AVX+AES ones, to avoid the property-11 test suddenly failing.
The test really is wrong, but let's not also make things inconsistent:
Without the movement, YMM use would be correctly recorded for the
128-bit forms simply because the first template already matches, as long
as VAES wasn't disabled. Yet it still wouldn't be if only AVX+AES were
enabled. Nor would behavior here then be the same as for VPCLMUL* insns.
Simon Marchi [Tue, 12 Sep 2023 17:37:06 +0000 (13:37 -0400)]
gdb/mi: remove warning about mi1
Remove a warning about mi1. mi1 was removed in 975249ff4e26 ("Remove MI
version 1"). It is no longer possible to reach this warning, since
trying to use interpreter mi1 bails out before:
Tom Tromey [Tue, 5 Sep 2023 12:55:54 +0000 (06:55 -0600)]
Avoid spurious breakpoint-setting failure in DAP
A user pointed out that if a DAP setBreakpoints request has a 'source'
field in a SourceBreakpoint object, then the gdb DAP implementation
will throw an exception.
While SourceBreakpoint does not allow 'source' in the spec, it seems
better to me to accept it. I don't think we should fully go down the
"Postel's Law" path -- after all, we have the type-checker -- but at
the same time, if we do send errors, they should be intentional and
not artifacts of the implementation.
Enze Li [Tue, 12 Sep 2023 13:40:05 +0000 (21:40 +0800)]
gdb: Fix -Wuninitialized issue
I see the following warning when building GDB on FreeBSD/amd64 with
Clang 14,
======================================================================
CXX mdebugread.o
mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized]
f->set_loc_enumval (tsym.value);
^
mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning
struct field *f;
^
= nullptr
======================================================================
after digging a little, I realized that we can not simply do what
Clang 14 says.
The root cause of this issue is that we lost the initialization of
the variable 'f' in this commit,
The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a
call to execl which does not have NULL as a last argument. This is
an invalid use of execl. This patch fixes this oversight.
Change-Id: I03b60abe30468d71ba5089b240c6d00f9b8883b2 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 11 Sep 2023 15:21:26 +0000 (09:21 -0600)]
Update Python signal-handling documentation
I noticed a typo in the "Basic Python" node, and when fixing it
realized that the paragraph could use a link to the block_signals
function. This patch is the result.
Ijaz, Abdul B [Fri, 8 Sep 2023 20:56:18 +0000 (22:56 +0200)]
testsuite, fortran: Fix regression due to fix for ifort's 'start' behavior
Got a regression email due to merge of commit in CI config
tcwg_gdb_check/master-aarch64 :
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec
Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above
commit to start the test from running to line with tag "First Breakpoint"
instead of "fortran_runto_main". Reason of the regression is shared
libraries are still loaded after hitting the breakpoint as "nosharedlibrary"
is already called before hitting the breakpoint.
So now after this change test is updated accordingly to disable and unload
shared libraries symbols after hitting the first breakpoint.
Simon Marchi [Fri, 8 Sep 2023 02:26:59 +0000 (22:26 -0400)]
gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs
I see the following failure when running this test on an AMD machine:
p/x $fioff^M
$24 = 0x0^M
(gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff
The register that GDB calls fioff normally contains the address of the
last instruction executed by the x87 unit. It is available through the
FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
area. You can read about it in the Intel manual [1] at section "10.5.1
FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
State".
The test therefore expects that after executing the FLD1 instruction,
the fioff register contains the address of the FLD1 instruction.
However, the FXSAVE and XSAVE instructions (which the kernel uses to
dump x87 register state which it provides GDB through ptrace) behave
differently on AMD CPUs. In section "11.4.4.3 FXSAVE and FXRSTOR
Instructions" of the AMD manual, we read:
The FXSAVE and FXRSTOR instructions save and restore the entire
128-bit media, 64-bit media, and x87 state. These instructions
usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
not normally save and restore the x87 exception pointers
(last-instruction pointer, last data-operand pointer, and last
opcode). The only case in which they do save the exception pointers
is the relatively rare case in which the exception-summary bit in
the x87 status word (FSW.ES) is set to 1, indicating that an
unmasked exception has occurred.
So, unless a floating point exception happened and that exception is
unmasked in the x87 FPU control register (which isn't by default on
Linux, from what I saw), the "last instruction address" register (or
fioff as GDB calls it) will always be 0 on an AMD CPU.
For this reason, I think it's fine to change the test to accept the
value 0 - that's just how the processor works.
I toyed with the idea of changing the test program to make it so the CPU
would generate a non-zero fioff. That is by unmasking an FPU exception
and executing an instruction to raise that kind exception. It worked,
but then I would have to change the test more extensively, and it didn't
seem to be worth it.
Jinyang He [Thu, 10 Aug 2023 02:21:40 +0000 (10:21 +0800)]
Make sure DW_CFA_advance_loc4 is in the same frag
Do the same as commit b9d8f5601bcf in another place generating
DW_CFA_advance_loc4. The idea behind commit b9d8f5601bcf was that
when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
eh_frame_convert_frag we want to remove the opcode entirely, not just
convert to a nop. If the opcode was split over two frags then a size
adjustment would need to be done to the first frag, not just the
second as is correct for other cases with split frags. This would
complicate the eh relaxation. It's easier to ensure the frag is not
split.
* ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4
to be placed in a different frag to the rs_cfa.
Simon Marchi [Fri, 8 Sep 2023 15:20:58 +0000 (11:20 -0400)]
gdb/doc: describe x87 registers
While investigating this [1], I initially had no idea what register
"fioff" stood for, making it difficult to map it to something in the
Intel or AMD manuals. Similarly, I can imaging someone familiar with
x87 to want to print the "x87 last instruction address", and have no
clue that GDB makes it available as register "fioff". The names of the
x87 state fields don't seem to be standardized, they even change between
sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
descriptions).
Add some details to the doc to help one map GDB register names to x87
state fields.
Simon Marchi [Fri, 8 Sep 2023 15:20:57 +0000 (11:20 -0400)]
gdb/doc: rename "x86 Architecture-specific Issues" section to "x86"
I'm looking to add some x86-specific information to the doc, but I find
the naming of this section odd. It doesn't really talk about issues, it
just gives generally useful information. Also, the sections about other
architectures don't mention "issues", just the architecture name.
Also, at least in the HTML version of the doc, the name is inconsistent
between the main table of content, where it appears as "x86
Architecture-specific Issues", and the sub-table of contents of the
"Architectures" section, where it appears as "i386".
Rename the section to just "x86".
Change-Id: I0a119ff1ab5e7b83c9afa3c3977eb085e88f52ca Approved-By: Eli Zaretskii <eliz@gnu.org>
projects / thirdparty / binutils-gdb.git / log
