The current implementation of the fcc register is referenced to the
user_fp_state structure of the kernel uapi [1].
struct user_fp_state {
uint64_t fpr[32];
uint64_t fcc;
uint32_t fcsr;
};
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.
(gdb) info register
...
fcc0 0x1 1
fcc1 0x0 0
fcc2 0x0 0
fcc3 0x0 0
fcc4 0x0 0
fcc5 0x0 0
fcc6 0x0 0
fcc7 0x0 0
...
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h
[2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register
Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
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.
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.
Tested on x86_64-linux.
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.
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.
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).
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.
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.
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.
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.
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29449
While using perf top for MozillaThunderbird I noticed quite some slow
dissably call with source code involved. E.g.
time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C /usr/lib64/thunderbird/libxul.so
took 2.071s and I noticed quite some time is spent in
find_abstract_instance:
33.46% objdump objdump [.] find_abstract_instance
18.22% objdump objdump [.] arange_add
13.77% objdump objdump [.] read_attribute_value
4.82% objdump objdump [.] comp_unit_maybe_decode_line_info
3.10% objdump libc.so.6 [.] __memset_avx2_unaligned_erms
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.
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.
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.
Tested on x86_64-linux.
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 75337cbc14 ("[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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29436
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).
Symbol table:
[ 0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
...
Tested on x86_64-linux.
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.
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.
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.
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.
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];
...
Tested on x86_64-linux.
With commit 18a5766d09 ("[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.
Tested on x86_64-linux.
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)
...
Tested on x86_64-linux.
Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use
the task size to distribute similarly-sized chunks to the threads.
Tested on x86_64-linux.
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);
instead of:
auto lambda = [&] (int) { ... };
gdb::function_view<void (int)> fv = 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:
template<typename T>
void my_function (T v, gdb::function_view<void(T)> callback = nullptr);
For such a function, the type of the callback argument you pass must
already be a function_view. I.e., this wouldn't compile:
auto lambda = [&] (int) { ... };
my_function (1, lambda);
With gdb::make_function_view, you can write the call like so:
auto lambda = [&] (int) { ... };
my_function (1, gdb::make_function_view (lambda));
Unit tests included.
Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64
GNU/Linux, and running the unit tests.
Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626
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.)
* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Sanity check
.dynamic content buffer reads.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Likewise.
* elf.c (_bfd_elf_print_private_bfd_data): Simplify .dynamic
buffer sanity checks.
* elflink.c (elf_link_add_object_symbols): Avoid possible UB
subtracting sizeof_dyn from pointer.
Fixes a segfault found by the fuzzers.
* dwarf.c (fetch_indexed_value): Return -1 on error.
(read_and_display_attr_value): Don't display string when
fetch_indexed_value returns an error. Sanity check loc_offsets
index.
The commit 1369522f36 ("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.
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)
...
Following the same format as the implementation in ld:
9e2bb0cb5e
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.
elfcpp/
* elfcpp.h: Add FDO_PACKAGING_METADATA note type.
gold/
* Makefile.am: Add jansson flags and libraries.
* configure.ac: Check for jansson library.
* layout.cc (Layout::create_notes): Call create_package_metadata().
(Layout::create_package_metadata): New function.
* layout.h (Layout::create_package_metadata): New function.
(Layout::package_metadata_note_): New data member.
* options.h (class General_options): Add --package-metadata option.
* testsuite/Makefile.am (object_unittest): Add jansson libraries.
(binary_unittest): Likewise.
(leb128_unittest): Likewise.
(overflow_unittest): Likewise.
(package_metadata_test): New test.
* testsuite/package_metadata_main.c: New test source.
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.
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.
