I build gdb with TSAN, and with test-case gdb.dwarf2/malformed-line-header.exp
ran into a heap-use-after-free:
...
(gdb) info line 1
==================
WARNING: ThreadSanitizer: heap-use-after-free (pid=897504)
Write of size 1 at 0x72040000d000 by main thread:
#0 dwarf_decode_line_header() gdb/dwarf2/line-header.c:356 (gdb+0xa0618c)
...
Previous write of size 8 at 0x72040000d000 by main thread:
#0 operator delete[](void*) <null> (libtsan.so.2+0xa6128)
#1 std::enable_if<std::is_convertible<unsigned char (*) [], unsigned char (*) []>::value, void>::type std::default_delete<unsigned char []>::operator()<unsigned char>(unsigned char*) const /usr/include/c++/15/bits/unique_ptr.h:134 (gdb+0xa08479)
#2 std::unique_ptr<unsigned char [], std::default_delete<unsigned char []> >::~unique_ptr() /usr/include/c++/15/bits/unique_ptr.h:685 (gdb+0xa07324)
#3 line_header::~line_header() gdb/dwarf2/line-header.h:86 (gdb+0xa0914a)
#4 std::default_delete<line_header>::operator()(line_header*) const /usr/include/c++/15/bits/unique_ptr.h:93 (gdb+0xa091a4)
#5 std::unique_ptr<line_header, std::default_delete<line_header> >::~unique_ptr() /usr/include/c++/15/bits/unique_ptr.h:399 (gdb+0xa07f18)
#6 dw2_get_file_names_reader gdb/dwarf2/read.c:1839 (gdb+0xa648ee)
...
Location is heap block of size 0 at 0x72040000d000 allocated by main thread:
#0 operator new[](unsigned long) <null> (libtsan.so.2+0xa6b01)
#1 dwarf_decode_line_header() gdb/dwarf2/line-header.c:354 (gdb+0xa06159)
...
This is caused by allocating a zero-sized array (lh->opcode_base == 0), and
writing to it:
...
lh->standard_opcode_lengths.reset (new unsigned char[lh->opcode_base]);
lh->standard_opcode_lengths[0] = 1; /* This should never be used anyway. */
...
Fix this by skipping this code if lh->opcode_base == 0.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When the DM registers were added, sorting of the table was broken. With
the present arrangement, this leads to (only) %dm0 not being found by the
binary search that both use sites of the table entertain.
I'm experiencing intermittent FAILs in fileio.exp when running on (my)
CI:
FAIL: gdb.base/fileio.exp: Open a file
FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST
FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
FAIL: gdb.base/fileio.exp: Writing to a file
...
The problem turned out to be the way the OUTDIR gets defined in fileio.c.
The path is passed down "naked" and turned into string by STRINGIFY macro.
However, if the path happens to contain name of unrelated pre-existing
C macro, this macro gets expanded during the "stringification", resulting
in (likely) different path than used in fileio.exp and therefore causing
failures.
For example, if the GDB is compiled and tested in directory
/var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu
then fileio.c is compiled with
-DOUTDIR_=/var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu/gdb/testsuite/outputs/gdb.base/fileio
But because there's also C macro named "linux" defined to 1, the resulting
OUTDIR is actually:
/var/lib/jenkins/workspace/binutils-gdb/build/x86_64-1-gnu/gdb/testsuite/outputs/gdb.base/fileio
This commit fixes this by defining the OUTDIR as string literal in first
place (similarly to how it was done prior commit cc91060) and updating
quote_for_host to handle strings that themselves contains quote (").
Tested on x86_64-linux by running all tests using quote_for_host with
both target board unix and host/target board local-remote-host-native.
Approved-By: Tom Tromey <tom@tromey.com>
I think this is a false positive as the "use" is reported at a
_bfd_link_reloc_status_error call, and the value passed is not used
except when bfd_reloc_dangerous. Avoid the warning anyway.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents):
Avoid false positive warning.
MIPS R5900 does not feature ceil/floor/round instructions, but only
ceil is correctly excluded at the moment. Correct the other two.
Signed-off-by: David Guillen Fandos <david@davidgf.net>
PR gdb/33761
* gdb/ui-style.c (colorsupport) [__MINGW32__]: MS-Windows always
supports at least 8 colors, even if the "Co" capability is not in
the terminfo DB. This fixes "set style FOO foreground COLOR"
commands in the Windows native build of GDB.
OK, so people want to be able to partly destroy gcc slim LTO object
files. I don't see why not, despite HJ's policy-setting slim lto
strip -R tests. I also don't see why it matters that objcopy/strip
won't similarly break LLVM objects (pr33271).
So out goes the slim lto strip -R tests, and the strip-debug test
expecting slim lto files won't be modified in any way. strip-debug
now removes a FILE symbol, which isn't unreasonable.
PR 33801
PR 33271
PR 33246
binutils/
* objcopy.c (copy_archive, copy_file): Do not special case
gcc LTO IR files.
ld/
* testsuite/ld-plugin/lto-binutils.exp: Remove slim lto strip -R
tests.
(run_pr33246_test): Don't compare slim object files after
strip-debug.
* testsuite/ld-plugin/strip-1a-s-all.nd: Delete.
Following the removal of gdbarch_sdb_reg_to_regnum,
i386_dbx_reg_to_regnum is only used by i386_svr4_dwarf_reg_to_regnum to
handle SSE and MMX registers. Remove it and inline the relevant bits in
i386_svr4_dwarf_reg_to_regnum.
Change-Id: Id74fad6ef6798c4cd061905f1c01eadd90e0a118
Approved-By: Andrew Burgess <aburgess@redhat.com>
Following the removal of the COFF debug info support,
gdbarch_sdb_reg_to_regnum is no longer used, remove it.
Change-Id: I2cb43465f1fdf74863edfa4dd00fd5f28a5a26bd
Approved-By: Andrew Burgess <aburgess@redhat.com>
These comments appear to be stale and no longer relevant.
Change-Id: I3470969b0c0f38d809fe074ffab93ac91202de18
Approved-By: Andrew Burgess <aburgess@redhat.com>
On s390x-linux (SLES 15 SP5), I'm running into:
...
FAIL: gdb.base/siginfo.exp: backtrace for nexti (pattern 2)
FAIL: gdb.base/siginfo.exp: step out of handler
...
The first FAIL is caused by a failure to unwind:
...
(gdb) bt^M
#0 handler (sig=26, info=0x3ffffffe428, context=0x3ffffffe4a8) at \
gdb.base/siginfo.c:31^M
Backtrace stopped: Cannot access memory at address 0x1a00000088^M
(gdb)
...
In contrast, on x86_64-linux I get instead:
...
(gdb) bt^M
#0 handler (sig=26, info=0x7fffffffc170, context=0x7fffffffc040) at \
gdb.base/siginfo.c:31^M
#1 <signal handler called>^M
#2 0x0000000000401201 in main () at gdb.base/siginfo.c:67^M
(gdb)
...
The memory access error is triggered here in s390_sigtramp_frame_unwind_cache:
...
/* Restore the previous frame's SP. */
prev_sp = read_memory_unsigned_integer (
info->saved_regs[S390_SP_REGNUM].addr (),
word_size, byte_order);
...
while trying to read an "Old-style RT frame" (for syscall sigreturn).
The problem is that we actually have a "New-style RT frame" (for syscall
rt_sigreturn).
[ See linux kernel source file arch/s390/kernel/signal.c for a detailed
explanation of the two. ]
The choice between the two is made earlier in that same function:
...
/* New-style RT frame:
retcode + alignment (8 bytes)
siginfo (128 bytes)
ucontext (contains sigregs at offset 5 words). */
if (next_ra == next_cfa)
{
...
}
/* Old-style RT frame and all non-RT frames:
old signal mask (8 bytes)
pointer to sigregs. */
else
...
I'm not sure why the check gives the wrong result, but I noticed that
s390_sigtramp_frame_sniffer is able to distinguish between the two, so fix
this by:
- factoring out new function s390_sigtramp_p out of
s390_sigtramp_frame_sniffer, and
- using s390_sigtramp_p in s390_sigtramp_frame_unwind_cache to distinguish
between the "Old-style RT frame" and "New-style RT frame".
This fixes the backtrace.
The second failure is:
...
(gdb) step^M
32 } /* handler */^M
1: x/i $pc^M
=> 0x1000772 <handler+50>: nopr^M
(gdb) step^M
0x000003fffdffe490 in __kernel_rt_sigreturn ()^M
1: x/i $pc^M
=> 0x3fffdffe490 <__kernel_rt_sigreturn>: svc 173^M
(gdb) FAIL: gdb.base/siginfo.exp: step out of handler
...
There is some code in process_event_stop_test that is supposed to trigger:
...
if (ecs->event_thread->control.step_range_end != 1
&& (ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
|| ecs->event_thread->control.step_over_calls == STEP_OVER_ALL)
&& get_frame_type (frame) == SIGTRAMP_FRAME)
{
infrun_debug_printf ("stepped into signal trampoline");
/* The inferior, while doing a "step" or "next", has ended up in
a signal trampoline (either by a signal being delivered or by
the signal handler returning). Just single-step until the
inferior leaves the trampoline (either by calling the handler
or returning). */
keep_going (ecs);
return;
}
...
but it doesn't because frame is a NORMAL_FRAME instead of a SIGTRAMP_FRAME.
This is caused by the "dwarf2" unwinder triggering, which has higher priority
than the "s390 linux sigtramp" unwinder:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
I found some code in dwarf2_frame_sniffer:
...
/* On some targets, signal trampolines may have unwind information.
We need to recognize them so that we set the frame type
correctly. */
if (fde->cie->signal_frame
|| dwarf2_frame_signal_frame_p (get_frame_arch (this_frame),
this_frame))
return self->type () == SIGTRAMP_FRAME;
...
and an example implementation i386_linux_dwarf_signal_frame_p, and after
copying this approach, indeed the stepping failure was fixed, but the
backtrace broken again.
Instead, fix this by giving the "s390 linux sigtramp" unwinder a higher
priority:
...
(gdb) maint info frame-unwinders
Name Type Class Enabled
dummy DUMMY_FRAME GDB Y
dwarf2 tailcall TAILCALL_FRAME DEBUGINFO Y
inline INLINE_FRAME GDB Y
jit NORMAL_FRAME EXTENSION Y
python NORMAL_FRAME EXTENSION Y
s390 linux sigtramp SIGTRAMP_FRAME ARCH Y
dwarf2 NORMAL_FRAME DEBUGINFO Y
dwarf2 signal SIGTRAMP_FRAME DEBUGINFO Y
s390 stub NORMAL_FRAME ARCH Y
s390 prologue NORMAL_FRAME ARCH Y
...
Also fixes test-case gdb.base/sigaltstack.exp and gdb.base/sigbpt.exp.
Tested on s390x-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR tdep/33708
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33708
aarch64-pe +FAIL: gas/aarch64/fix-adj
arm-pe +FAIL: MVE vmlas instructions
arm-wince-pe +FAIL: MVE vmlas instructions
These new tests use ELF directives.
* testsuite/gas/aarch64/fix-adj.d: Only run on ELF targets.
* testsuite/gas/arm/mve-vmlas.d: Likewise.
so that the memory can be reclaimed easily when reset_resolved_wilds
throws it all away.
* ldlang.c (matching_obstack): New static var.
(add_matching_section): Rewrite to use matching_obstack.
(lang_init): Init matching_obstack.
(reset_resolved_wilds): Free matching_obstack.
These are small, and making them inline lets me call
lang_statement_append without adding a forward declaration in the
next patch.
* ldlang.c (lang_for_each_statement, lang_list_init),
(lang_statement_append): Move to..
* ldlang.h: ..here making them inline functions.
(bfd_input_just_syms): Group with other inlines.
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change-Id: I92ba6b5ef9e9ab3d2ebe364373aeaf459fd6e34c
Approved-By: Tom Tromey <tom@tromey.com>
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change core_process_module_section's signature to take a cpms_data
reference instead of a void pointer.
Change-Id: Ic4f9a12c9c1479799ec87658fd88490106b61836
Approved-By: Tom Tromey <tom@tromey.com>
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Rename copy_sections to copy_section and change its signature to take
explicit parameters instead of the callback-style void pointer.
Change-Id: I30f1c3c051415722f2220b7fba48103101b640e8
Approved-By: Tom Tromey <tom@tromey.com>
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change-Id: If2e1141f2e9345fe50e2a63ce8f8682e82a60f21
Approved-By: Tom Tromey <tom@tromey.com>
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change-Id: I34182a67ee52da479c1868a5880709c401cbf34e
Approved-By: Tom Tromey <tom@tromey.com>
Replace bfd_map_over_sections with iteration over gdb_bfd_sections.
Change-Id: Ib236b364dc81f43cab8d27271d413eb61d6c703e
Approved-By: Tom Tromey <tom@tromey.com>
On aarch64-linux, I run into:
...
(gdb) info auxv^M
...
26 AT_HWCAP2 Extension of AT_HWCAP 0x181^M
29 ??? 0x0^M
31 AT_EXECFN File name of executable 0xffffffffffb9 ...
...
28 AT_RSEQ_ALIGN rseq allocation alignment 32^M
0 AT_NULL End of vector 0x0^M
(gdb) WARNING: Unrecognized tag value: 29 ... ??? ... 0x0^M
FAIL: gdb.base/auxv.exp: info auxv on live process
...
Fix this by handling AT_HWCAP3 in default_print_auxv_entry. Likewise for
AT_HWCAP4.
Tested on aarch64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32590
Since glibc 2.39, containing commit 3ab9b88 ("powerpc: Add HWCAP3/HWCAP4 data
to TCB for Power Architecture."), glibc's elf/elf.h contains constants
AT_HWCAP3/AT_HWCAP4.
Add these in elf/common.h.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This is a test-case to make sure that
8eb1701823
("gdb: fix loading compressed scripts from `.debug_gdb_scripts`-section")
doesn't regress.
The test was mostly implemented by Tom Tromey, with the exception of the
check to make sure that the sections are actually compressed and
corrected compiler flags (-Wl,--compress-debug-sections=zlib-gabi was
missing).
This is an individual patch since the actual fix already landed in the
repository.
Approved-By: Tom Tromey <tom@tromey.com>
Nothing seems to use this anymore. However, the private field is still
used internally by buildsym, so keep it.
Change-Id: Ie6fbd96110a3c5603359a483855bbecc4008e5b4
Approved-By: Tom Tromey <tom@tromey.com>
With the removal of the COFF debug info support, nothing uses
buildsym-legacy anymore, remove it.
Change-Id: I46612509889b6868f5889a4347ad8d0a28d29127
Approved-By: Tom Tromey <tom@tromey.com>
This patch removes support for reading in the COFF debug info.
I am not a specialist of the COFF format, but my understanding is that
debug info in the COFF format consisted of extra symbol table entries
describing the standard symbol table entries. For instance, when
compiling without debug info, a function would get a simple symbol
entry, akin to an ELF symbol. We would create a minimal symbol out of
that. When compiling with debug info, that symbol table entry would be
followed by special additional entries, describing things like
parameters and local variables (what would now be in DWARF). We would
create some full symbols out of that.
This patch removes everything that reads this extra information, on the
basis that any target still used today would not use it anymore, having
switched to DWARF instead. We still read the standard symbol table
entries and create minimal symbols out of that. This can be seen when
loading a Windows executable (the only COFF executable kind I know how
to produce):
$ ./gdb -nx -q --data-directory=data-directory -ex "set debug symtab-create 2" -ex "file a.exe"
...
[symtab-create] record_full: recording minsym: mst_file_bss 0x140008018 6 argv
[symtab-create] record_full: recording minsym: mst_file_bss 0x140008008 6 managedapp
[symtab-create] record_full: recording minsym: mst_text 0x1400013e0 0 WinMainCRTStartup
[symtab-create] record_full: recording minsym: mst_text 0x140001400 0 mainCRTStartup
[symtab-create] record_full: recording minsym: mst_text 0x140001420 0 atexit
[symtab-create] record_full: recording minsym: mst_file_data 0x140005000 3 __EH_FRAME_BEGIN__
[symtab-create] record_full: recording minsym: mst_file_bss 0x140008060 6 obj
...
[symtab-create] install: installing 299 minimal symbols of objfile /home/smarchi/src/binutils-gdb/gdb/a.exe
I did not and can't easily test more than that. At least, the remaining
code is understandable enough that I think we would be able to fix any
bug that comes up.
This change should not alter the debugging experience on Windows.
For more info on the COFF symbol table format:
https://www.delorie.com/djgpp/doc/coff/symtab.html
Change-Id: I83220589b8e5b242a4ac42a842e504a4aa47aada
Approved-By: Tom Tromey <tom@tromey.com>
Replace two uses of bfd_map_over_sections with an iteration over
gdb_bfd_sections.
Re-use cs_to_bfd_section in cs_section_address to simplify it.
Change-Id: I2b8f70cc1deba151b7b286affe78a43ac1a26375
Approved-By: Tom Tromey <tom@tromey.com>
This changes the tracepoint code to use make_unique_xstrdup (and
make_unique_xstrndup). This meant changing the types of some members
of uploaded_tp -- but it seems to me that using array types there did
not add any value.
Approved-By: Andrew Burgess <aburgess@redhat.com>
This replaces a number of uses of 'ptr.reset (xstrdup ())'
with 'ptr = make_unique_xstrdup ()'.
The main motivation for this is that, IMO, it's better to avoid the
reset method when possible.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Continuation of fix to VMLA
Bit 12 of the first halfword in the VMLAS instruction is listed as (0)
in the ARMARM (document DDI0553B.w, version ID07072023).
This means that the instruction does not discriminate between signed
and unsigned types and processing elements do not use the bit.
The encoding used by gas was based on an older version
of the document that made the sign important.
This change makes it possible to use vmlas.i8 (16,32) in addition to
vmlas.u8 and vmlas.s8 mnemonics, with the i8, i16 and i32 aliases becoming
the default when disassembling.
The generated encoding sets bit 12 to 0, compatibly with other
assembler implementations.
This patch adds support for MLB invalidate (MLBI) instruction.
Syntax: MLBI <mlbi_op>{, <Xt>}
This instruction is an alias to "SYS #4, C7, C0, #<op2>{, <Xt>}"
and MLBI being the preferred disassembly.
The following list of MLBI operations are supported in this patch for the
MLBI instructions enabled by "+mpamv2"
* alle1
* vmalle1
* vpide1
* vpmge1
