I ran
for i in $(find . -name configure.ac); do pushd $(dirname $i); autoreconf -vf; popd; done
to re-generate all automake/autoconf files throughout the repo (with
upstream autoconf 2.69 and automake 1.15.1). These were the changes
that came out. I am pushing this as obvious.
libdecnumber/ChangeLog:
* aclocal.m4, configure: Re-generate.
sim/bfin/ChangeLog:
* aclocal.m4, configure: Re-generate.
sim/erc32/ChangeLog:
* configure: Re-generate.
sim/mips/ChangeLog:
* configure: Re-generate.
sim/testsuite/ChangeLog:
* configure: Re-generate.
Change-Id: I97335c09972d25cc5f6fd8da4db4ffe4a0348787
Make the MIPS/IRIX naming of local section symbols consistent between
files produced by generic ELF code and ELF linker code, complementing
commit 174fd7f95561 ("New bfd elf hook: force naming of local section
symbols"), <https://sourceware.org/ml/binutils/2004-02/msg00072.html>.
Local section symbols have no names in the standard ELF gABI, however
the lack of a name causes problems with IRIX's MIPSpro linker. To work
around the issue we give them names, however we do that in generic ELF
code only, based on what the `elf_backend_name_local_section_symbols'
hook returns if present. That makes objects created by GAS or `objdump'
work correctly, however not ones created by `ld -r'. That would not
normally cause issues with IRIX systems using GAS and `objdump' only
with the MIPSpro linker, however if GNU LD was used for whatever reason
in producing objects later fed to IRIX's MIPSpro linker, then things
would break.
Modify ELF linker code accordingly then, using the same hook. Adjust
the `ld-elf/64ksec-r' test accordingly so that it also accepts a section
symbol with a name.
Also modify the hook itself so that only actual ET_REL objects have
names assigned to local section symbols. Other kinds of ELF files are
not ever supposed to be relocated with the MIPSpro linker, so we can
afford producing more standard output.
Add suitable GAS, LD and `objcopy' test cases to the relevant testsuites
to keep these tools consistently verified. This change also fixes:
FAIL: objcopy executable (pr25662)
across MIPS targets using the IRIX compatibility mode.
bfd/
* elflink.c (bfd_elf_final_link): Give local symbols a name if
so requested.
* elfxx-mips.c (_bfd_mips_elf_name_local_section_symbols): Only
return TRUE if making ET_REL output.
binutils/
* testsuite/binutils-all/mips/global-local-symtab-sort-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-o32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n32t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-sort-n64t.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-o32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n32.d:
New test.
* testsuite/binutils-all/mips/global-local-symtab-final-n64.d:
New test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
gas/
* testsuite/gas/mips/global-local-symtab-sort-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64.d: New test.
* testsuite/gas/mips/global-local-symtab-sort-n64t.d: New test.
* testsuite/gas/mips/mips.exp: Run the new tests.
ld/
* testsuite/ld-elf/sec64k.exp: Also accept a section symbol with
a name.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-o32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n32t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-sort-n64t.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-o32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n32.d: New
test.
* testsuite/ld-mips-elf/global-local-symtab-final-n64.d: New
test.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
Correct ELF linker code so as to set the `sh_info' value of the static
symbol table section according to the section symbols vs other symbols
split where required by the selection of the IRIX compatibility mode for
MIPS target. Add a `elf_backend_elfsym_local_is_section' hook for that
purpose, returning TRUE if it is only STB_LOCAL/STT_SECTION symbols that
are to be considered local for the purpose of this split rather than all
STB_LOCAL symbols.
We do it already in generic ELF code, and have done it since 1993, with
the `elf_backend_sym_is_global' hook, affecting GAS and `objcopy', so
these tools produce correct ELF output in the IRIX compatibility mode,
however if such output is fed as input to `ld -r', then the linker's
output is no longer valid for that mode. The relevant changes to
generic ELF code are:
commit 062189c6eab72c7ba1bab1cf30fdb27d67a7d668
Author: Ian Lance Taylor <ian@airs.com>
Date: Thu Nov 18 17:12:47 1993 +0000
and:
commit 6e07e54f1b347f885cc6c021c3fd912c79bdaf55
Author: Ian Lance Taylor <ian@airs.com>
Date: Thu Jan 6 20:01:42 1994 +0000
(split across two GIT commits likely due to repository conversion
peculiarities).
The `elf_backend_sym_is_global' hook however operates on BFD rather than
ELF symbols, making it unsuitable for the ELF linker as the linker does
not convert any symbol tables processed into the BFD format. Converting
the hook to operate on ELF symbols would in principle be possible, but
it would still require a considerable rewrite of `bfd_elf_final_link' to
adapt to the interface.
Therefore, especially given that no new use for the IRIX compatibility
mode is expected, minimize changes made to the ELF linker code and just
add an entirely new hook, and wire it in the o32 and n32 MIPS backends
accordingly; the n64 backend never uses the IRIX compatibility mode.
Since we have no coverage here at all add suitable GAS, LD and `objcopy'
test cases to the relevant testsuites to keep these tools consistently
verified.
bfd/
* elf-bfd.h (elf_backend_data): Add
`elf_backend_elfsym_local_is_section' member.
* elfxx-target.h (elf_backend_elfsym_local_is_section): New
macro.
(elfNN_bed): Add `elf_backend_elfsym_local_is_section' member.
* elflink.c (bfd_elf_final_link): Use it to determine whether
set the `.symtab' section's `sh_info' value to the index of the
first non-local or non-section symbol.
* elf32-mips.c (mips_elf32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.
* elfn32-mips.c (mips_elf_n32_elfsym_local_is_section): New
function.
(elf_backend_elfsym_local_is_section): New macro.
binutils/
* testsuite/binutils-all/mips/global-local-symtab-o32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-o32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n32t.d: New
test.
* testsuite/binutils-all/mips/global-local-symtab-n64.d: New
test.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.
gas/
* testsuite/gas/mips/global-local-symtab-o32.d: New test.
* testsuite/gas/mips/global-local-symtab-o32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n32.d: New test.
* testsuite/gas/mips/global-local-symtab-n32t.d: New test.
* testsuite/gas/mips/global-local-symtab-n64.d: New test.
* testsuite/gas/mips/global-local-symtab.s: New test source.
* testsuite/gas/mips/mips.exp: Run the new tests.
ld/
* testsuite/ld-mips-elf/global-local-symtab-o32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-o32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n32t.d: New test.
* testsuite/ld-mips-elf/global-local-symtab-n64.d: New test.
* testsuite/ld-mips-elf/global-local-symtab.ld: New test linker
script.
* testsuite/ld-mips-elf/mips-elf.exp: Run the new tests.
In s390-mkopc.c, the function insertExpandedMnemonic() searches for the
first occurrence of '*' or '$' in the given mnemonic, and, if a match is
found, chooses an extension table using a switch() on that character. The
switch statement contains a default case that prints an error message and
does not set the extension table. Although this case cannot occur, some
GCC versions obviously conclude that the extension table might have been
left uninitialized after the switch statement and consequently emit
maybe-uninitialized warnings for the variables 'ext_table' and
'ext_table_length'.
Circumvent the warning by handling the unreachable default case with
abort().
opcodes/
* s390-mkopc.c (insertExpandedMnemonic): Handle unreachable
default case with abort() instead of printing an error message and
continuing, to avoid a maybe-uninitialized warning.
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression
tests, I run into the following FAILs:
...
FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop
...
The problem is that when setting the breakpoint at captured_command_loop:
...
(gdb) break captured_command_loop^M
Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M
(gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
...
there are two breakpoint locations instead of one. This is due to
PR26096 - "gdb sets breakpoint at cold clone":
...
$ nm gdb | grep captured_command_loop| c++filt
0000000000659f20 t captured_command_loop()
00000000004230ed t captured_command_loop() [clone .cold]
...
Work around this by allowing multiple breakpoint locations for
captured_command_loop.
Reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp (selftest_setup): Allow breakpoint at
multiple locations.
We get lots of errors before we get to this code, but let's not
segfault.
* elflink.c (bfd_elf_final_link): Don't segfault on local dynsyms
defined in excluded sections.
When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP
set, we need to set SEC_EXCLUDE here to avoid a problem later.
* ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for
discarded sections.
When building gdb with CFLAGS/CXXFLAGS="-O2 -g -Wall", I see:
...
src/gdb/s390-tdep.c: In function 'void s390_displaced_step_fixup(gdbarch*, \
displaced_step_closure*, CORE_ADDR, CORE_ADDR, regcache*)':
src/gdb/s390-tdep.c:528:30: warning: 'r2' may be used uninitialized in this \
function [-Wmaybe-uninitialized]
528 | if (insn[0] == op_basr && r2 == 0)
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
...
The problem is that the compiler is unaware that
'is_rr (insn, op_basr, &r1, &r2) == 1' ensures that 'insn[0] == op_basr':
...
if (is_rr (insn, op_basr, &r1, &r2)
|| is_rx (insn, op_bas, &r1, &d2, &x2, &b2))
{
/* Recompute saved return address in R1. */
regcache_cooked_write_unsigned (regs, S390_R0_REGNUM + r1,
amode | (from + insnlen));
/* Update PC iff the instruction doesn't actually branch. */
if (insn[0] == op_basr && r2 == 0)
regcache_write_pc (regs, from + insnlen);
}
...
Fix this by storing the result of the call, and using it instead of
'insn[0] ==op_basr'.
Build on x86_64-linux with --enable-targets=s390-suse-linux,s390x-suse-linux.
gdb/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
PR tdep/26280
* s390-tdep.c (s390_displaced_step_fixup): Fix Wmaybe-uninitialized.
On aarch64, there are FAILs for gdb.dwarf2/dw2-line-number-zero.exp due to
problems in the prologue analyzer (filed as PR26310).
Make the test-case more robust by avoiding to use the prologue analyzer:
...
-gdb_breakpoint "bar1"
+gdb_breakpoint "$srcfile:27"
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-line-number-zero.exp: Set breakpoints on lines
rather than function name.
Andrew Burgess pointed out a regression, which he described in
PR symtab/26270:
================
After commit:
commit bcfe6157ca288efed127c5efe21ad7924e0d98cf (refs/bisect/bad)
Date: Fri Apr 24 15:35:01 2020 -0600
Use the linkage name if it exists
The disassembler no longer demangles function names in its output. So
we see things like this:
(gdb) disassemble tree_insert
Dump of assembler code for function _Z11tree_insertP4nodei:
....
Instead of this:
(gdb) disassemble tree_insert
Dump of assembler code for function tree_insert(node*, int):
....
This is because find_pc_partial_function now returns the linkage name
rather than the demangled name.
================
This patch fixes the problem by introducing a new "overload" of
find_pc_partial_function, which returns the general_symbol_info rather
than simply the name. This lets the disassemble command choose which
name to show.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2020-07-28 Tom Tromey <tromey@adacore.com>
PR symtab/26270:
* symtab.h (find_pc_partial_function_sym): Declare.
* cli/cli-cmds.c (disassemble_command): Use
find_pc_partial_function_sym. Check asm_demangle.
* blockframe.c (cache_pc_function_sym): New global.
(cache_pc_function_name): Remove.
(clear_pc_function_cache): Update.
(find_pc_partial_function_sym): New function, from
find_pc_partial_function.
(find_pc_partial_function): Rewrite using
find_pc_partial_function_sym.
gdb/testsuite/ChangeLog
2020-07-28 Andrew Burgess <andrew.burgess@embecosm.com>
PR symtab/26270:
* gdb.cp/disasm-func-name.cc: New file.
* gdb.cp/disasm-func-name.exp: New file.
Pedro pointed out that disassemble/m should be documented after
disassemble/s, because /m is deprecated. This patch does so, and adds
a usage line.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2020-07-28 Tom Tromey <tromey@adacore.com>
* cli/cli-cmds.c (_initialize_cli_cmds): Rearrange "disassemble"
help. Add usage.
A modified version of the gnat compiler (TBH I don't know if the
modifications are relevant to this bug or not, but I figured I'd
mention it) can generate a DWARF location expression like:
<1><1201>: Abbrev Number: 3 (DW_TAG_dwarf_procedure)
<1202> DW_AT_location : 32 byte block: 12 31 29 28 4 0 30 2f 12 0 14 30 2d 28 4 0 14 2f 1 0 30 34 1e 23 3 9 fc 1a 16 13 16 13 (DW_OP_dup; DW_OP_lit1; DW_OP_eq; DW_OP_bra: 4; DW_OP_lit0; DW_OP_skip: 18; DW_OP_over; DW_OP_lit0; DW_OP_lt; DW_OP_bra: 4; DW_OP_over; DW_OP_skip: 1; DW_OP_lit0; DW_OP_lit4; DW_OP_mul; DW_OP_plus_uconst: 3; DW_OP_const1s: -4; DW_OP_and; DW_OP_swap; DW_OP_drop; DW_OP_swap; DW_OP_drop)
<2><1279>: Abbrev Number: 9 (DW_TAG_structure_type)
<127a> DW_AT_name : (indirect string, offset: 0x1a5a): p__logical_channel_t
<127e> DW_AT_byte_size : 18 byte block: fd 43 12 0 0 97 94 1 99 34 0 0 0 23 7 9 fc 1a (DW_OP_GNU_variable_value: <0x1243>; DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_call4: <0x1201>; DW_OP_plus_uconst: 7; DW_OP_const1s: -4; DW_OP_and)
When evaluated, this gives:
Incompatible types on DWARF stack
In Jakub's original message about DW_OP_GNU_variable_value:
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-02/msg01499.html
.. it says:
The intended behavior is that the debug info consumer computes the
value of that referenced variable at the current PC, and if it can
compute it and pushes the value as a generic type integer into the
DWARF stack
Instead, gdb is using the variable's type -- but this fails with some
operations, like DW_OP_and, which expect the types to match.
I believe what was intended was for the value to be cast to the DWARF
"untyped" type, which is what this patch implements. This patch also
updates varval.exp to exhibit the bug.
gdb/ChangeLog
2020-07-28 Tom Tromey <tromey@adacore.com>
* dwarf2/expr.c (dwarf_expr_context::execute_stack_op)
<DW_OP_GNU_variable_value>: Cast to address type.
gdb/testsuite/ChangeLog
2020-07-28 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/varval.exp (setup_exec): Add 'or' instruction to
'varval' location.
NetBSD implements reading and overwriting siginfo_t received by the
tracee. With TARGET_OBJECT_SIGNAL_INFO signal information can be
examined and modified through the special variable $_siginfo.
Implement the "get_siginfo_type" gdbarch method for NetBSD architectures.
As with Linux architectures, cache the created type in the gdbarch when it
is first created. Currently NetBSD uses an identical siginfo type on
all architectures, so there is no support for architecture-specific fields.
gdb/ChangeLog:
* nbsd-nat.h (nbsd_nat_target::xfer_partial): New declaration.
* nbsd-nat.c (nbsd_nat_target::xfer_partial): New function.
* nbsd-tdep.c (nbsd_gdbarch_data_handle, struct nbsd_gdbarch_data)
(init_nbsd_gdbarch_data, get_nbsd_gdbarch_data)
(nbsd_get_siginfo_type): New.
(nbsd_init_abi): Install gdbarch "get_siginfo_type" method.
(_initialize_nbsd_tdep): New
There is no need to check $pkg_cv_[]$1[]_LIBS works if package check
failed.
config/
PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Use AC_TRY_LINK only if
$pkg_failed = no.
binutils/
PR binutils/26301
* configure: Regenerated.
gdb/
PR binutils/26301
* configure: Regenerated.
When building with CFLAGS/CXXFLAGS="-O2 -g -Wall", we run into:
...
In file included from src/gdb/exceptions.h:23,
from src/gdb/utils.h:24,
from src/gdb/defs.h:630,
from src/gdb/record-btrace.c:22:
src/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, \
const btrace_thread_info*, const btrace_insn_iterator*, \
const btrace_insn_iterator*, gdb_disassembly_flags)':
src/gdb/ui-out.h:352:18: warning: \
'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' may be used \
uninitialized in this function [-Wmaybe-uninitialized]
352 | m_uiout->end (Type);
| ~~~~~~~~~~~~~^~~~~~
src/gdb/record-btrace.c:795:35: note: \
'asm_list.ui_out_emit_type<ui_out_type_list>::m_uiout' was declared here
795 | gdb::optional<ui_out_emit_list> asm_list;
| ^~~~~~~~
...
This is reported as PR gcc/80635 - "[8/9/10/11 regression] std::optional and
bogus -Wmaybe-uninitialized warning".
Silence the warning by using the workaround suggested here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635#c53 ):
...
union
{
struct { } m_dummy;
T m_item;
+ volatile char dont_use; // Silences -Wmaybe-uninitialized warning.
};
...
Build on x86_64-linux.
gdbsupport/ChangeLog:
2020-07-28 Tom de Vries <tdevries@suse.de>
PR build/26281
* gdb_optional.h (class optional): Add volatile member to union
contaning m_dummy and m_item.
It is quite normal to have headers without library on multilib OSes.
Add AC_TRY_LINK to PKG_CHECK_MODULES to check if $pkg_cv_[]$1[]_LIBS
works.
config/
PR binutils/26301
* pkg.m4 (PKG_CHECK_MODULES): Add AC_TRY_LINK to check if
$pkg_cv_[]$1[]_LIBS works.
binutils/
PR binutils/26301
* configure: Regenerated.
gdb/
PR binutils/26301
* configure: Regenerated.
Since (%bp)/(%ebp)/(%rbp) are encoded as 0(%bp)/0(%ebp)/0(%rbp), use
disp32/disp16 on 0(%bp)/0(%ebp)/0(%rbp) for {disp32}.
Note: Since there is no disp32 on 0(%bp), use disp16 instead.
PR gas/26305
* config/tc-i386.c (build_modrm_byte): Use disp32/disp16 on
(%bp)/(%ebp)/(%rbp) for {disp32}.
* doc/c-i386.texi: Update {disp32} documentation.
* testsuite/gas/i386/pseudos.s: Add (%bp)/(%ebp) tests.
* testsuite/gas/i386/x86-64-pseudos.s: Add (%ebp)/(%rbp) tests.
* testsuite/gas/i386/pseudos.d: Updated.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.
This commit unifies all of the Python register lookup code (used by
Frame.read_register, PendingFrame.read_register, and
gdb.UnwindInfo.add_saved_register), and adds support for using a
gdb.RegisterDescriptor for register lookup.
Currently the register unwind code (PendingFrame and UnwindInfo) allow
registers to be looked up either by name, or by GDB's internal
number. I suspect the number was added for performance reasons, when
unwinding we don't want to repeatedly map from name to number for
every unwind. However, this kind-of sucks, it means Python scripts
could include GDB's internal register numbers, and if we ever change
this numbering in the future users scripts will break in unexpected
ways.
Meanwhile, the Frame.read_register method only supports accessing
registers using a string, the register name.
This commit unifies all of the register to register-number lookup code
in our Python bindings, and adds a third choice into the mix, the use
of gdb.RegisterDescriptor.
The register descriptors can be looked up by name, but once looked up,
they contain GDB's register number, and so provide all of the
performance benefits of using a register number directly. However, as
they are looked up by name we are no longer tightly binding the Python
API to GDB's internal numbering scheme.
As we may already have scripts in the wild that are using the register
numbers directly I have kept support for this in the API, but I have
listed this method last in the manual, and I have tried to stress that
this is NOT a good method to use and that users should use either a
string or register descriptor approach.
After this commit all existing Python code should function as before,
but users now have new options for how to identify registers.
gdb/ChangeLog:
* python/py-frame.c: Remove 'user-regs.h' include.
(frapy_read_register): Rewrite to make use of
gdbpy_parse_register_id.
* python/py-registers.c (gdbpy_parse_register_id): New function,
moved here from python/py-unwind.c. Updated the return type, and
also accepts register descriptor objects.
* python/py-unwind.c: Remove 'user-regs.h' include.
(pyuw_parse_register_id): Moved to python/py-registers.c.
(unwind_infopy_add_saved_register): Update to use
gdbpy_parse_register_id.
(pending_framepy_read_register): Likewise.
* python/python-internal.h (gdbpy_parse_register_id): Declare.
gdb/testsuite/ChangeLog:
* gdb.python/py-unwind.py: Update to make use of a register
descriptor.
gdb/doc/ChangeLog:
* python.texi (Unwinding Frames in Python): Update descriptions
for PendingFrame.read_register and
gdb.UnwindInfo.add_saved_register.
(Frames In Python): Update description of Frame.read_register.
Adds a new method 'find' to the gdb.RegisterDescriptorIterator class,
this allows gdb.RegisterDescriptor objects to be looked up directly by
register name rather than having to iterate over all registers.
This will be of use for a later commit.
I've documented the new function in the manual, but I don't think a
NEWS entry is required here, as, since the last release, the whole
register descriptor mechanism is new, and is already mentioned in the
NEWS file.
gdb/ChangeLog:
* python/py-registers.c: Add 'user-regs.h' include.
(register_descriptor_iter_find): New function.
(register_descriptor_iterator_object_methods): New static global
methods array.
(register_descriptor_iterator_object_type): Add pointer to methods
array.
gdb/testsuite/ChangeLog:
* gdb.python/py-arch-reg-names.exp: Add additional tests.
gdb/doc/ChangeLog:
* python.texi (Registers In Python): Document new find function.
Even a testcase that is expected to fail shouldn't segfault.
* elf.c (assign_section_numbers): Comment. Don't segfault on
discarded sections when setting linked-to section for generic
ELF linker.
* elflink.c (bfd_elf_match_symbols_in_sections): Allow NULL info.
* ldlang.c (lang_check): Don't complain about relocs or merge
attributes from --just-symbols input.
* testsuite/ld-misc/just-symbols.exp: Just dump .data section.
Don't run test on a number of targets.
This ensures we don't match random data *before* the line we want to
see, ie. that --just-symbols has excluded section contents from
just-symbols-0.o. Oops, missed the ChangeLog entry before too.
* testsuite/ld-misc/just-symbols-1.dd: Revert last change.
Fixes to set correct si_code values (such as TRAP_BRKPT) were made to
the remaining FreeBSD architectures (MIPS and sparc64) in the head
branch leading up to 12.0 and were merged back between the 11.2 and
11.3 releases.
gdb/ChangeLog:
* fbsd-nat.h: Include <osreldate.h>. Define USE_SIGTRAP_SIGINFO
for all architectures on FreeBSD 11.3 and later.
gcore.h declares load_corefile, but there are no other mentions of
this in the source. This patch removes it. Tested by grep and
rebuilding.
gdb/ChangeLog
2020-07-27 Tom Tromey <tromey@adacore.com>
* gcore.h (load_corefile): Don't declare.
* testsuite/ld-misc/just-symbols.exp: Run for x86_64 PE too.
Set LDFLAGS for PE and XCOFF.
* testsuite/ld-misc/just-symbols.ld: Accept XCOFF mapped .data.
This patch is aimed at curing
just-symbols-1.o: loader reloc in unrecognized section `*ABS*'
for xcoff by treating symbols defined by --just-symbols objects as
absolute.
* xcofflink.c (xcoff_need_ldrel_p): Accept --just-symbols symbols and
similar as absolute.
(bfd_xcoff_import_symbol): Don't fuss over absolute symbol
redefinitions here.
"objdump -s -j .bss" results in a message that indicates objdump
couldn't find a .bss section when present. Fix that.
* objdump.c (dump_section): Don't return without calling
process_section_p.
gold version of commit e10a07b32dc1.
* options.h (DEFINE_enum): Add optional_arg__ param, adjust
all uses.
(General_options): Add --power10-stubs and --no-power10-stubs.
* options.cc (General_options::finalize): Handle --power10-stubs.
* powerpc.cc (set_power10_stubs): Don't set when --power10-stubs=no.
(power10_stubs_auto): New.
(struct Plt_stub_ent): Add toc_ and tocoff_. Don't use a bitfield
for indx_.
(struct Branch_stub_ent): Add toc_and tocoff_. Use bitfields for
iter_, notoc_ and save_res_.
(add_plt_call_entry): Set toc_. Adjust resizing conditions for
--power10-stubs=auto.
(add_long_branch_entry): Set toc_.
(add_eh_frame, define_stub_syms): No longer use const_iterators
for plt and long branch stub iteration.
(build_tls_opt_head, build_tls_opt_tail): Change parameters and
return value. Move tests for __tls_get_addr to callers.
(plt_call_size): Handle --power10-stubs=auto.
(branch_stub_size): Likewise.
(Stub_table::do_write): Likewise.
(relocate): Likewise.
I'm running into a build breaker:
...
src/gdb/ser-tcp.c:65:13: error: conflicting declaration ‘typedef int
socklen_t’
65 | typedef int socklen_t;
| ^~~~~~~~~
In file included from ../gnulib/import/unistd.h:40,
from
/home/vries/gdb_versions/devel/src/gdb/../gnulib/import/pathmax.h:42,
from
/home/vries/gdb_versions/devel/src/gdb/../gdbsupport/common-defs.h:120,
from src/gdb/defs.h:28,
from src/gdb/ser-tcp.c:20:
/usr/include/unistd.h:277:21: note: previous declaration as ‘typedef
__socklen_t socklen_t’
277 | typedef __socklen_t socklen_t;
| ^~~~~~~~~
...
after commit 05a6b8c28b "Don't unnecessarily redefine 'socklen_t' type in
MinGW builds".
The root cause is a typo in gdb/configure.ac, using sys/sockets.h where
sys/socket.h was meant:
...
AC_CHECK_HEADERS([sys/sockets.h])
...
Fix the typo.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-07-27 Tom de Vries <tdevries@suse.de>
* configure.ac: Fix sys/sockets.h -> sys/socket.h typo.
* config.in: Regenerate.
* configure: Regenerate.
This commit fixes a compilation failure in a couple of libctf files
due to the use of EOVERFLOW and ENOTSUP, which are not defined
when compiling on MinGW.
libctf/ChangeLog:
PR binutils/25155:
* ctf-create.c (EOVERFLOW): If not defined by system header,
redirect to ERANGE as a poor man's substitute.
* ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead.
(cherry picked from commit 50500ecfefd6acc4c7f6c2a95bc0ae1945103220)
The original configure-time tests in gdb/ and gdbserver/ failed to
detect that 'socklen_t' is defined in MinGW headers because the test
program included only sys/socket.h, which is absent in MinGW system
headers. However on MS-Windows this data type is declared in another
header, ws2tcpip.h. The modified test programs try using ws2tcpip.h
if sys/socket.h is unavailable.
Thanks to Joel Brobecker who helped me regenerate the configure
scripts and the config.in files.
gdb/ChangeLog:
2020-07-26 Eli Zaretskii <eliz@gnu.org>
* configure.ac (AC_CHECK_HEADERS): Check for sys/socket.h and
ws2tcpip.h. When checking whether socklen_t type is defined, use
ws2tcpip.h if it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.
gdbserver/ChangeLog:
2020-07-26 Eli Zaretskii <eliz@gnu.org>
* configure.ac (AC_CHECK_HEADERS): Add ws2tcpip.h.
When checking whether socklen_t type is defined, use ws2tcpip.h if
it is available and sys/socket.h isn't.
* configure: Regenerate.
* config.in: Regenerate.
The binutils testsuite supports involving LD in processing test cases
and with the MIPS target that has the same issues the LD testsuite does.
So to support LD in the MIPS part of the binutils testsuite similarly
to commit 86b24e15c45b ("MIPS/LD/testsuite: Correct comm-data.exp test
ABI/emul/endian arrangement") update the mips.exp test script to:
- correctly select emulations for targets using non-traditional MIPS
emulations,
- correctly select ABIs for targets that do not support all of them,
- use the default endianness selection where possible to benefit targets
that support only one,
- simplify test invocation by providing ABI-specific `run_dump_test'
wrappers, specifically `run_dump_test_o32', `run_dump_test_n32' and
`run_dump_test_n64', which remove the need to use conditionals across
the Expect script or to repeat ABI-specific GAS and LD flags with each
invocation,
borrowing changes from commit 78da84f99405 ("MIPS/LD/testsuite: Correct
mips-elf.exp test ABI/emul/endian arrangement").
As a side effect this disables o32 ABI testing for targets that are not
supposed to support them and do not with LD, but still have such support
with BFD and GAS due to our inflexibility in configuration. Ultimately
we ought to support having o32 completely disabled.
binutils/
* testsuite/binutils-all/mips/mips.exp (run_dump_test_abi)
(run_dump_test_o32, run_dump_test_n32, run_dump_test_n64): New
procedures.
(has_newabi): Remove variable.
(has_abi, abi_asflags, abi_ldflags): New associative array
variables.
(irixemul): New variable.
Replace `run_dump_test' calls where applicable throughout with
`run_dump_test_o32', `run_dump_test_n32' and `run_dump_test_n64'
as appropriate. Use `noarch' for tests that require their own
architecture setting.
* testsuite/binutils-all/mips/mips-ase-1.d: Remove GAS flags.
* testsuite/binutils-all/mips/mips-ase-2.d: Likewise.
* testsuite/binutils-all/mips/mips-ase-3.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2-n64.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r-n64.d: Likewise.
* testsuite/binutils-all/mips/mips-note-2r.d: Likewise.
* testsuite/binutils-all/mips/mips-reginfo-n32.d: Likewise.
* testsuite/binutils-all/mips/mips-reginfo.d: Likewise.
* testsuite/binutils-all/mips/mips16-extend-noinsn.d: Likewise.
* testsuite/binutils-all/mips/mips16-pcrel.d: Likewise.
* testsuite/binutils-all/mips/mips16-alias.d: Remove `-32' from
GAS flags.
* testsuite/binutils-all/mips/mips16-extend-insn.d: Likewise.
* testsuite/binutils-all/mips/mips16-noalias.d: Likewise.
* testsuite/binutils-all/mips/mips16-undecoded.d: Likewise.
* testsuite/binutils-all/mips/mips16e2-extend-insn.d: Likewise.
* testsuite/binutils-all/mips/mips16e2-undecoded.d: Likewise.
* testsuite/binutils-all/mips/mixed-micromips.d: Likewise.
* testsuite/binutils-all/mips/mixed-mips16.d: Likewise.
After dereferencing a pointer (in value_ind) or following a
reference (in coerce_ref) we call readjust_indirect_value_type to
"fixup" the type of the resulting value object.
This fixup handles cases relating to the type of the resulting object
being different (a sub-class) of the original pointers target type.
If we encounter a pointer to a dynamic type then after dereferencing a
pointer (in value_ind) the type of the object created will have had
its dynamic type resolved. However, in readjust_indirect_value_type,
we use the target type of the original pointer to "fixup" the type of
the resulting value. In this case, the target type will be a dynamic
type, so the resulting value object, once again has a dynamic type.
This then triggers an assertion later within GDB.
The solution I propose here is that we call resolve_dynamic_type on
the pointer's target type (within readjust_indirect_value_type) so
that the resulting value is not converted back to a dynamic type.
The test case is based on the original test in the bug report.
gdb/ChangeLog:
PR fortran/23051
PR fortran/26139
* valops.c (value_ind): Pass address to
readjust_indirect_value_type.
* value.c (readjust_indirect_value_type): Make parameter
non-const, and add extra address parameter. Resolve original type
before using it.
* value.h (readjust_indirect_value_type): Update function
signature and comment.
gdb/testsuite/ChangeLog:
PR fortran/23051
PR fortran/26139
* gdb.fortran/class-allocatable-array.exp: New file.
* gdb.fortran/class-allocatable-array.f90: New file.
* gdb.fortran/pointer-to-pointer.exp: New file.
* gdb.fortran/pointer-to-pointer.f90: New file.
The DWARF standard states for the line register in the line number information
state machine the following:
...
An unsigned integer indicating a source line number. Lines are numbered
beginning at 1. The compiler may emit the value 0 in cases where an
instruction cannot be attributed to any source line.
...
So, it's possible to have a zero line number in the DWARF line table.
This is currently not handled by GDB. The zero value is read in as any other
line number, but internally the zero value has a special meaning:
end-of-sequence, so the line table entry ends up having a different
interpretation than intended in some situations.
I've created a test-case where various aspects are tested, which has these 4
interesting tests.
1. Next-step through a zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
2. Next-step through a zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
3. Show source location at zero-line instruction, is_stmt == 1
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
4. Show source location at zero-line instruction, is_stmt == 0
gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
And we have the following results:
8.3.1, 9.2:
...
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
commit 8c95582da8 "gdb: Add support for tracking the DWARF line table is-stmt
field":
...
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
commit d8cc8af6a1 "[gdb/symtab] Fix line-table end-of-sequence sorting",
master:
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1_label_3
PASS: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2_label_3
...
The regression in test 2 at commit d8cc8af6a1 was filed as PR symtab/26243,
where clang emits zero line numbers.
The way to fix all tests is to make sure line number zero internally doesn't
clash with special meaning values, and by handling it appropriately
everywhere. That however looks too intrusive for the GDB 10 release.
Instead, we decide to ensure defined behaviour for line number zero by
ignoring it. This gives us back the test results from before commit
d8cc8af6a1, fixing PR26243.
We mark the FAILs for tests 3 and 4 as KFAILs. Test 4 was already failing for
the 9.2 release, and we consider the regression of test 3 from gdb 9.2 to gdb
10 the cost for having defined behaviour.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-07-25 Tom de Vries <tdevries@suse.de>
PR symtab/26243
* dwarf2/read.c (lnp_state_machine::record_line): Ignore zero line
entries.
gdb/testsuite/ChangeLog:
2020-07-25 Tom de Vries <tdevries@suse.de>
PR symtab/26243
* gdb.dwarf2/dw2-line-number-zero.c: New test.
* gdb.dwarf2/dw2-line-number-zero.exp: New file.
With gcc-7, I run into:
...
gcc -c -I./ -gnata -Isrc/gdb/testsuite/gdb.ada/mi_prot -g -lm -I- \
src/gdb/testsuite/gdb.ada/mi_prot/prot.adb^M
prot.adb:21:04: info: "Obj_Type" is frozen here, aspects evaluated at this \
point^M
prot.adb:23:09: visibility of aspect for "Obj_Type" changes after freeze \
point^M
gnatmake: "src/gdb/testsuite/gdb.ada/mi_prot/prot.adb" compilation error^M
compiler exited with status 1
...
FAIL: gdb.ada/mi_prot.exp: compilation prot.adb
...
Fix this by requiring gnatmake-8 for this test-case.
Tested on x86_64-linux, with gnatmake-7, gnatmake-8 and gnatmake-11.
gdb/testsuite/ChangeLog:
2020-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/26293
* gdb.ada/mi_prot.exp: Require gnatmake-8.
