non_mangled incorrectly returned "true" for Ada. Correct that, and
add a few more non-mangled entries. Return a value suitable for
passing to cplus_demangle to control demangling.
* dwarf2.c: Include demangle.h.
(mangle_style): Rename from non_mangled. Return DMGL_* value
to suit lang. Adjust all callers.
The "sec" field in these structures is only set and used in lookup
functions. It always starts off as NULL. So the only possible effect
of the field is to modify the return of the lookup, which was its
purpose back in 2005 when HJ fixed PR990. Since then we solved the
problem of relocatable object files with the fix for PR2338, so this
field is now redundant.
* dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
(lookup_symbol_in_function_table): Don't set or test "sec".
(lookup_symbol_in_variable_table): Likewise.
(info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.
Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through
bfd/warning.m4), not AC_SUBSTing the variable causes minor issues.
Fortunately, it didn't cause severe errors but error messages related to
@CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed
to subdirectories through Makefile) remain in config.log.
To avoid invalid invocation of preprocessor for build environment, we
need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to
subdirectories that need it. This is what this commit does.
ChangeLog:
* configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories.
* configure: Regenerate.
This patch support ZTSO extension. It will turn on the tso flag for elf_flags
once we have enabled Ztso extension. This is intended to implement v0.1 of
the proposed specification which can be found in Chapter 25 of,
https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.
bfd\ChangeLog:
* elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag.
* elfxx-riscv.c: Add Ztso's arch.
binutils\ChangeLog:
* readelf.c (get_machine_flags): Set TSO flag.
gas\ChangeLog:
* config/tc-riscv.c (riscv_set_tso): Ditto.
(riscv_set_arch): Ditto.
* testsuite/gas/riscv/ztso.d: New test.
include\ChangeLog:
* elf/riscv.h (EF_RISCV_TSO): Ditto.
Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now,
3b1450b38c
And the psabi already deprecate the CALL reloc,
a0dced8501
Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if
it has @plt postfix. I believe LLVM (https://reviews.llvm.org/D132530) already
support this, so GNU as should do the same thing.
gas/
* config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for
call, even if it has @plt postfix.
* testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT.
* testsuite/gas/riscv/relax-reloc.d: Likewise.
ld/
* testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.
The last patch wasn't all that shiny. There are rather a lot more
relocations that can hit the assertion in md_apply_fix if the symbol
is local or absolute. Fix them all.
* config/tc-ppc.c (ppc_force_relocation): Add all relocs that
expect a symbol in md_apply_fix. Remove tls pcrel relocs
already covered in general tls match range.
The direct cause for the looping was failing to test for error return
from _bfd_vms_get_object_record inside a while(1) loop. Fix that.
Also record status of first alpha_vms_slurp_relocs call and return
that for all subsequent calls. (The object format has one set of
relocation records for all sections.) If the first call fails, all
others should too.
* vms-alpha.c (struct vms_private_data_struct): Make reloc_done
a tri-state int.
(alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on
failure. Return that status on subsequent calls. Check
_bfd_vms_get_object_record return status.
(alpha_vms_get_reloc_upper_bound): Return status from
alpha_vms_slurp_relocs.
(alpha_vms_write_exec): Exclude sections with contents NULL due
to previous errors from layout, and don't try to write them.
This changes some target_so_ops instances to be const. This makes
their use a little more obvious (they can't be mutated) and also
allows for the removal of some initialization code.
This changs solib_ops to be an ordinary gdbarch value and updates all
the uses. This removes a longstanding FIXME and makes the code
somewhat cleaner as well.
We currently have a single test for GDB's debuginfod support, this is
gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
setup, starts debuginfod, and then does the testing.
This commit tries to split the existing script in two, there is a new
library lib/debuginfod-support.exp, which contains a helper functions
related to running debuginfod tests. All the code in the new library
is basically copied from the existing test case (which is why I
retained the copyright date range on the new library), with some minor
adjustments to try and make the code a little more generic.
One change I made, for example, is the library offers functions to
shut down debuginfod, previously we just relied on expect shutting
down debuginfod when dejagnu completed.
The existing test script is updated to make use of the new library
code, and this test is still passing for me. The only change in the
test results is a single test where I changed the name to remove the
port number from the test name - the port number can change from run
to run, so could make it hard to compare test results.
I have also done a little light house keeping on the original test
script, updating and adding new comments, and making use of
proc_with_prefix in a couple of places.
loongarch_elf_finish_dynamic_symbol is called after elf_link_sort_relocs
if -z combreloc. elf_link_sort_relocs redistributes the contents of
.rela.* sections those would be merged into .rela.dyn, so the slot for
R_LARCH_IRELATIVE may be out of relplt->contents now.
To make things worse, the boundary check
dyn < dyn + relplt->size / sizeof (*dyn)
is obviously wrong ("x + 10 < x"? :), causing the issue undetected
during the linking process and the resulted executable suddenly crashes
at runtime.
The issue was found during an attempt to add static-pie support to the
toolchain.
Fix it by iterating through the inputs of .rela.dyn to find the slot.
Local ifuncs are always resolved at runtime via R_LARCH_IRELATIVE, so
there is no need to write anything into GOT. And when we write the GOT
we actually trigger a heap-buffer-overflow: If a and b are different
sections, we cannot access something in b with "a->contents + (offset
from a)" because "a->contents" and "b->contents" are heap buffers
allocated separately, not slices of a large buffer.
So stop writing into GOT for local ifunc now.
I see this error when building with clang,
CXX gdb_bfd.o
gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
const std::string str = string_vprintf (fmt, ap_copy);
^~~
1 error generated.
This patch adds missing ATTRIBUTE_PRINTF to fix the error.
Tested on x86_64-linux with gcc 12 and clang 14.
With the test-case included in this commit, we run into this FAIL:
...
(gdb) p var^M
During symbol reading: file index out of range^M
$1 = 0^M
(gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints
...
This is a regression since commit 6d263fe46e ("Avoid bad breakpoints with
--gc-sections"), which contains this change in read_file_scope:
...
- handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+ if (lowpc != highpc)
+ handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
...
The change intends to avoid a problem with a check in
lnp_state_machine::check_line_address, but also prevents the file and dir
tables from being read, which causes the complaint.
Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the
call to dwarf_decode_lines in handle_DW_AT_stmt_list.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561
This commit adds a GDB test case which tests GDB's BFD error handler
hook for suppressing output of all but the first identical messages.
See the comment at the beginning of bfd-errors.exp for details about
this new test.
I've tested this test for both 32- and 64-bit ELF files and also
on both little endian and big endian machines. It also works for
both native and remote targets. The only major restriction is that
it only works for ELF targets.
This commit adds a hook to the BFD error handler for suppressing
identical messages which have been output once already.
It's motivated by this Fedora bug...
https://bugzilla.redhat.com/show_bug.cgi?id=2083315
...in which over 900,000 BFD error messages are output when attaching
to firefox. From the bug report, the messages all say:
BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38)
Since there's no (additional) context which might assist the user in
determining what's wrong, there's really no point in outputting more
than one message. Of course, if BFD should output some
other/different message, it should be output too, but all future
messages identical to those already output should be suppressed.
For the firefox problem, it turned out that there were only 37
sections, but something was referring to section #38. I haven't
investigated further to find out how this came to be.
Despite this problem, useful debugging might still be done, especially
if the user doesn't care about debugging the problematic library.
If it turns out that knowing the quantity of messages might be useful,
I've implemented the suppression mechanism by keeping a count of each
identical message. A new GDB command, perhaps a 'maintenance'
command, could be added to print out each message along with the
count. I haven't implemented this though because I'm not convinced of
its utility. Also, the BFD message printer has support for BFD-
specific format specifiers. The BFD message strings that GDB stores
in its map are sufficient for distinguishing messages from each
other, but are not identical to those output by BFD's default error
handler. So, that problem would need to be solved too.
With the test-case included in the patch, we run into:
...
(gdb) info types -q std::nullptr_t^M
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M
^M
File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M
2198: typedef decltype(nullptr) std::nullptr_t;^M
(gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \
without complaint
...
Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify
in the test-case using "maint print symbols" that the symbol exists.
Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271
On a powerpc system with gcc 12 built to default to 128-bit IEEE long double,
I run into:
...
(gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M
$8 = 0 + 0i^M
(gdb) FAIL: gdb.base/varargs.exp: print \
find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)
...
This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param.
Fix this and similar cases, and expand the test-case to test handling of
homogeneous aggregates.
Tested on ppc64le-linux, power 10.
Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
Tested-by: Carl Love <cel@us.ibm.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543
[ Another attempt at fixing the problem described in commit cd919f5533
("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ]
When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with
aarch64-linux, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \
tmp-dw2-dir-file-name.c:999^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x400608 starts at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x400608 x
tmp-dw2-dir-file-name.c 1000 0x40062c x
tmp-dw2-dir-file-name.c - 0x40062c
...
and therefore the breakpoint is printed without instruction address.
In contrast, for x86_64-linux, we have the breakpoint printed with instruction
address:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x004004c1 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
...
The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x004004c1 doesn't start at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004bd x
tmp-dw2-dir-file-name.c 1000 0x4004d3 x
tmp-dw2-dir-file-name.c - 0x4004d3
...
Fix this by:
- unifying behaviour between the archs by adding an explicit line number entry
for the address compdir_missing__ldir_missing__file_basename_label, making
the FAIL reproducible on x86_64-linux.
- expecting the breakpoint to be printed without instruction address.
Tested on x86_64-linux and aarch64-linux.
In completion tests in various test-cases, we've been running into these
"clearing input line" timeouts:
...
(gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd"
FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout)
...
where $cmd == "maintenance selftest name_that_does_not_exist".
AFAIU, the following scenario happens:
- expect sends "$cmd\t"
- gdb detects the stdin event, and calls rl_callback_read_char until it
comes to handle \t
- readline interprets the \t as completion, tries to complete, fails to do so,
outputs a bell (^G)
- expect sees the bell, and proceeds to send ^C
- readline is still in the call to rl_callback_read_char, and stores the
signal in _rl_caught_signal
- readline returns from the call to rl_callback_read_char, without having
handled _rl_caught_signal
- gdb goes to wait for the next event
- expect times out waiting for "Quit", the expected reaction for ^C
Fix this by handling pending signals after each call to rl_callback_read_char.
The fix is only available for readline 8.x, if --with-system-readline provides
an older version, then the fix is disabled due to missing function
rl_check_signals.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813
Not that anyone would want to indirect via the GOT when an address can
be loaded directly with pla, the following:
pld 3,x@got@pcrel
x:
leads to "Internal error in md_apply_fix", because the generic parts
of assembler fixup handling convert the fx_pcrel fixup to one without
a symbol. Stop that happening.
* config/tc-ppc.c (ppc_force_relocation): Add PLT_PCREL34 and
assorted GOT_PCREL34 relocs.
Clang generates a warning on unused (technically, written but not read
thereafter) variables. By the default configuration (with "-Werror"), it
causes a build failure (unless "--disable-werror" is specified).
This commit adds ATTRIBUTE_UNUSED attribute to some of them, which means
they are *possibly* unused (can be used but no warnings occur when
unused) and removes others.
bfd/ChangeLog:
* elf32-lm32.c (lm32_elf_size_dynamic_sections): Mark unused
rgot_count variable.
* elf32-nds32.c (elf32_nds32_unify_relax_group): Remove unused
count variable.
* mmo.c (mmo_scan): Mark unused lineno variable.
binutils/ChangeLog:
* windmc.c (write_rc): Remove unused i variable.
gas/ChangeLog:
* config/tc-riscv.c (riscv_ip): Remove unused argnum variable.
ld/ChangeLog:
* pe-dll.c (generate_reloc): Remove unused bi and page_count
variables.
mach-o.c doesn't sanity check mach-o-fat archives, making it easy for
fuzzers to create an archive with mach_o_fat_archentry headers that
point to the same offset. bfd_mach_o_fat_openr_next_archived_file
uses the previous element offset to find its header, and thus the next
element. If two offsets are the same, any tool reading the archive
will get stuck. This patch rejects such archives, and any with
overlapping elements.
* mach-o.c (overlap_previous): New function.
(bfd_mach_o_fat_archive_p): Sanity check that elements do not
overlap each other or the file and archive headers.
Some components of GNU Binutils will pass "-Wstack-usage=262144" when
"GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage",
despite that related configuration part in bfd/warning.m4 handles the latest
Clang (15.0.0 as of this writing) as "GCC >= 5.0".
The option "-Wstack-usage" was ignored when the first version of Clang is
released but even this "ignoring" behavior is removed before Clang 4.0.0.
So, if we give Clang "-Wstack-usage=262144", it generates a warning, making
the build failure.
This commit checks "__clang__" macro to prevent adding the option if the
compiler is identified as Clang.
bfd/ChangeLog:
* warning.m4: Stop appending "-Wstack-usage=262144" option when
compiled with Clang.
* configure: Regenerate.
binutils/ChangeLog:
* configure: Regenerate.
gas/ChangeLog:
* configure: Regenerate.
gold/ChangeLog:
* configure: Regenerate.
gprof/ChangeLog:
* configure: Regenerate.
ld/ChangeLog:
* configure: Regenerate.
opcodes/ChangeLog:
* configure: Regenerate.
Also a bugfix. The first time the section was read, the contents
didn't supply an addend.
* som.c (som_set_reloc_info): Sanity check offset. Do process
contents after reading. Tidy section->contents after freeing.
