When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
have:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004c4 in \
compdir_missing__ldir_missing__file_basename () \
at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
When trying to set a breakpoint on
compdir_missing__ldir_missing__file_basename, the architecture-specific
prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
... 00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
4004c0: 55 push %rbp
4004c1: 48 89 e5 mov %rsp,%rbp
4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
4004ca: 83 c0 01 add $0x1,%eax
4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
4004d3: 90 nop
4004d4: 5d pop %rbp
4004d5: c3 ret
...
And because the line table info is rudamentary:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004c0 x
tmp-dw2-dir-file-name.c 1000 0x4004d6 x
tmp-dw2-dir-file-name.c - 0x4004d6
...
the address does not fall at an actual line, so the breakpoint is shown with
address, both when setting it and hitting it.
when running the test-case with aarch64-linux, we have similarly:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
...
due to the architecture-specific prologue skipper starting at 0x400610 and
skipping past two insns, to 0x400618:
... 0000000000400610 <compdir_missing__ldir_missing__file_basename>:
400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400614: 9100b000 add x0, x0, #0x2c
400618: b9400000 ldr w0, [x0]
40061c: 11000401 add w1, w0, #0x1
400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400624: 9100b000 add x0, x0, #0x2c
400628: b9000001 str w1, [x0]
40062c: d503201f nop
400630: d65f03c0 ret
...
But interestingly, the aarch64 architecture-specific prologue skipper is
wrong. There is no prologue, and the breakpoint should be set at 0x400610.
By using "break *compdir_missing__ldir_missing__file_basename"
we can get the breakpoint set at 0x400610:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
...
and make the test-case independent of prologue analysis.
This requires us to update the expected patterns.
The fix ensures that once the aarch64 architecture-specific prologue skipper
will be fixed, this test-case won't start failing.
Lancelot SIX [Wed, 10 Aug 2022 21:23:29 +0000 (22:23 +0100)]
gdb/varobj: Only re-evaluate invalid globals during re_set
When doing varobj_re_set, we currently try to recreate floating varobj.
This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
of varobj_invalidate" to deal with use a after free issue. However
since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
never have dangling pointers so this all recreation is not strictly
needed anymore for floating varobjs.
This commit proposes to remove this recreation process for floating
varobjs.
Tom de Vries [Wed, 10 Aug 2022 21:23:28 +0000 (22:23 +0100)]
gdb/varobj: Reset varobj after relocations have been computed
[This patch is a followup to the discussion in
https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]
PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
test when using a compiler which does not produce a PIE executable by
default.
In the testcase, a varobj is created to track a global variable, and
then the main binary is reloaded in GDB (using the file command).
During the load of the new binary, GDB tries to recreate the varobj to
track the global in the new binary (varobj_invalidate_iter). At this
point, the old process is still in flight. So when we try to access to
the value of the global, in a PIE executable we only have access to the
unrelocated address (the objfile's text_section_offset () is 0). As a
consequence down the line read_value_memory fails to read the unrelated
address, so cannot evaluate the value of the global. Note that the
expression used to access to the global’s value is valid, so the varobj
can be created. When using a non PIE executable, the address of the
global GDB knows about at this point does not need relocation, so
read_value_memory can access the (old binary’s) value.
So at this point, in the case of a non-PIE executable the value field is
set, while it is cleared in the case of PIE executable. Later when the
test issues a "-var-update global_var", the command sees no change in
the case of the non-PIE executable, while in the case of the PIE
executable install_new_value sees that value changes, leading to a
different output.
This patch makes sure that, as we do for breakpoints, we wait until
relocation has happened before we try to recreate varobjs. This way we
have a consistent behavior between PIE and non-PIE binaries.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426 Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
Lancelot SIX [Thu, 11 Aug 2022 14:09:55 +0000 (15:09 +0100)]
gdb/varobj: Do not invalidate locals in varobj_invalidate_iter
The varobj_invalidate_iter function has logic to invalidate any local
varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use
after free in varobj" all varobj containing references to an objfile are
cleared when the objfile goes out of scope. This means that at this
point any local varobj seen by varobj_invalidate_iter either has
already been invalidated by varobj_invalidate_if_uses_objfile or only
contains valid references and there is no reason to invalidate it.
This patch proposes to remove this unnecessary invalidation and adds a
testcase which exercises a scenario where a local varobj can legitimately
survive a call to varobj_invalidate_iter.
At this point the varobj_invalidate and varobj_invalidate_iter seem
misnamed since they deal with re-creating invalid objects and do not do
invalidation, but this will be fixed in a following patch.
svstep and svshape instructions subtract 1 before encoding some of the
operands. Obviously zero is not supported for these operands. Whilst
PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be
incremented, there is no flag which marks the fact that zero values are
not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this
purpose.
This patch adds support for LibreSOC machine and SVP64 extension flag
for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm
Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit
Prefixed instruction format implementing SV. Funded by NLnet through EU
Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly
submitted via the OpenPOWER Foundation ISA Working Group via the
newly-created External RFC Process.
With this change, only valid contents of LR are accepted when unwinding
exception frames for m-profile targets.
If the contents of LR are anything but EXC_RETURN or FNC_RETURN, it
will cause GDB to print an error and/or abort unwinding of the frame as
it's an invalid state for the unwinder.
The FNC_RETURN pattern requires Security Extensions to be enabled.
Alan Modra [Thu, 11 Aug 2022 00:21:03 +0000 (09:51 +0930)]
PR29466, APP/NO_APP with .linefile
Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could
result in losing input. If scrubbing results in expansion past the
holding capacity of do_scrub_chars output buffer, then do_scrub_chars
stashes the extra input for the next call. That call never came
because sb_scrub_and_add_sb wrongly decided it was done. Fix that by
allowing sb_scrub_and_add_sb to see whether there is pending input.
Also allow a little extra space so that in most cases we won't need
to resize the output buffer.
sb_scrub_and_add_sb also limited output to the size of the input,
rather than the actual output buffer size. Fixing that resulted in a
fail of gas/testsuite/macros/dot with an extra warning: "end of file
not at end of a line; newline inserted". OK, so the macro in dot.s
really does finish without end-of-line. Apparently the macro
expansion code relied on do_scrub_chars returning early. So fix that
too by adding a newline if needed in macro_expand_body.
PR 29466
* app.c (do_scrub_pending): New function.
* as.h: Declare it.
* input-scrub.c (input_scrub_include_sb): Add extra space for
two .linefile directives.
* sb.c (sb_scrub_and_add_sb): Take into account pending input.
Allow output to max.
* macro.c (macro_expand_body): Add terminating newline.
* testsuite/config/default.exp (SIZE, SIZEFLAGS): Define.
* testsuite/gas/macros/app5.d,
* testsuite/gas/macros/app5.s: New test.
* testsuite/gas/macros/macros.exp: Run it.
In both the =breakpoint-modified and -break-info output, we have:
script={"aaa","bbb","ccc"}
According to the output syntax [1], curly braces means tuple, and a
tuple contains key=value pairs. This looks like it should be a list,
but uses curly braces by mistake. This would make more sense:
script=["aaa","bbb","ccc"]
Fix it, keeping the backwards compatibility by introducing a new MI
version (MI4), in exactly the same way as was done when fixing
multi-locations breakpoint output in [2].
- Add a fix_breakpoint_script_output uiout flag. MI uiouts will use
this flag if the version is >= 4.
- Add a fix_breakpoint_script_output_globally variable and the
-fix-breakpoint-script-output MI command to set it, if frontends want
to use the fixed output for this without using the newer MI version.
- When emitting the script field, use list instead of tuple, if we want
the fixed output (depending on the two criteria above)
-
The x0 (zero) register is read-only on RISC-V. Implement the
cannot_store_register gdbarch method to tell GDB this.
Without this method GDB will try to write to x0, and relies on the
target to ignore such writes. If you are using a target that
complains (or throws an error) when writing to x0, this change will
prevent this from happening.
The gdb.arch/riscv-reg-aliases.exp test exercises writing to x0, and
will show the errors when using a suitable target.
Luis Machado [Mon, 25 Jul 2022 23:17:38 +0000 (00:17 +0100)]
Disable year 2038 support on 32-bit hosts by default
With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.
Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.
As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.
This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.
This patch disables the year 2038 check for now, which makes things work
reliably again.
I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense. 64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.
Jan Beulich [Wed, 10 Aug 2022 08:30:46 +0000 (10:30 +0200)]
gas/Dwarf: properly skip zero-size functions
PR gas/29451
While out_debug_abbrev() properly skips such functions, out_debug_info()
mistakenly didn't. It needs to calculate the high_pc expression ahead of
time, in order to skip emitting any data for the function if the value
is zero.
The one case which would still leave a zero-size entry is when
symbol_get_obj(symp)->size ends up evaluating to zero. I hope we can
expect that to not be the case, otherwise we'd need to have a way to
post-process .debug_info contents between resolving expressions and
actually writing the data out to the file. Even then it wouldn't be
entirely obvious in which way to alter the data.
Alan Modra [Wed, 10 Aug 2022 01:08:52 +0000 (10:38 +0930)]
PR29462, internal error in relocate, at powerpc.cc:10796
Prior to the inline plt call support (commit 08be322439), the only
local syms with plt entries were local ifunc symbols. There shouldn't
be stubs for other local symbols so don't look for them. The patch
also fixes minor bugs in get_reference_flags; Many relocs are valid
only for ppc64 and a couple only for ppc32.
PR 29462
* powerpc.cc (Target_powerpc::Relocate::relocate): Rename
use_plt_offset to pltcal_to_direct, invert logic. For relocs
not used with inline plt sequences against local symbols, only
look for stubs when the symbol is an ifunc.
(Target_powerpc::Scan::get_reference_flags): Correct reloc
handling for relocs not valid for both 32-bit and 64-bit.
Youling Tang [Sat, 6 Aug 2022 06:49:43 +0000 (14:49 +0800)]
bfd: Add support for LoongArch64 EFI (efi-*-loongarch64).
This adds support for efi-loongarch64 by virtue of adding a new PEI target
pei-loongarch64. This is not a full target and only exists to support EFI at
this time.
This means that this target does not support relocation processing and is mostly
a container format. This format has been added to elf based loongarch64 targets
such that efi images can be made natively on Linux.
However this target is not valid for use with gas but only with objcopy.
We should't limit addresses to 32-bits for 64-bit vma, otherwise there will be
"RVA truncated" error when using objcopy on loongarch64.
With these changes the resulting file is recognized as an efi image.
Any magic number is based on the Microsoft PE specification [1].
The test results are as follows:
$ make check-binutils RUNTESTFLAGS='loongarch64.exp'
PASS: Check if efi app format is recognized
binutils
* testsuite/binutils-all/loongarch64/loongarch64.exp: New file.
* testsuite/binutils-all/loongarch64/pei-loongarch64.d: New test.
* testsuite/binutils-all/loongarch64/pei-loongarch64.s: New test.
include
* coff/loongarch64.h: New file.
* coff/pe.h (IMAGE_FILE_MACHINE_LOONGARCH64): New.
Change how "print/x" displays floating-point value
The problem is that when 501 is written to $ft0.float the value is
converted to floating point format and stored in the register. Prior
to the above commit printing with /x and /d would first extract the
value as a float, and then convert the value to an integer for
display. After the above commit GDB now uses the raw register value
when displaying /x and /d, and so we see this behaviour:
But it is mistakenly defined as a 64-bit fputype register, resulting
in a confusing output of "info register".
(gdb) info register
...
fcc {f = 0x0, d = 0x0} {f = 0, d = 0}
...
According to "Condition Flag Register" in "LoongArch Reference Manual"
[2], there are 8 condition flag registers of size 1. Use 8 registers of
uint8 to make it easier for users to view the fcc register groups.
Nick Clifton [Tue, 9 Aug 2022 13:57:48 +0000 (14:57 +0100)]
Default to enabling colored disassembly if output is to a terminal.
PR 29457
* objdump.c (disassembler_color): Change type to an enum.
(disassembler_extended_color): Remove.
(usage): Update.
(objdump_color_for_assembler_style): Update.
(main): Update initialisation of disassembler_color. If not
initialised via a command line option, set based upon terminal
output.
* doc/binutils.texi: Update description of disassmbler-color
option.
* testsuite/binutils-all/arc/objdump.exp: Add
--disassembler-color=off option when disassembling.
* testsuite/binutils-all/arm/objdump.exp: Likewise.
In AIX multiple threads were not added. This patch is a fix for the same
When we create a pthread debug session we have callbacks to read
symbols and memory. One of those call backs is pdc_read_data.
Before we come into aix-thread wait() we switch to no thread and
therefore the current thread is null.
When we get into pdc_read_data we have a dependency that we need to
be in the correct current thread that has caused an event of new
thread, inorder to read memory.
Hence we switch to the correct thread.
This is done by passing the pid in the pthdb_user_t user_current_pid
parameter in every call back.
Tom de Vries [Tue, 9 Aug 2022 13:12:05 +0000 (15:12 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/debug-names.exp
When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I
run into:
...
(gdb) maint info symtabs^M
...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab
...
Fix this by simplifying the test-case to print _start rather running to it.
Andrew Burgess [Tue, 9 Aug 2022 11:10:03 +0000 (12:10 +0100)]
gdb/riscv: use register name enum values in riscv-linux-nat.c
There were a few places where we were using integer values rather than
the RISCV_*_REGNUM constants defined in riscv-tdep.h. This commit
replaces 0 with RISCV_ZERO_REGNUM and 32 with RISCV_PC_REGNUM in a few
places.
There should be no user visible changes after this commit.
Jan Beulich [Tue, 9 Aug 2022 07:20:07 +0000 (09:20 +0200)]
x86-64: adjust MOVQ to/from SReg attributes
It is unclear to me why the corresponding MOV (no Q suffix) can be
issued without REX.W, but MOVQ has to have that prefix (bit). Add
NoRex64 and in exchange drop Size64.
Jan Beulich [Tue, 9 Aug 2022 07:19:36 +0000 (09:19 +0200)]
x86: adjust MOVSD attributes
The non-SSE2AVX form of the SIMD variant of the instruction needlessly
has the (still multi-purpose) IgnoreSize attribute. All other similar
SSE2 insns use NoRex64 instead. Make this consistent, noting that the
SSE2AVX form can't have the same change made - there the memory operand
doesn't at the same time permit RegXMM (which logic uses when deciding
whether a Q suffix is okay outside of 64-bit mode).
Jan Beulich [Tue, 9 Aug 2022 07:18:56 +0000 (09:18 +0200)]
x86: fold AVX VGATHERDPD / VPGATHERDQ
While the other three variants each differ in attributes and hence can't
be folded, these two pairs actually can be (and were previously
overlooked). This effectively matches their AVX512VL counterparts, which
are also expressed as a single template.
Jan Beulich [Tue, 9 Aug 2022 07:18:35 +0000 (09:18 +0200)]
x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insns
While the x/y/z suffix isn't necessary to use in this case, it is still
odd that these forms don't support broadcast (unlike their AVX512F /
AVX512DQ counterparts). The lack thereof can e.g. make macro-ized
programming more difficult.
Jan Beulich [Tue, 9 Aug 2022 07:18:04 +0000 (09:18 +0200)]
x86/Intel: split certain AVX512-FP16 VCVT*2PH templates
One more place where pre-existing templates should have been taken as a
basis: In Intel syntax we want to consistently issue an "ambiguous
operand size" error when a size-less memory operand is specified for an
insn where register use alone isn't sufficient for disambiguation.
Jiangshuai Li [Tue, 9 Aug 2022 02:13:57 +0000 (10:13 +0800)]
gdb/csky fix build error in ubuntu20_04
build error in: https://builder.sourceware.org/buildbot/#/builders/170/builds/246
...
../../binutils-gdb/gdb/csky-linux-tdep.c: In function ‘void
csky_supply_fregset(const regset*, regcache*, int, const void*, size_t)’:
../../binutils-gdb/gdb/csky-linux-tdep.c:194:18: error: format ‘%ld’
expects argument of type ‘long int’, but argument 2 has type ‘size_t’
{aka ‘unsigned int’} [-Werror=format=]
194 | warning (_("Unknow size %ld of section .reg2, can not get
value"
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
195 | " of float registers."), len);
...
Fix it via using %s vs pulongest suggested by Tom.
Tom Tromey [Mon, 8 Aug 2022 15:56:47 +0000 (09:56 -0600)]
Fix regression from gdbarch registry change
The gdbarch registry patch introduced a regression that could cause a
crash when opening files in gdb. The bug is that, previously, the
solib ops would default to current_target_so_ops; but the patch
changed this code to default to nullptr. This patch fixes the bug by
reintroducing the earlier behavior. This is PR gdb/29449.
I managed to reproduce the bug with a riscv-elf build and then
verified that this fixes the problem.
where linked list of CU is iterated when searing for where info_ptr
belongs to:
: 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
0.00 : 4c61f7: mov 0x10(%rbx),%rax
0.00 : 4c61fb: test %rax,%rax
0.00 : 4c61fe: je 4c6215 <find_abstract_instance+0x365>
: 3453 if (info_ptr >= u->info_ptr_unit && info_ptr < u->end_ptr)
0.00 : 4c6200: cmp 0x60(%rax),%rdx
83.20 : 4c6204: jb 4c620c <find_abstract_instance+0x35c>
0.00 : 4c6206: cmp 0x78(%rax),%rdx
6.89 : 4c620a: jb 4c6270 <find_abstract_instance+0x3c0>
: 3452 for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
0.00 : 4c620c: mov 0x10(%rax),%rax
7.90 : 4c6210: test %rax,%rax
0.00 : 4c6213: jne 4c6200 <find_abstract_instance+0x350>
The following scan can be replaced with search in a splay tree and with
that I can get to 1.5s and there are other symbols where the difference
is even bigger.
bfd/ChangeLog:
PR 29081
* dwarf2.c (struct addr_range): New.
(addr_range_intersects): Likewise.
(splay_tree_compare_addr_range): Likewise.
(splay_tree_free_addr_range): Likewise.
(struct dwarf2_debug_file): Add comp_unit_tree.
(find_abstract_instance): Use the splay tree when searching
for a info_ptr.
(stash_comp_unit): Insert to the splay tree.
(_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree.
Compilation unit at offset 920:
Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
Unit type: partial (3)
...
[ 3d3] variable abbrev: 31
name (strp) "__ioinit"
decl_file (data1) demo.C (10)
decl_line (data1) 6
decl_column (data1) 3
type (ref_udata) [ 3c4]
declaration (flag_present) yes
With the patch the same output is emitted as before usage of dwz.
bfd/ChangeLog:
PR 29442
* dwarf2.c (struct varinfo): Use const char * type.
(scan_unit_for_symbols): Call find_abstract_instance for
DW_AT_specification for variables that can be in a different CU
(e.g. done by dwz)
Jiangshuai Li [Mon, 8 Aug 2022 03:15:30 +0000 (11:15 +0800)]
gdb/csky support .reg2 for kernel 4.x and later
When kernel's version >= 4.x, the size of .reg2 section will be 400.
Contents of .reg2 are {
unsigned long vr[96];
unsigned long fcr;
unsigned long fesr;
unsigned long fid;
unsigned long reserved;
};
VR[96] means: (vr0~vr15) + (fr16~fr31), each Vector register is
128-bits, each Float register is 64 bits, the total size is
(4*96).
In addition, for fr0~fr15, each FRx is the lower 64 bits of the
corresponding VRx. So fr0~fr15 and vr0~vr15 regisetrs use the same
offset.
Tom de Vries [Sun, 7 Aug 2022 14:03:00 +0000 (16:03 +0200)]
[gdb/build] Fix build with gcc 4.8.5
When building with gcc 4.8.5, I run into:
...
user-regs.c:85:1: error: could not convert \
‘{0l, (& builtin_user_regs.gdb_user_regs::first)}’ from \
‘<brace-enclosed initializer list>’ to ‘gdb_user_regs’
};
^
...
Fix this by removing the initialization and handling regs.last == nullptr in
append_user_reg.
Tom de Vries [Sun, 7 Aug 2022 06:31:37 +0000 (08:31 +0200)]
[gdb/symtab] Fix assert in read_addrmap_from_aranges
When loading the debug-names-duplicate-cu executable included in this
test-case, we run into:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \
Assertion `insertpair.second' failed.^M
...
This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix
.debug_aranges duplicate offset warning").
The assert triggers because the CU table in the .debug_names section contains
a duplicate:
...
Version 5
Augmentation string: 47 44 42 00 ("GDB")
CU table:
[ 0] 0x0
[ 1] 0x0
...
Fix this by rejecting the .debug_names index:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
warning: Section .debug_names has duplicate entry in CU table, \
ignoring .debug_names.^M
...
Likewise for the case where the CU table is not sorted by increasing offset.
Tom de Vries [Sun, 7 Aug 2022 06:31:36 +0000 (08:31 +0200)]
[gdb/testsuite] Add support for .debug_names in dwarf assembler
Add:
- support for a per-module .debug_names section in the dwarf assembler, and
- a test-case excercising this new functionality.
A per-module .debug_names section needs to have an entry in the CU list for
each CU in the module, which is made more difficult by two things:
- linking in other objects, which may contain additional CUs
(typically the case on openSUSE), and
- adding dummy CUs in the dwarf assembler.
We handle this by:
- compiling with -nostartfiles (so the test-case contains _start rather than
main), and
- disabling the dummy CU generation for the test-case.
I've kept things simple by having the test-case specify the hash value, rather
than adding that functionality in the dwarf assembler.
Also I've kept the bucket count to 1, which makes it trivial to satisfy the
requirement that "the symbol is entered into a bucket whose index is the hash
value modulo bucket_count".
The readelf dump of the .debug_names section from the test-case looks like:
...
Version 5
Augmentation string: 47 44 42 00 ("GDB")
CU table:
[ 0] 0x0
TU table:
Foreign TU table:
Used 1 of 1 bucket.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).
Alan Modra [Sat, 6 Aug 2022 10:24:46 +0000 (19:54 +0930)]
asan: heap buffer overflow in _bfd_error_handler
On coff_slurp_symbol_table printing "unrecognized storage class"
for a symbol error. If the symbol name is the last string in its
section and not terminated, we run off the end of the buffer.
* coffgen.c (build_debug_section): Terminate the section with
an extra 0.
Alan Modra [Sat, 6 Aug 2022 07:35:44 +0000 (17:05 +0930)]
msan: bfd_mach_o_layout_commands use of uninitialised value
Catches fuzzed input with unterminated strings that later run off the
end of their buffers when calling strlen.
* mach-o.c: Use size_t vars where approprite.
(bfd_mach_o_alloc_and_read): Add "extra" param. Allocate that
much extra and clear. Update all callers, those that set up
strings with one extra byte.
Alan Modra [Sat, 6 Aug 2022 05:27:27 +0000 (14:57 +0930)]
objcopy section alignment
bfd_set_section_alignment currently always returns true. This patch
changes it to return false on silly alignment values, avoiding yet
another way to trigger ubsan errors like coffcode.h:3192:12: runtime
error: shift exponent 299 is too large for 32-bit type 'int'. We'll
catch that one in objcopy.c:setup_sections. However, setup_sections
gives up on other setup operations that are necessary even after an
error of some sort. Change that to keep going, which might change the
error message but that shouldn't matter in the least.
bfd/
* section.c (bfd_set_section_alignment): Return false and
don't set alignment_power for stupidly large alignments.
* bfd-in2.h: Regenerate.
* coffcode.h (coff_compute_section_file_positions): Don't use
an int constant when calculating alignment.
binutils/
* objcopy.c (setup_section): Keep on going after hitting
non-fatal errors.
Alan Modra [Thu, 4 Aug 2022 03:18:05 +0000 (12:48 +0930)]
Don't use BFD_VMA_FMT in gdb and sim
Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with
PRIx64 and casts to promote bfd_vma to uint64_t. The one file using
BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the
warning message is fixed.
Tom de Vries [Fri, 5 Aug 2022 15:31:43 +0000 (17:31 +0200)]
[gdb/build] Fix build breaker in language.c with gcc 7.5.0
When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into:
...
gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’:
gdb/language.c:921:8: error: use of deleted function \
‘language_arch_info::language_arch_info(const language_arch_info&)’
struct language_gdbarch
^~~~~~~~~~~~~~~~
In file included from gdbsupport/common-defs.h:104:0,
from gdb/defs.h:28,
from gdb/language.c:31:
gdb/language.h:95:28: note: declared here
DISABLE_COPY_AND_ASSIGN (language_arch_info);
^
include/ansidecl.h:342:3: note: in definition of macro \
‘DISABLE_COPY_AND_ASSIGN’
TYPE (const TYPE&) = delete; \
^~~~
gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’:
gdb/language.c:936:22: note: synthesized method ‘constexpr \
language_gdbarch::language_gdbarch()’ first required here
l = new struct language_gdbarch;
^~~~~~~~~~~~~~~~
...
This seems to be fixed by this change in the struct language_gdbarch
definition:
...
- struct language_arch_info arch_info[nr_languages] {};
+ struct language_arch_info arch_info[nr_languages];
...
Tom de Vries [Fri, 5 Aug 2022 14:12:56 +0000 (16:12 +0200)]
[gdb] Add unit test for gdb::sequential_for_each
With commit 18a5766d09c ("[gdbsupport] Add sequential_for_each") I added a
drop-in replacement for gdb::parallel_for_each, but there's nothing making
sure that the two remain in sync.
Extend the unit test for gdb::parallel_for_each to test both.
Do this using a slightly unusual file-self-inclusion. Doing so keep things
readable and maintainable, and avoids macrofying functions.
Tom de Vries [Fri, 5 Aug 2022 14:12:56 +0000 (16:12 +0200)]
[gdb/symtab] Use task size in parallel_for_each in dwarf2_build_psymtabs_hard
In dwarf2_build_psymtabs_hard, we use a parallel_for_each to distribute CUs
over threads.
Ensuring a fair distribution over the worker threads and main thread in terms
of number of CUs might not be the most efficient way, given that CUs can vary
in size.
Fix this by using per_cu->get_length () as the task size.
I've used this experiment to verify the performance impact:
...
$ for n in $(seq 1 10); do \
time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
2>&1 \
| grep "real:"; \
done
...
and without the patch got:
...
real: 4.71
real: 4.88
real: 4.29
real: 4.30
real: 4.65
real: 4.27
real: 4.27
real: 4.27
real: 4.75
real: 4.41
...
and with the patch:
...
real: 3.68
real: 3.81
real: 3.80
real: 3.68
real: 3.75
real: 3.69
real: 3.69
real: 3.74
real: 3.67
real: 3.74
...
so that seems a reasonable improvement.
With parallel_for_each_debug set to true, we get some more detail about
the difference in behaviour. Without the patch we have:
...
Parallel for: n_elements: 2818
Parallel for: minimum elements per thread: 1
Parallel for: elts_per_thread: 704
Parallel for: elements on worker thread 0 : 705
Parallel for: elements on worker thread 1 : 705
Parallel for: elements on worker thread 2 : 704
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 704
...
and with the patch:
...
Parallel for: n_elements: 2818
Parallel for: total_size: 1483674865
Parallel for: size_per_thread: 370918716
Parallel for: elements on worker thread 0 : 752 (size: 371811790)
Parallel for: elements on worker thread 1 : 360 (size: 371509370)
Parallel for: elements on worker thread 2 : 1130 (size: 372681710)
Parallel for: elements on worker thread 3 : 0 (size: 0)
Parallel for: elements on main thread : 576 (size: 367671995)
...
Pedro Alves [Fri, 5 Aug 2022 14:12:56 +0000 (16:12 +0200)]
Introduce gdb::make_function_view
This adds gdb::make_function_view, which lets you create a function
view from a callable without specifying the function_view's template
parameter. For example, this:
auto lambda = [&] (int) { ... };
auto fv = gdb::make_function_view (lambda);
It is particularly useful if you have a template function with an
optional function_view parameter, whose type depends on the function's
template parameters. Like:
Fuzzed input files with sizes of .dynamic not a multiple of dynamic
tag size can result in reading past the end of the buffer with the
current simple checks. Fix that, and use the same check in other
files that process input object .dynamic section. (There is no need
for buffer overflow checks in the linker's generated .dynamic
section.)
Tsukasa OI [Fri, 5 Aug 2022 09:52:09 +0000 (11:52 +0200)]
gas: fix a testcase broken by new ZSTD support
The commit 1369522f36eece1b37139a81f7f2139ba3915172 ("Recognize the new ELF
compression type for ZSTD.") added the new ELF compression type but it
accidentally broke a GAS testcase. Since testing for the section type
"2048" (SHF_COMPRESSED) is not going to be portable in the long term, it
now tests SHF_LINK_ORDER ("128") instead.
Using SHF_LINK_ORDER (with possibly sh_link == 0) is an idea by Jan Beulich.
gas/ChangeLog:
* testsuite/gas/elf/section10.s: Use SHF_LINK_ORDER to test
mixed numeric and alpha values.
* testsuite/gas/elf/section10.d: Reflect the change above.
Tom de Vries [Fri, 5 Aug 2022 06:09:57 +0000 (08:09 +0200)]
[gdb] Add debug_{exp,val}
When debugging cc1 I heavily rely on simple one-parameter debug functions
that allow me to inspect a variable of a common type, like:
- debug_generic_expr
- debug_gimple_stmt
- debug_rtx
and I miss similar functions in gdb.
Add functions to dump variables of types 'value' and 'expression':
- debug_exp, and
- debug_val.
Tested on x86_64-linux, by breaking on varobj_create, and doing:
...
(gdb) call debug_exp (var->root->exp.get ())
&"Operation: OP_VAR_VALUE\n"
&" Block symbol:\n"
&" Symbol: aaa\n"
&" Block: 0x2d064f0\n"
(gdb)
...
and:
...
(gdb) call debug_val (value)
&"5"
(gdb)
...
Generate a .note.package FDO package metadata ELF note, following
the spec: https://systemd.io/ELF_PACKAGE_METADATA/
If the jansson library is available at build time (and it is explicitly
enabled), link ld to it, and use it to validate that the input is
correct JSON, to avoid writing garbage to the file. The
configure option --enable-jansson has to be used to explicitly enable
it (error out when not found). This allows bootstrappers (or others who
are not interested) to seamlessly skip it without issues.
Cary Coutant [Fri, 5 Aug 2022 00:05:33 +0000 (17:05 -0700)]
Recognize the new ELF compression type for ZSTD.
There is more work to be done to actually support compression and
decompression using the zstd library, but I will leave that to the
champions of the new compression option.
binutils/
* binutils/readelf.c (process_section_headers): Add support for
ELFCOMPRESS_ZSTD.
Tom Tromey [Wed, 1 Jun 2022 21:31:15 +0000 (15:31 -0600)]
Use registry in gdbarch
gdbarch implements its own registry-like approach. This patch changes
it to instead use registry.h. It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.
The main benefit of this change is that it introduces type safety to
the gdbarch registry. It also removes a bunch of code.
One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup. This
doesn't seem very important to me, though.
Tom Tromey [Wed, 1 Jun 2022 20:52:28 +0000 (14:52 -0600)]
Allow registry to refer to const types
So far, the registry hasn't been used to refer to a 'const' type, but
this changes with the gdbarch change. This patch arranges to let the
registry store a pointer-to-const, by removing const in the 'set'
method.
Tom de Vries [Thu, 4 Aug 2022 17:56:06 +0000 (19:56 +0200)]
[gdb/testsuite] Fix .debug_aranges in gdb.dwarf2/fission-loclists.S
When running test-case gdb.dwarf2/fission-loclists.exp, I noticed:
...
warning: Section .debug_aranges in fission-loclists has duplicate \
debug_info_offset 0x8f, ignoring .debug_aranges.^M
...
Fix this by removing the duplicate .debug_aranges entry.
Tom de Vries [Thu, 4 Aug 2022 17:54:38 +0000 (19:54 +0200)]
[gdb/testsuite] Fix ERROR in gdb.base/watchpoint-unaligned.exp
In PR23888 an error is reported:
...
ERROR: tcl error sourcing watchpoint-unaligned.exp.
ERROR: expected boolean value but got ""
while executing
"if {$wpnum} {
...
This presumably happens when:
- skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported
- gdb fails to set a hw watchpoint and instead sets a sw watchpoint
That particular situation is handled for arm:
...
-re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" {
if {[istarget "arm*-*-*"]} {
untested $test
set wpnum 0
}
}
...
but not for any other targets so wpnum remains "", triggering the ERROR.
Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9
add test for HW watchpoint support."), but it's still possible for other
targets.
Fix this by:
- initializing wpnum to 0 instead of ""
- signalling the failure to set a hw watchpoint by a fail
Tested on x86_64-linux, also by adding:
...
gdb_test_no_output "set can-use-hw-watchpoints 0"
...
and verifying that it triggers the fail.
Tom de Vries [Thu, 4 Aug 2022 13:23:34 +0000 (15:23 +0200)]
[gdb/tdep] Fix gdb.base/large-frame.exp for aarch64
On aarch64, I run into:
...
FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace
...
The problem is that the architecture-specific prologue analyzer fails to
handle the first two insns in the prologue properly:
... 0000000000400610 <func>:
400610: d2880210 mov x16, #0x4010
400614: cb3063ff sub sp, sp, x16
400618: a9007bfd stp x29, x30, [sp]
40061c: 910003fd mov x29, sp
400620: 910043a0 add x0, x29, #0x10
400624: 97fffff0 bl 4005e4 <blah>
...
so we get:
...
$ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func"
Breakpoint 1 at 0x400614
...
Fix this by:
- fixing the support for the first insn to extract the immediate operand, and
- adding support for the second insn,
such that we have:
...
Breakpoint 1 at 0x400624
...
Note that we're overshooting by one insn (0x400620 is the first insn after the
prologue), but that's a pre-existing problem.
Alan Modra [Thu, 4 Aug 2022 02:52:39 +0000 (12:22 +0930)]
Don't use BFD_VMA_FMT in binutils
BFD_VMA_FMT can't be used in format strings that need to be
translated, because the translation won't work when the type of
bfd_vma differs from the machine used to compile .pot files. We've
known about this for a long time, but patches slip through review.
So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64,
PRIu64, PRIx64 or PRIo64 and SCN variants for scanf. The patch is
mostly mechanical, the only thing requiring any thought is casts
needed to preserve PRId64 output from bfd_vma values, or to preserve
one of the unsigned output formats from bfd_signed_vma values.
Alan Modra [Thu, 4 Aug 2022 00:42:51 +0000 (10:12 +0930)]
Re: Get rid of fprintf_vma and sprintf_vma
Commit f493c2174e messed the formatting in linker map files,
particularly for 32-bit builds where a number of tests using map files
regressed. I should have noticed the BFD64 conditional printing of
spaces to line up output due to the original %V printing hex vmas with
16 digits when BFD64 and 8 digits when not. Besides that, it is nicer
to print 32-bit vmas for 32-bit targets. So change %V back to be
target dependent, now using bfd_sprintf_vma. Since minfo doesn't
return the number of chars printed, that means some places that
currently use %V must instead sprintf to a buffer in order to find the
length printed.
* ldmisc.h (print_spaces): Declare.
(print_space): Change to a macro.
* ldmisc.c (vfinfo): Use bfd_sprintf_vma for %V. Tidy %W case.
(print_space): Delete.
(print_spaces): New function.
* emultempl/aix.em (print_symbol): Use print_spaces.
* ldctor.c (ldctor_build_sets): Likewise.
* ldmain.c (add_archive_element): Likewise.
* ldlang.c (print_one_symbol, lang_print_asneeded): Likewise.
(print_output_section_statement, print_data_statement): Likewise.
(print_reloc_statement, print_padding_statement): Likewise.
(print_assignment): Likewise. Also replace %V printing of vmas
with printing to a buffer in order to properly format output.
(print_input_section, lang_one_common): Likewise.
Tom Tromey [Tue, 2 Aug 2022 18:01:01 +0000 (12:01 -0600)]
Use unique_ptr to destroy per-bfd object
In some cases, the objfile owns the per-bfd object. This is yet
another object that can sometimes be destroyed before the registry is
destroyed, possibly reslting in a use-after-free. Also, I noticed
that the condition for deleting the object is not the same as the
condition used to create it -- so it could possibly result in a memory
leak in some situations. This patch fixes the problem by introducing
a new unique_ptr that holds this object when necessary.
Tom Tromey [Tue, 2 Aug 2022 17:57:20 +0000 (11:57 -0600)]
Use auto_obstack in objfile
This changes objfile to use an auto_obstack. This helps prevent
use-after-free bugs, because it ensures that anything allocated on the
objfile obstack will live past the point at which the registry object
is destroyed.
Tom Tromey [Tue, 2 Aug 2022 15:55:32 +0000 (09:55 -0600)]
Use gdb_bfd_ref_ptr in objfile
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series. The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed. This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.
Alan Modra [Wed, 3 Aug 2022 12:31:57 +0000 (13:31 +0100)]
Fix a conflict between the linker's need to rename some PE format input libraries and the BFD library's file caching mechanism.
PR 29389
bfd * bfd.c (BFD_CLOSED_BY_CACHE): New bfd flag.
* cache.c (bfd_cache_delete): Set BFD_CLOSED_BY_DELETE on the
closed bfd.
(bfd_cache_lookup_worker): Clear BFD_CLOSED_BY_DELETE on the newly
reopened bfd.
* opncls.c (bfd_set_filename): Refuse to change the name of a bfd
that has been closed by bfd_cache_delete. Mark changed bfds as
uncacheable.
* bfd-in2.h: Regenerate.
ld * ldlang.h (lang_input_statement_struct): Add sort_key field.
* emultempl/pe.em (after_open): If multiple import libraries refer
to the same bfd, store their names in the sort_key field.
* emultempl/pep.em (after_open): Likewise.
* ldlang.c (sort_filename): New function. Returns the filename to
be used when sorting input files.
(wild_sort): Use the sort_filename function.
Lancelot SIX [Tue, 2 Aug 2022 12:14:20 +0000 (13:14 +0100)]
gdb: Fix regression in varobj recreation
Commit bc20e562ec0 "Fix use after free in varobj" introduced a
regression. This commit makes sure that the varobj object does not
keeps stale references to object being freed when we unload an objfile.
This includes the "valid_block" field which is reset to nullptr if the
pointed to block is tied to an objfile being freed.
However, at some point varobj_invalidate_iter might try to recreate
varobjs tracking either floating or globals. Varobj tracking globals
are identified as having the "valid_block" field set nullptr, but as bc20e562ec0 might clear this field, we have lost the ability to
distinguish between varobj referring to globals and non globals.
Fix this by introducing a "global" flag which tracks if a given varobj
was initially created as tracking a global.
Alan Modra [Wed, 3 Aug 2022 05:36:15 +0000 (15:06 +0930)]
Re: PE objdump -x
All of these buffer overrun tests are better written as a comparison
against size remaining, due to ISO C 9899 standard 6.5.2 para 8
regarding adding a constant to a pointer:
"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior
is undefined."
So "ex_dta + 4" might be undefined behaviour, if you interpret "the
array object" in this case to be the malloc'd section contents!
- Drop the rounding type check: We're past template matching, and none
of the involved insns support embedded rounding.
- Drop the extension opcode check: None of the involved opcodes have
variants with it being other than None.
- Instead check opcode space, even if just to be on the safe side going
forward.
- Reduce the number of comparisons by folding two groups.
Jan Beulich [Wed, 3 Aug 2022 06:59:46 +0000 (08:59 +0200)]
x86: also use D for MOVBE
First of all rename the meanwhile misleading Opcode_SIMD_FloatD, as it
has also been used for KMOV* and BNDMOV. Then simplify the condition
selecting which form if "reversing" to use - except for the MOV to/from
control/debug/test registers all extended opcode space insns use bit 0
(rather than bit 1) to indicate the direction (from/to memory) of an
operation. With that, D can simply be set on the first of the two
templates, while the other can be dropped.
projects / thirdparty / binutils-gdb.git / log
