I see this error with clang-14:
CC elf64-ppc.lo
/home/smarchi/src/binutils-gdb/bfd/elf64-ppc.c:13131:11: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
return (check_pasted_section (info, ".init")
~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix by replacing & with &&. But given that the check_pasted_section
function has side-effects and we want to make sure both calls are made,
assign to temporary variables before evaluating the `&&`.
Change-Id: I849e1b2401bea5f4d8ef3ab9af99ba9e3ef42490
binutils/NEWS says of the change in --process-links semantics:
If other debug section display options are also enabled (eg
--debug-dump=info) then the contents of matching sections in both the main
file and the separate debuginfo file *will* be displayed. This is because in
most cases the debug section will only be present in one of the files.
Implying that debug info is dumped without --process-links. Indeed
that appears to be the case for readelf. This does the same for
objdump.
PR 28029
* objdump.c (dump_bfd): Do not exit early when !is_mainfile
&& !processlinks, instead just exclude non-debug output.
(dump_dwarf): Add is_mainfile parameter and pass to
dump_dwarf_section.
(dump_dwarf_section): Only display debug sections when
!is_mainfile and !process_links.
PowerPC64 takes a more traditional approach to DT_RELR than x86. Count
relative relocs in check_relocs, allocate space for them and output in
the usual places but not doing so when enable_dt_relr. DT_RELR is
sized in the existing ppc stub relaxation machinery, run via the
linker's ldemul_after_allocation hook. DT_RELR is output in the same
function that writes ppc stubs, run via ldemul_finish.
This support should be considered experimental.
bfd/
* elf64-ppc.c (struct ppc_local_dyn_relocs): Renamed from
ppc_dyn_relocs. Add rel_count field. Update uses.
(struct ppc_dyn_relocs): New. Replace all uses of elf_dyn_relocs.
(struct ppc_link_hash_table): Add relr_alloc, relr_count and
relr_addr.
(ppc64_elf_copy_indirect_symbol): Merge rel_count.
(ppc64_elf_check_relocs): Init rel_count for global and local syms.
(dec_dynrel_count): Change r_info param to reloc pointer. Update
all callers. Handle decrementing rel_count.
(allocate_got): Don't allocate space for relative relocs when
enable_dt_relr.
(allocate_dynrelocs): Likewise.
(ppc64_elf_size_dynamic_sections): Likewise. Handle srelrdyn.
(ppc_build_one_stub): Don't emit relative relocs on .branch_lt.
(compare_relr_address, append_relr_off): New functions.
(got_and_plt_relr_for_local_syms, got_and_plt_relr): Likewise.
(ppc64_elf_size_stubs): Size .relr.syn.
(ppc64_elf_build_stubs): Emit .relr.dyn.
(build_global_entry_stubs_and_plt): Don't output relative relocs
when enable_dt_relr.
(write_plt_relocs_for_local_syms): Likewise.
(ppc64_elf_relocate_section): Likewise.
binutils/
* testsuite/lib/binutils-common.exp (supports_dt_relr): Add
powerpc64.
ld/
* emulparams/elf64ppc.sh: Source dt-relr.sh.
* testsuite/ld-elf/dt-relr-2b.d: Adjust for powerpc.
* testsuite/ld-elf/dt-relr-2c.d: Likewise.
* testsuite/ld-elf/dt-relr-2d.d: Likewise.
* testsuite/ld-elf/dt-relr-2e.d: Likewise.
bfd/
* elf-bfd.h (UNDEFWEAK_NO_DYNAMIC_RELOC): Test linker_def.
ld/
* ldelf.c (ldelf_before_allocation): Don't force __ehdr_start
local and hidden here..
* ldlang.c (lang_symbol_tweaks): ..do so here instead and set
def_regular and linker_def for check_relocs. New function
extracted from lang_process.
Now that this lives on the stack, let's have it be a little less
wasteful in terms of space. Switch boolean fields to "bool" (also when
this doesn't change their size) and also limit the widths of "rex",
"rex_used", "op_ad", and "op_index". Do a little bit of re-ordering as
well to limit the number of padding holes.
There's no real need for the pseudo-boolean "haveindex" or for separate
32-bit / 64-bit index pointers. Fold them into a single "indexes" and
set that uniformly to AT&T names, compensating by emitting the register
name via oappend_maybe_intel().
Since commit ce2d3708bc ("Synchronize binutils libiberty sources with
gcc version."), I see this failure:
demangle _D8demangle4testFnZv^M
demangle.test(typeof(null))^M
(gdb) FAIL: gdb.dlang/demangle.exp: _D8demangle4testFnZv
The commit imported the commit 0e32a5aa8bc9 ("libiberty: Add support for
D `typeof(*null)' types") from the gcc repository. That commit includes
an update to libiberty/testsuite/d-demangle-expected, which updates a
test for the exact same mangled name:
_D8demangle4testFnZv
-demangle.test(none)
+demangle.test(typeof(null))
I don't know anything about D, but give that the change was made by Iain
Buclaw, the D language maintainer, I trust him on that.
Fix our test by updating the expected output in the same way.
Note: it's not really useful to have all these D demangling tests in the
GDB testsuite, since there are demangling tests in libiberty. We should
consider removing them, but we first need to make sure that everything
that is covered in gdb/testsuite/gdb.dlang/demangle.exp is also covered
in libiberty/testsuite/d-demangle-expected.
Change-Id: If2b290ea8367b8e1e0b90b20d4a6e0bee517952d
Intel Next Gen compiler defines preprocessor __INTEL_LLVM_COMPILER and provides
version info in __clang_version__ e.g. value: 12.0.0 (icx 2020.10.0.1113).
gdb/testsuite/ChangeLog:
2020-12-07 Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
* lib/compiler.c: Add Intel next gen compiler pre-processor check.
* lib/compiler.cc: Ditto.
* lib/fortran.exp (fortran_main): Check Intel next gen compiler in
test_compiler_info.
include/
* bfdlink.h (struct bfd_link_info): Add commonpagesize_is_set.
ld/
PR 28751
* emultempl/elf.em (handle_option): Set commonpagesize_is_set.
* ldelf.c (ldelf_after_parse): Don't error when only one of
-z max-page-size or -z common-page-size is given, correct the
other value to make it sane.
* testsuite/ld-elf/elf.exp (mbind2a, mbind2b): Do not pass
-z max-page-size.
On top of prior similar work more opportunities have appeared in the
meantime. Note that this also happens to address the prior lack of
decoding of EVEX.L'L for VMOV{L,H}P{S,D} and VMOV{LH,HL}PS.
For some reason the original AVFX512F insns were not taken as a basis
here, causing unnecessary divergence. While not an active issue, it is
still relevant to note that OP_XMM() has special treatment of e.g.
scalar_mode (marking broadcast as invalid). Such would better be
consistent for all sufficiently similar insns.
For one EVEX.W set does not imply EVEX.b is uniformly valid. Reject it
for modes which occur for insns allowing for EVEX.W to be set (noticed
with VMOV{H,L}PD and VMOVDDUP, and only in AT&T mode, but not checked
whether further insns would also have been impacted; I expect e.g.
VCMPSD would have had the same issue). And then the present concept of
broadcast makes no sense at all when the memory operand of an insn is
the destination.
Like for AVX512-FP16, there's not that many FP insns where going through
this table is easier / cheaper than using suitable macros. Utilize %XS
and %XD more to eliminate a fair number of table entries.
While doing this I noticed a few anomalies. Where lines get touched /
moved anyway, these are being addressed right here:
- vmovshdup used EXx for its 2nd operand, thus displaying seemingly
valid broadcast when EVEX.b is set with a memory operand; use
EXEvexXNoBcst instead just like vmovsldup already does
- vmovlhps used EXx for its 3rd operand, when all sibling entries use
EXq; switch to EXq there for consistency (the two differ only for
memory operands)
Like already indicated during review of the original submission, there's
really only very few insns where going through this table is easier /
cheaper than using suitable macros. Utilize %XH more and introduce
similar %XS and %XD (which subsequently can be used for further table
size reduction).
While there also switch to using oappend() in 'XH' macro processing.
Reapply the patch to detect GCC LTO plugin used for libiberty build to
support LTO build in libiberty.
* Makefile.in (AR): Add @AR_PLUGIN_OPTION@
(RANLIB): Add @RANLIB_PLUGIN_OPTION@.
(configure_deps): Depend on ../config/gcc-plugin.m4.
* aclocal.m4: Include ../config/gcc-plugin.m4.
* configure.ac: AC_SUBST AR_PLUGIN_OPTION and
RANLIB_PLUGIN_OPTION.
* configure: Regenerate.
This commit aims to not make use of -Wmissing-prototypes when
compiling with g++.
Use of -Wmissing-prototypes was added with this commit:
commit a0761e34f0
Date: Wed Mar 11 15:15:12 2020 -0400
gdb: enable -Wmissing-prototypes warning
Because clang can provide helpful warnings with this flag.
Unfortunately, g++ doesn't accept this flag, and will give this
warning:
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
In theory the fact that this flag is not supported should be detected
by the configure check in gdbsupport/warning.m4, but for users of
ccache, this check doesn't work due to a long standing ccache issue:
https://github.com/ccache/ccache/issues/738
The ccache problem is that -W... options are reordered on the command
line, and so -Wmissing-prototypes is seen before -Werror. Usually
this doesn't matter, but the above warning (about the flag not being
valid) is issued before the -Werror flag is processed, and so is not
fatal.
There have been two previous attempts to fix this that I'm aware of.
The first is:
https://sourceware.org/pipermail/gdb-patches/2021-September/182148.html
In this attempt, instead of just relying on a compile to check if a
flag is valid, the proposal was to both compile and link. As linking
doesn't go through ccache, we don't suffer from the argument
reordering problem, and the link phase will correctly fail when using
-Wmissing-prototypes with g++. The configure script will then disable
the use of this flag.
This approach was rejected, and the suggestion was to only add the
-Wmissing-prototypes flag if we are compiling with gcc.
The second attempt, attempts this approach, and can be found here:
https://sourceware.org/pipermail/gdb-patches/2021-November/183076.html
This attempt only adds the -Wmissing-prototypes flag is the value of
GCC is not 'yes'. This feels like it is doing the right thing,
unfortunately, the GCC flag is really a 'is gcc like' flag, not a
strict, is gcc check. As such, GCC is set to 'yes' for clang, which
would mean the flag was not included for clang or gcc. The entire
point of the original commit was to add this flag for clang, so
clearly the second attempt is not sufficient either.
In this new attempt I have added gdbsupport/compiler-type.m4, this
file defines AM_GDB_COMPILER_TYPE. This macro sets the variable
GDB_COMPILER_TYPE to either 'gcc', 'clang', or 'unknown'. In future
the list of values might be extended to cover other compilers, if this
is ever useful.
I've then modified gdbsupport/warning.m4 to only add the problematic
-Wmissing-prototypes flag if GDB_COMPILER_TYPE is not 'gcc'.
I've tested this with both gcc and clang and see the expected results,
gcc no longer attempts to use the -Wmissing-prototypes flag, while
clang continues to use it.
When compiling using ccache, I am no longer seeing the warning.
While working on another patch I wanted to add some extra debug
information to the attach_command function. This required me to add a
new function to convert the thread_info::state variable to a string.
The new debug might be useful to others, and the state to string
function might be useful in other locations, so I thought I'd merge
it.
tc-ppc.c: In function 'ppc_comm':
tc-ppc.c:4560:40: error: 'visibility' may be used uninitialized in this function [-Werror=maybe-uninitialized]
With that fixed we hit lots of segfaults in the ld testsuite.
PR 22085
bfd/
* xcofflink.c (xcoff_link_input_bfd): Don't segfault on NULL
sym_hash.
gas/
* config/tc-ppc.c (ppc_comm): Init visibility.
Otherwise the very simple test may not be linked with libc.so at all,
and thus correctly have no version reference added. Causing failure
of the dt-relr-glibc-1b.so test.
* testsuite/ld-elf/dt-relr.exp: Link with --no-as-needed.
It might seem to work, but only if '/' is a start of comment char.
* testsuite/ld-elf/dt-relr-1.s: Use # for comment.
* testsuite/ld-elf/dt-relr-2.s: Likewise.
* testsuite/ld-elf/dt-relr-3.s: Likewise.
This makes the code setting DT_RELR tags generally available. Many
targets will be able to use the defaults. Those that can't should set
up sh_entsize for .relr.dyn output section before reaching the dynamic
tag code in bfd_elf_final_link.
* elflink.c (bfd_elf_final_link): Set up DT_RELR tags and sh_entsize.
* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Don't do any
of that here.
This reverts the commit ff656e2e1c ("gdb: testsuite: fix failed
testcases in gdb.base/charset.exp").
The original test code has no problem. On an architecture where
char is signed, then both 'A' and ebcdic_us_string[7] will yield
-63, which makes the equality true. On an architecture where char
is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193,
which also makes the equality true.
The test cases only failed on LoongArch. The default type of char
is signed char on LoongArch, like x86-64. But when use gdb print
command on LoongArch, the default type of char is unsigned char,
this is wrong, I will look into it later, sorry for that.
On LoongArch:
$ cat test_char.c
#include <stdio.h>
int main()
{
char c1 = 193;
unsigned char c2 = 193;
printf("%d\n", c1);
printf("%d\n", c1 == c2);
return 0;
}
$ gcc test_char.c -o test_char
$ ./test_char
-63
0
(gdb) set target-charset EBCDIC-US
(gdb) print 'A'
$1 = 193 'A'
(gdb) print /c 'A'
$2 = 193 'A'
(gdb) print /u 'A'
$3 = 193
(gdb) print /d 'A'
$4 = -63
(gdb) print /x 'A'
$5 = 0xc1
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
The Power 9 processor revision 2.2 has HW watchpoint support disabled due
to a HW bug. The support is fixed in Power 9 processor revision 2.3. This
patch add a test to lib/gdb.exp for Power to determine if the processor
supports HW watchpoints or not. If the Power processor doesn't support HW
watchpoints the proceedure skip_hw_watchpoint_tests will return 1 to
disable the various HW watchpoint tests.
The patch has been tested on Power 9, processor revesions 2.2 and 2.3. The
patch has also been tested on Power 10. No regression test failures were
found.
When executed with --target_board=native-extended-gdbserver, the
gdb.python/py-events.exp test errors out with
ERROR: tcl error sourcing /path/to/gdb/testsuite/gdb.python/py-events.exp.
ERROR: can't read "process_id": no such variable
while executing
"lappend expected "ptid: \\($process_id, $process_id, 0\\)" "address: $addr""
(file "/path/to/gdb/testsuite/gdb.python/py-events.exp" line 103)
invoked from within
"source /path/to/gdb/testsuite/gdb.python/py-events.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /path/to/gdb/testsuite/gdb.python/py-events.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
There are multiple problems around this:
1. The process_id variable is not initialized to a default value.
2. The test attempts to find the PID of the current thread, but the
regexp that it uses is not tailored for the output printed by the
remote target.
3. The test uses "info threads" to find the current thread PID.
Using the "thread" command instead is simpler.
Fix these problems.
PR remote/9177 points out that "info files" mentions "serial" a couple
of times:
Remote serial target in gdb-specific protocol:
Debugging a target over a serial line.
However, often the remote target isn't really a serial connection.
It seems to me that this text could be a bit clearer; and furthermore
since "info files" prints the target's long description,
remote_target::files_info doesn't really add much and can simply be
removed.
Regression tested on x86-64 Fedora 34.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9177
When DT_RELR is enabled, to avoid random run-time crash with older glibc
binaries without DT_RELR support, add a GLIBC_ABI_DT_RELR symbol version,
which is provided by glibc with DT_RELR support, dependency on the shared
C library if it provides a GLIBC_2.XX symbol version.
bfd/
* elflink.c (elf_link_add_dt_relr_dependency): New function.
(bfd_elf_size_dynamic_sections): Call
elf_link_add_dt_relr_dependency if DT_RELR is enabled.
ld/
* ld.texi: Mention GLIBC_ABI_DT_RELR in -z pack-relative-relocs
entry.
* testsuite/ld-elf/dt-relr-glibc-1.c: New file.
* testsuite/ld-elf/dt-relr-glibc-1a.rd: Likewise.
* testsuite/ld-elf/dt-relr-glibc-1b.rd: Likewise.
* testsuite/ld-elf/dt-relr.exp: Likewise.
