Nick Clifton [Thu, 7 Nov 2024 14:53:26 +0000 (14:53 +0000)]
Deprecate the ARM simulator.
The ARM simulator is no longer able to simulator modern ARM cores, so it
is being deprecated. Once this change has been active for a while - and
assuming that no problems have been found - the ARm simulator codebase
will be removed.
Stephan Rohr [Tue, 22 Oct 2024 14:01:19 +0000 (07:01 -0700)]
gdbserver: add process specific thread list and map
Replace the servers global thread list with a process specific thread
list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on
GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions
to use std::unordered_map::find for faster lookup of threads without
iterating over all processes and threads, if applicable. This becomes
important when debugging applications with a large thread count, e.g.,
in the context of GPU debugging.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Peter Bergner [Wed, 6 Nov 2024 19:37:10 +0000 (13:37 -0600)]
PowerPC: Merge rfc2655 and rfc2656 test cases into one future test case
gas/
* testsuite/gas/ppc/rfc02655.[ds]: Rename from this...
* testsuite/gas/ppc/future.[ds]: ... to this.
* testsuite/gas/ppc/rfc02656.[ds]: Delete. Move tests to future.[ds].
* testsuite/gas/ppc/ppc.exp: Update for file name changes.
The last parameter is bool* that when set will receive information
if the match was exact. This parameter is never used by any callsite
and can therefore be removed.
This will become:
symtab *find_line_symtab (symtab *sym_tab, int line, int *index);
Tom Tromey [Fri, 1 Nov 2024 19:07:16 +0000 (13:07 -0600)]
Remove gdb::hash_enum
gdb::hash_enum is a workaround for a small oversight in C++11:
std::hash was not defined for enumeration types. This was rectified
in C++14 and so we can remove the local workaround.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Mon, 30 Sep 2024 15:01:26 +0000 (16:01 +0100)]
gdb: use option framework for add-inferior and clone-inferior
Convert the add-inferior and clone-inferior commands to make use of
the option framework. This improves the tab completion for these
commands.
Previously the add-inferior command used a trick to simulate
completion of -exec argument. The command use filename completion for
everything on the command line, thus you could do:
(gdb) add-inferior /path/to/some/fil<TAB>
and GDB would complete the file name, even though add-inferior doesn't
really take a filename as an argument. This helped a little though
because, if the user did this:
(gdb) add-inferior -exec /path/to/some/fil<TAB>
then the file name would be completed. However, GDB didn't really
understand the options, so couldn't offer completion of the options
themselves.
After this commit, the add-inferior command makes use of the recently
added gdb::option::filename_option_def feature. This means that the
user now has full completion of the option names, and that file names
will still complete for the '-exec' option, but will no longer
complete if the '-exec' option is not used.
I have also converted the clone-inferior command, though this command
does not use any file name options. This command does now have proper
completion of the command options.
Andrew Burgess [Wed, 11 Sep 2024 14:25:32 +0000 (15:25 +0100)]
gdb: add filename option support
This commit adds support for filename options to GDB's option
sub-system (see cli/cli-option.{c,h}).
The new filename options support quoted and escaped filenames, and tab
completion is fully supported.
This commit adds the new option, and adds these options to the
'maintenance test-options' command as '-filename', along with some
tests that exercise this new option.
I've split the -filename testing into two. In gdb.base/options.exp we
use the -filename option with some arbitrary strings. This tests that
GDB can correctly extract the value from a filename option, and that
GDB can complete other options after a filename option. However,
these tests don't actually pass real filenames, nor do they test
filename completion.
In gdb.base/filename-completion.exp I have added some tests that test
the -filename option with real filenames, and exercise filename tab
completion.
This commit doesn't include any real uses of the new filename options,
that will come in the next commit.
This program creates a thread via main that sleeps for 20 seconds.
When we debug this with gdb we get,
Reading symbols from ./test...
(gdb) b main
Breakpoint 1 at 0x10000934: file test.c, line 11.
(gdb) r
Starting program: /read_only_gdb/binutils-gdb/gdb/test
Breakpoint 1, main () at test.c:11
11 pthread_create(&thread, nullptr, thread_main, nullptr);
(gdb) c
Continuing. 15335884
[New Thread 258 (tid 31130079)]
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 258 (tid 31130079)]
0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) thread 1
[Switching to thread 1 (Thread 1 (tid 25493845))]
(gdb) c
Continuing.
[Thread 1 (tid 25493845) exited]
[Thread 258 (tid 31130079) exited]
inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
There are two bugs here. One is the core dump. The other is the main thread information
not captured.
So, while I was debugging the first part the reason, the reason I figured out was
the last for loop in sync_threadlists ().
Once both my threads exit we delete them as below:
But once these two threads are deleted, all_threads ()
has one more thread whose tid and pid are 0.
gdb) c
Continuing.
In for loop 8782296 is pid, 19857879 is tid
[Thread 1 (tid 19857879) exited]
In for loop 8782296 is pid, 30933401 is tid
[Thread 258 (tid 30933401) exited]
In for loop 0 is pid, 0 is tid
[Inferior 1 (process 8782296) exited normally]
(gdb) q
I used a printf in the for loop mentioned above for explaination.
You see the loop enters the third time with 0 as pid.
The reason being though the threads are removed but not deleted since they are
not deletable ().
Hence we use all_threads_safe () iterator instead.
The second part to the bug is the lack of information of the main thread.
Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html)
Thank you Andrew.
The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread
failed. This returned EPERM as errno.
gprofng application names have a gp- prefix (gp-display-text, gp-archive, etc.).
But our man pages use the gprofng- prefix (gprofng-display-text,
gprofng-archive, etc.).
I renamed the gprofng binaries and temporarily created the gp-* links for
compatibility with the old gprofng-gui.
We plan to remove these links in version 2.46.
gprofng/ChangeLog
2024-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
Indu Bhagat [Fri, 1 Nov 2024 22:36:35 +0000 (15:36 -0700)]
ld: generate SFrame stack trace info for .plt.got
PR/32298 sframe: no SFrame stack trace info generated for .plt.got
Add support to generate SFrame stack trace info for .plt.got section.
Enhance the current definition of struct elf_x86_sframe_plt to include
initialized SFrame FDE/FREs applicable for .plt.got section. There are
two variants of .plt.got entries: 16 byte and 8 byte.
For the testcase, define some application symbols such that their PLT
entry is placed in .plt.got and ensure SFrame information is generated
with and without -z ibtplt.
ChangeLog:
PR/32298
* bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
PLT GOT entry size is different for IBT vs non IBT PLTs.
* bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for
SFRAME_PLT_GOT.
(_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT.
(_bfd_x86_elf_write_sframe_plt): Likewise.
(_bfd_x86_elf_late_size_sections): Likewise.
(_bfd_x86_elf_finish_dynamic_sections): Likewise.
* bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members
to keep information about PLT GOT entries.
(struct elf_x86_link_hash_table): Add support for creating
SFrame section for .plt.got.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new tests.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test.
* ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test.
Josh Poimboeuf [Fri, 1 Nov 2024 22:36:03 +0000 (15:36 -0700)]
ld: fix wrong SFrame info for lazy IBT PLT
Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt
The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and
.plt.sec entries. It was observed that SFrame information for .plt.sec
section was incorrect. The erroneous assumption was that SFrame stack
trace information for .plt.sec with lazy binding is the same as SFrame
stack trace information for .plt with lazy binding. This is corrected
now by initializing a new SFrame PLT helper object
elf_x86_64_sframe_ibt_plt for lazy PLT with IBT.
Add a testcase where linking with -z ibtplt generates .plt.sec entries and
ensure correct SFrame information for it.
Committed by Indu Bhagat.
ChangeLog:
PR/32296
* bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New
definition elf_x86_64_sframe_ibt_plt. Use it in
elf_x86_64_sframe_plt.
(elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are
different from lazy PLT.
* bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for
SFrame for IBT PLT.
* ld/testsuite/ld-x86-64/x86-64.exp: Add new test.
* ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test.
Josh Poimboeuf [Fri, 1 Nov 2024 22:26:13 +0000 (15:26 -0700)]
ld: fix PR/32297
When _creating_ SFrame information for the linker created .plt.sec, the
code correctly checks for presence of .plt.sec. When _writing_ the
SFrame section for the corresponding .plt.sec, however, the conditionals
were wrongly checking for splt. This was causing an assertion at link
time.
This issue has been known to affect glibc build with SFrame enabled.
No testcase is added just yet. A later commit ensures correct SFrame
stack trace information is created for .plt.got. A test case (where only
.plt and .plt.got are created) is added then.
PR/32297 sframe: bfd assertion with empty main on IBT enabled system
Committed by Indu Bhagat.
ChangeLog:
PR/32297
* bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for
plt_second member not for splt.
0000000000000000 <func>:
0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 <func+0x6> 2: R_X86_64_PC32 foo-0x4
6: c3 ret
$ ld -shared -o x.so x.o
ld: x.o: in function `func':
x.c:(.text+0x2): undefined reference to `foo'
ld: x.o: relocation R_X86_64_PC32 against undefined hidden symbol `foo' can not be used when making a shared object
ld: final link failed: bad value
$
since -fPIC has been used.
* testsuite/ld-x86-64/hidden6.d: New file.
* testsuite/ld-x86-64/hidden6.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run hidden6.
This appears to be due to the mismatch between ATTRIBUTE_NORETURN and
[[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error
resolves the issue. Removing ATTTRIBUTE_NORETURN on the
declaration of host_callback::error also works, but deprives the
compiler of data.
Tested by compiling on macos both with the system clang, as well as with
GCC 14. With clang, remote-sim.c does not compile (per above) without
this patch. With GCC, it compiles with and without the patch (it
doesn't link, but AFAICT that is unrelated).
The clang bug is reported upstream at
https://github.com/llvm/llvm-project/issues/113511
Domani Johannes [Thu, 31 Oct 2024 12:40:04 +0000 (13:40 +0100)]
Prevent use-after-free of bfd filename in gdb_bfd_close_or_warn
On Windows gcore is not implemented, and if you try it, you get an
heap-use-after-free error:
(gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test
warning: cannot close "=================================================================
==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140
READ of size 111 at 0x1259ea503110 thread T0
#0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391
#1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558
#2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514
#3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41
#4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484
#5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106
#6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227
#7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571
#8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740
#9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73
#10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881
#11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181
#12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33
#13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437
#14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646
#15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
#16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
#17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
#18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176
0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0)
freed by thread T0 here:
#0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90
#1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187
#2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247
#3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180
#4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960
#5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925
#6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643
#7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739
#8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82
#9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91
#10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176
It happens because gdb_bfd_close_or_warn uses a bfd-internal name for
the failing-close warning, after the close is finished, and the name
already freed:
static int
gdb_bfd_close_or_warn (struct bfd *abfd)
{
int ret;
const char *name = bfd_get_filename (abfd);
for (asection *sect : gdb_bfd_sections (abfd))
free_one_bfd_section (sect);
ret = bfd_close (abfd);
if (!ret)
gdb_bfd_close_warning (name,
bfd_errmsg (bfd_get_error ()));
return ret;
}
Fixed by making a copy of the name for the warning.
Nelson Chu [Fri, 27 Oct 2023 00:39:17 +0000 (08:39 +0800)]
RISC-V: Dump instruction without checking architecture support as usual.
Since QEMU have supported -Max option to to enable all normal extensions,
the dis-assembler should also add an option, -M,max to do the same thing.
For the instruction, which have overlapped encodings like zfinx, will not
be considered by the -M,max option.
opcodes/
* riscv-dis.c (all_ext): New static boolean. If set, disassemble
without checking architectire string.
(riscv_disassemble_insn): Likewise.
(parse_riscv_dis_option_without_args): Recognized -M,max option.
binutils/
* NEWS: Updated.
Guinevere Larsen [Thu, 13 Jun 2024 18:34:26 +0000 (15:34 -0300)]
gdb: Update SECURITY.txt to mention extension scripts and internal errors
Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update
the gdb/SECURITY.txt to be more explicit about some details. Specifically,
we now explicitly say that internal errors aren't security
vulnerabilities, and mention that users should review plugins before
running them, and under which conditions a plugin can cause a security
bug.
Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Wed, 30 Oct 2024 12:30:51 +0000 (13:30 +0100)]
[gdb/tdep] Use std::array in amd64-windows-tdep.c
I noticed commit 84786372e1c ("Fix size of register buffer") fixing a
stack-buffer-overflow found by AddressSanitizer in
amd64_windows_store_arg_in_reg:
...
- gdb_byte buf[8];
+ gdb_byte buf[16];
...
and wondered if we could have found this without AddressSanitizer.
I realized that the problem is that this:
...
gdb_byte buf[N];
...
regcache->cooked_write (regno, buf);
...
is using the deprecated variant of cooked_write instead of the one using
gdb::array_view:
...
/* Transfer of pseudo-registers. */
void cooked_write (int regnum, gdb::array_view<const gdb_byte> src);
/* Deprecated overload of the above. */
void cooked_write (int regnum, const gdb_byte *src);
...
and consequently cooked_write does not know the size of buf.
Fix this by using std::array, and likewise in other places in
gdb/amd64-windows-tdep.c.
In the process I fixed another out of bounds access here:
...
gdb_byte imm16[2];
...
cache->prev_sp = cur_sp
+ extract_unsigned_integer (imm16, 4, byte_order);
...
where we're reading 4 bytes from the 2-byte buffer imm16.
Jan Beulich [Wed, 30 Oct 2024 11:12:54 +0000 (12:12 +0100)]
x86/APX: support JMPABS also in assembler
Without this APX support isn't really complete.
For Intel syntax displacement form is needed, such that symbolic
operands won't need prefixing by "offset". (The other form is actually
not used at all in Intel syntax.)
For the record: To restrict displacement form to Intel syntax is not
something I actually agree with.
Jan Beulich [Wed, 30 Oct 2024 11:12:24 +0000 (12:12 +0100)]
x86/APX: squash REX prefix when REX2 is being emitted
We should not (silently) emit a REX prefix ahead of a REX2-encoded insn;
such encodings are illegal. Best we can do is fold the REX bits into the
REX2 prefix, and then zap the REX one from i.prefix[].
Bernd Edlinger [Mon, 20 May 2024 05:12:30 +0000 (07:12 +0200)]
Fix signal unsafe call inside a signal
It can easily happen that the signal handler function
`handle_fatal_signal` uses various signal unsafe functions.
The problematic functions are `_` and `strsignal` which
can be pre-computed after the `setlocale` call is done.
Unfortunately when compiled with --disable-libbacktrace a
different code path is used, that calls the glibc function
`backtrace` which calls `malloc` and `free` and is therefore
also signal unsafe, that is probably unfixable, so there
is no attempt to fix anything in this code path.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
Hakan Candar [Mon, 28 Oct 2024 11:01:59 +0000 (11:01 +0000)]
ld/ELF: Add --image-base command line option to the ELF linker
LLD has dropped the option -Ttext-segment for specifying image base
addresses, instead forcing the use of the --image-base option for both
ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible,
having two different options for the same functionality.
This patch enables the use of --image-base on ELF targets, advancing
consistency and compatibility.
Moreover, a new test has been added to ensure -z separate-code behaviour
when used with -Ttext-segment stays the same. When this combination is
used, -Ttext-segment sets the address of the first segment (R), not the
text segment (RX), and like with -z noseparate-code, no segments lesser
than the specified address are created. If this behaviour was to change,
the first (R) segment of the ELF file would begin in a lesser address
than the specified text (RX) segment, breaking traditional use of this
option for specifying image base address.
Tom de Vries [Tue, 29 Oct 2024 09:08:04 +0000 (10:08 +0100)]
[gdb/symtab] Handle multiple .debug_info sections
When compiling dw2-multiple-debug-info.c using -gdwarf-5
-fdebug-types-section, we end with two .debug_info sections in the object
file:
...
$ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \
-gdwarf-5 \
-fdebug-types-section
$ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info
[10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8
[12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8
...
One of them contains the CU for dw2-multiple-debug-info.c, the other contains
the TU for the type of variable a.
When trying to print the type of variable a, we get:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
'a' has unknown type; cast it to its declared type
...
because the TU hasn't been read.
Fix this by adding support for reading multiple .debug_info sections, similar
to how that is done for multiple .debug_types sections, getting us instead:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
type = class sp1::A {
...
}
...
Ijaz, Abdul B [Thu, 4 Jan 2024 14:39:07 +0000 (15:39 +0100)]
fortran: Fix arrays of variable length strings for FORTRAN
Before this change resolve_dynamic_array_or_string was called for
all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end,
this function always called create_array_type_with_stride, which
creates a TYPE_CODE_ARRAY type.
Suppose we have
subroutine vla_array (arr1, arr2)
character (len=*):: arr1 (:)
character (len=5):: arr2 (:)
The "print arr1" and "print arr2" command at the "break-here" line
gives the following output:
(gdb) print arr1
$1 = <incomplete type>
(gdb) print arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = Type
End Type
(gdb) ptype arr2
type = character*5 (3)
Dwarf info using Intel® Fortran Compiler for such case contains following:
<1><fd>: Abbrev Number: 12 (DW_TAG_string_type)
<fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1
<102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8)
After this change resolve_dynamic_array_or_string now calls
create_array_type_with_stride or create_string_type, so if the
incoming dynamic type is a TYPE_CODE_STRING then we'll get back a
TYPE_CODE_STRING type. Now gdb shows following:
(gdb) p arr1
$1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij')
(gdb) p arr2
$2 = ('abcde', 'abcde', 'abcde')
(gdb) ptype arr1
type = character*10 (5)
(gdb) ptype arr2
type = character*5 (3)
In case of GFortran, compiler emits DW_TAG_structure_type for string type
arguments of the subroutine and it has only DW_AT_declaration tag. This
results in <incomplete type> in gdb. So, following issue is raised in gcc
bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826".
Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp,
i.e. the test forces the language to C/C++ and print a Fortran string value.
The string value is a dynamic type with code TYPE_CODE_STRING.
Before this commit the dynamic type resolution would always convert this to
a TYPE_CODE_ARRAY of characters, which the C value printing could handle.
But now after this commit we get a TYPE_CODE_STRING, which
neither the C value printing, or the generic value printing code can
support. And so, I've added support for TYPE_CODE_STRING to the generic
value printing, all characters of strings are printed together till the
first null character.
Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp
tests it expects type of character array in 'character (3)' format but now
after this change we get 'character*3', so tests are updated accordingly.
Jan Beulich [Tue, 29 Oct 2024 07:08:29 +0000 (08:08 +0100)]
gas: make fix_new_exp()'s "exp" parameter const
This really should be only an input; in particular it looks bogus that
O_add expressions are even altered. That altering and the recursion are
even pointless: Once expanding what the inner call would do (with
O_symbol) it becomes clear that this is no different than the default
case. Simplify the code accordingly, retaining the comment.
Jan Beulich [Tue, 29 Oct 2024 07:08:02 +0000 (08:08 +0100)]
gas: constify md_{short,long}opts and md_longopts_size
First of all make the declarations globally visible, such that producer
and consumer actually share them.
For the latter two simply add const (as PPC already had it,), while for
the former achieve the effect by converting to an array: There's no need
for the extra level of indirection.
Kito Cheng [Tue, 29 Oct 2024 00:37:35 +0000 (08:37 +0800)]
RISC-V: Update the doc to match ISA manual
ISA manual use funct* rather than func*[1] (e.g. funct7 rather than func7),
and I realized that may something I typo at beginning when I write the patch
for `.insn` support...:P
Hannes Domani [Mon, 28 Oct 2024 16:43:09 +0000 (17:43 +0100)]
Fix size of register buffer
When calling a function with double arguments, I get this asan error:
==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40
READ of size 16 at 0x0053131ece38 thread T0
#0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814
#1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845
#2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840
#3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874
#4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:914
#5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933
#6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216
Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame
#0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208
This frame has 4 object(s):
[32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable
It's because the first 4 double arguments are passed via XMM registers,
and they need a buffer of 16 bytes, even if we only use 8 bytes of them.
Hannes Domani [Sun, 27 Oct 2024 18:30:38 +0000 (19:30 +0100)]
Don't copy memory for arguments if there are none
If amd64_windows_push_arguments is called with no arguments, then ARGS
can be NULL, and inside the passed-by-pointer block, memcpy is called
with this NULL, which is undefined behavior.
So this just disable the passed-by-pointer block if there are no
arguments.
Fixes the following ubsan error:
C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null
Simon Marchi [Mon, 28 Oct 2024 17:56:02 +0000 (13:56 -0400)]
gdbserver: remove unused include in gdbthread.h
clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h,
which seems right, so remove it. Add it to two files that need it, but
were relying on the now-removed include.
This commit adds recording support for the AVX instruction vzeroupper,
which zeroes the high bits of ymm registers 0..15. In the programmer's
manual, it is explicitly states that ymm registers 16..31 won't be
affected if present, so we only need to record the first 16 registers.
We record ymm_h registers since only the higher bits are touched, and
that reduces the memory footprint of the instruction.
This instruction is tested differently as we want to confirm we're only
saving the relevant registers, and we want to ensure we're saving
all of them, so it makes use of "maint print record-instruction" to see
exactly what was recorded.
gdb/record: support AVX instructions VMOVDQ(U|A) when recording
This commit adds support for the instructions VMOVDQU and VMOVDQA, used
to move values to/from 256 bit registers. Unfortunately, the
programmer's manual is very incomplete (if not wrong) about these
instructions, so the logic had to be reverse engineered from how gcc
actually encodes the instruction.
This commit also changes the memory regions from the test to store 256
bits, so its easier to test the instructions and that we're recording
ymm registers correctly.
Guinevere Larsen [Thu, 13 Jun 2024 17:32:29 +0000 (14:32 -0300)]
gdb/record: Add recording support to vpbroadcast instructions
This commit adds recording support to all AVX and AVX2 instructions
of the form vpbroadcast. GDB is not yet concerned about AVX512 in
recording mode, so for now we only support the AVX2 registers and
instructions.
This commit also updates the gdb.reverse/i386-avx-reverse.exp to test
broadcast instructions.
Guinevere Larsen [Thu, 14 Mar 2024 14:24:36 +0000 (15:24 +0100)]
gdb/record: add support to AVX unpack instructions
This commit adds support to recording instructions to unpack high
or low data from XMM registers, identified by the mnemonics in the
form: VPUNPCK [L|H] [BW|WD|DQ|QDQ].
All these instructions are encoded the exact same way, and only affect
the destination register, making them trivial to implement together.
It also updates the test gdb.reverse/i386-avx-reverse.exp to test these
new instructions. The test always uses ymm because the vpunpck
instructions overwrite the high bits, so we have to be able to record
the full ymm register, not just the output size.
gdb/record: add support to vmovd and vmovq instructions
This commit adds support to the x86_64 AVX instructions vmovd and vmovq.
The programmers manuals for Intel and AMD describe these 2 instructions
as being almost the same, but my local testing, using gcc 13.2 on Fedora
39, showed several differences and inconsistencies.
The instruction is supposed to always use the 3-byte VEX prefix, but I
could only find 2-byte versions. The instructions aren't differentiated
by the VEX.w bit, but by opcodes and VEX.pp.
This patch adds a test with many different uses for both vmovd and
vmovq. It also updates the test gdb.reverse/step-precsave.exp to
reference the generic "missing avx support" bug open in the bug tracker
(17346), instead of pointing to one that specifically calls out to
vmovd instructions.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188 Approved-By: Tom Tromey <tom@tromey.com>
Guinevere Larsen [Thu, 14 Mar 2024 14:24:35 +0000 (15:24 +0100)]
gdb: Start supporting AVX instruction
This patch introduces the information needed to properly identify the
VEX prefix, used to signal an AVX and AVX2 instruction, and introduces
a helper function to handle all AVX instruction, instead of adding to
the 3000 line long recording function.
This new function will temporarily set the current thread as "not
executing" so that it can read from pseudo registers as we record, since
most AVX/AVX2 instructions would benefit from recording ymm registers.
The new helper also handles unsupported instructions so that the largest
part of the i386_process_record doesn't have to be shifted by 2 spaces,
which made an unreadably big patch file.
The only expected difference to the end user added by this patch is a
small change to the unsupported message. This patch also updates the
test gdb.reverse/step-precsave.exp, by recognizing the new output.
As a note for the future, we don't handle xmm16-31 and ymm16-31 because
those require the EVEX prefix, meaning avx512 support.
Guinevere Larsen [Wed, 19 Jun 2024 20:16:33 +0000 (17:16 -0300)]
gdb: Allow replayed threads to read and write pseudo registers
In an effort to support AVX instructions when recording, we need to
allow replaying threads to access pseudo registers. Currently, if
we try to do that gdb will fail in a call to validate_registers_access,
because the thread is executing so GDB thinks it is unsafe to read
pseudo registers.
When replaying, the thread is really executing for all intents and
purposes, but the execution is just having GDB change values on
registers, so it will always be safe to read and write pseudo registers.
This commit changes functions that check for register access to allow
access when we are replaying. The check to whether we are replaying must
not happen when writing a core file, as record_full_list could be nullptr,
so we only check it if the thread is executing.
As of this commit, I don't know of a way to trigger this commit without
AVX support on record, so a test isn't provided. However, as soon as
record-full supports saving ymm registers, the AVX tests will test this
as well.
Andrew Burgess [Sun, 27 Oct 2024 08:55:16 +0000 (08:55 +0000)]
gdb/testsuite: avoid intermittent failures on a debuginfod test
I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which
I could only produce one time.
Normally the test output looks like this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war
But one time I saw this:
file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug...
Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo...
(gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings
The difference is the "Downloading separate debug info for ..." line
has gained an extra '6.77 K' component. When I got the FAIL the
machine was under heavy load, so I suspect everything was running
pretty slow. I think the size is only added when the debuginfod
download is taking its time.
Anyway, the test in question is not expecting to see a size, which is
why it failed.
Every other debuginfod test does allow for an optional size being
printed, so lets update this test to also accept an optional size,
this should prevent failures like this in the future.
Tom de Vries [Sat, 26 Oct 2024 12:48:44 +0000 (14:48 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp
There are two test-cases that only run when the target board produces .dwp
files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp.
When running those test-cases with target board fission-dwp, I run into:
...
(gdb) ptype main^M
warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \
referenced by CU at offset 0xa6 [in module dwp-symlink]^M
type = <unknown return type> ()^M
(gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink
...
coming from:
...
# This case cannot work.
gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink"
...
I had a bit of difficulty understanding what the test-case does/tries to do,
so to build some understanding I reproduced the behaviour outside of the
test-case:
...
$ cat start.c
void _start (void) {}
$ gcc -gsplit-dwarf start.c -nostdlib
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ dwp -e a.out
$ rm start.dwo
$ gdb -q -batch a.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ ln -s a.out b.out
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ mv a.out.dwp b.out.dwp
$ gdb -q -batch b.out -ex "print _start"
$1 = {void (void)} 0x400144 <_start>
$ gdb -q -batch a.out -ex "print _start"
During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \
referenced by CU at offset 0x0 [in module a.out]
$1 = {<text variable, no debug info>} 0x400144 <_start>
...
and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp,
and there's no way to find b.out.dwp starting from a.out.
The fact that a FAIL is produced is incorrect, gdb does nothing wrong.
Fix this by checking for the warning text instead.
While we're at it, fix this PATH as well:
...
(gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M
Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M
(gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
PATH: gdb.dwarf2/dwp-symlink.exp: cd \
/data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink
...
While we're at it, use string_to_regexp to simplify the test-case.
Tested on x86_64-linux, with target board fission-dwp.
[gdb/testsuite] Fix some test-cases for check-read1 (-lbl)
I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem
is that by switching to line by line matching we now need to ensure
that the gdb_test_multiple patterns match up to the end of the line,
but don't actually include the trailing \r\n (yeah, our line by line
matching is weird). We need to be especially careful anywhere '.*' is
used as this can potentially match content on a subsequent line.
I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up
to the end of the line, but not the end of line itself, and I've made
use of '(?=\r\n)' in a couple of other places to ensure we match up to
the end of the line, but don't match the line terminator itself.
Tom de Vries [Sat, 26 Oct 2024 06:40:07 +0000 (08:40 +0200)]
[gdb] Don't create registry keys in destructor
Creating a registry key using emplace calls new:
...
DATA *result = new DATA (std::forward<Args> (args)...);
...
which can throw a bad alloc, which will terminate gdb if called from a
destructor.
Tom de Vries [Fri, 25 Oct 2024 10:48:18 +0000 (12:48 +0200)]
[gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexcept
Say we simulate a bad alloc in exceptions_state_mc_init:
...
jmp_buf *
exceptions_state_mc_init ()
{
+ {
+ static bool throw_bad_alloc = true;
+ if (throw_bad_alloc)
+ {
+ throw_bad_alloc = false;
+
+ va_list dummy;
+ throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
+ }
+ }
catchers.emplace_front ();
return &catchers.front ().buf;
}
...
After starting gdb and typing "q", gdb terminates:
...
$ gdb -q
(gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc'
what(): std::bad_alloc
...
because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on
gdb_rl_callback_read_char_wrapper_noexcept:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
struct gdb_exception gdb_expt;
/* C++ exceptions can't normally be thrown across readline (unless
it is built with -fexceptions, but it won't by default on many
ABIs). So we instead wrap the readline call with a sjlj-based
TRY/CATCH, and rethrow the GDB exception once back in GDB. */
TRY_SJLJ
...
Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to
gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function
that catches the bad alloc expection:
...
static struct gdb_exception
gdb_rl_callback_read_char_wrapper_noexcept () noexcept
{
try
{
return gdb_rl_callback_read_char_wrapper_sjlj ();
}
catch (gdb_exception &ex)
{
return std::move (ex);
}
}
...
getting us instead:
...
$ gdb -q
(gdb) bad alloc
(gdb) q
...
Tom de Vries [Fri, 25 Oct 2024 04:14:03 +0000 (06:14 +0200)]
[gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1
Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting
the output of skip_libstdcxx_probe_tests_prompt by making the used command
more precise: using "info probes stap libstdcxx" instead of "info probes".
Tom de Vries [Fri, 25 Oct 2024 04:14:03 +0000 (06:14 +0200)]
[gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1
Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by
using a custom line-by-line exp_continue clause:
...
-re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" {
exp_continue
}
...
which drops a line each time it finds two lines in the buffer.
This allows the other clauses to use two-line patterns.
Tom Tromey [Thu, 17 Oct 2024 23:16:54 +0000 (17:16 -0600)]
Add locking when reading BFD sections
This adds some per-BFD locking to gdb_bfd_map_section and
gdb_bfd_get_full_section_contents.
It turned out that the background DWARF reader could race with the
auto-load code, because the reader might try to mmap a section when
the main thread was trying to read in .debug_gdb_scripts.
The current BFD threading model is that only BFD globals will be
locked, so any multi-threaded use of a BFD has to be handled specially
by the application.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Tom Tromey [Thu, 17 Oct 2024 22:57:03 +0000 (16:57 -0600)]
Use gdb_bfd_get_full_section_contents in auto-load.c
This changes auto-load.c ot use gdb_bfd_get_full_section_contents.
This shouldn't change any behavior, but makes it easier to add locking
in a subsequent patch.
Alan Modra [Mon, 21 Oct 2024 01:46:31 +0000 (12:16 +1030)]
Replace uses of asprintf with xasprintf
xasprintf has a nicer interface and behaves like xmalloc as far as
memory is concerned, ie. no need to check a return status and the
program exits with an error on OOM.
gdb/testsuite: introduce dwarf5 option to gdb_compile
A few tests on the testsuite require dwarf5 to work. Up until now, the
way to do this was to explicitly add the command line flag -gdwarf-5.
This isn't very portable, in case a compiler requires a different flag
to emit dwarf5.
This commit adds a new option to gdb_compile that would be able to add
the correct flag (if known) or error out in case we are unable to tell
which flag to use. It also changes the existing tests to use this
general option instead of hard coding -gdwarf-5.
Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 18 Sep 2024 18:44:42 +0000 (12:44 -0600)]
Implement 'Object_Size
This patch started as an attempt to allow the 'Size attribute to be
applied to types, and not just objects.
However, that turns out to be difficult due to the Ada semantcs of
'Size. In particular, Ada requires 'Size to denote the size of the
representation of the value, so for example Boolean'Size must be 1.
Implementing this properly requires information not readily available
to gdb... and while we could synthesize this information in many
cases, it also seemed to me that this wasn't strictly very useful when
debugging.
So instead, this patch adds support for the 'Object_Size attribute,
which is somewhat closer to 'sizeof'.
Note also that while 'Object_Size is defined for some dynamic types, I
chose not to implement this here, as again this information is not
readily available -- and I think it's preferable to error than to
print something that might be incorrect.
Michael Matz [Mon, 21 Oct 2024 15:58:32 +0000 (17:58 +0200)]
stringmerge: don't presize hash table
originally the reason for pre-sizing was that that's easier
for a multi-threaded use of the hash table. That hasn't materialized
yet, so there's not much sense in using the very very conservative
estimates for pre-sizing. Doing the resize on-demand, whenever we
actually need to add a new entry doesn't change performance.
bfd/
merge.c (sec_merge_hash_insert): Resize as needed from here ...
(record_section): ... not from here. Don't calculate estimates,
return bool instead of three-state, regard all errors as soft
errors.
(_bfd_merge_sections): Adjust.
Stephan Rohr [Wed, 16 Oct 2024 08:42:27 +0000 (01:42 -0700)]
gdbserver: use 'gdb::function_view' in 'find_*' and 'for_each_*'
Remove the templated versions of 'find_thread', 'for_each_thread' and
'find_thread_in_random' and replace the template function argument with
'gdb::function_view'. The usage of 'gdb::function_view' produces less
cryptic messages on errors and documents well the types of the
parameters taken by the callback and its return type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Tue, 22 Oct 2024 07:23:26 +0000 (09:23 +0200)]
[gdb/testsuite] Handle maint set dwarf synchronous off default
I ran the testsuite with a patch setting dwarf_synchronous to false by
default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
not show up as a result of the file command.
Fix this by forcing "maint set dwarf synchronous on".
Add the same in gdb.base/index-cache.exp, where this is also required.
Tom de Vries [Tue, 22 Oct 2024 06:53:51 +0000 (08:53 +0200)]
[gdb] Handle EINTR in run_under_shell
When building gdb with -O2 -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
(gdb) c&^M
Continuing.^M
(gdb) Quit^M
(gdb) quit_count=1
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: $exp: no force memory write: \
SIGINT does not interrupt background execution
...
What happens is that:
- the breakpoint hits
- while evaluating the condition of the breakpoint,
$_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
- in run_under_shell, a vfork is issued
- in the vfork child, execl executes the kill command
- in the vfork parent, waitpid is called to wait for the result of the kill
command
- waitpid returns -1 with errno set to EINTR
- run_under_shell doesn't check the result of waitpid, and returns the
value of local variable status. Since waitpid returned -1, status was
not assigned a value, so it's uninitialized, and happens to be
non-zero
- the breakpoint condition evaluates to true, because
$_shell("kill -INT <pid-of-gdb>") != 0
- the breakpoint triggers a stop, which the test-case doesn't expect.
Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.
Also handle the case that waitpid returns an error other than EINTR, using
perror_with_name.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR gdb/30695
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
Lulu Cai [Thu, 17 Oct 2024 07:08:47 +0000 (15:08 +0800)]
LoongArch: Force relocation for every reference to the global offset table
Local absolute symbols are resolved at assembly stage and the symbol
value is placed in the relocation addend. But non-zero addend will
cause an assertion failure during linking.
Forces emission of relocations to defer resolution of local abs symbols
until link time.
bfd/
* elfnn-loongarch.c (loongarch_elf_relax_section): Determine
absolute symbols in advance to avoid ld crash.
gas/
* config/tc-loongarch.c (loongarch_force_relocation): New
function to force relocation.
* config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros
to force relocation.
(loongarch_force_relocation): Function declaration.
* testsuite/gas/loongarch/localpic.d: New test.
* testsuite/gas/loongarch/localpic.s: New test.
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
As gdbreplay communicates with GDB, it outputs all the remote
protocol communication it reads from the remotelogfile to stderr.
This patch disables this behavior by default but adds the new
--debug-logging option which turns printing the packets
to stderr on again.
The motivation for this change is to make it possible to use
gdbreplay with TCL tests. Printing the whole remotelog file out
seems to overflow the expect cache wich causes gdbreplay to not
to get the packet its expects and results in going out of sync
with GDB. Other motivation is making communication between GDB
and gdbreplay faster as printing bigger remotelogfile takes
considerable amount of time.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
