Jakub Jelinek [Thu, 16 Apr 2020 08:12:30 +0000 (10:12 +0200)]
intl: Allow building both with old bison and bison >= 3 [PR92008]
bison 3 apparently made a backwards incompatible change, dropped
YYLEX_PARAM/YYPARSE_PARAM support and instead needs %param or %lex-param
and %parse-param. Furthermore, there is no easy way to conditionalize
on bison version in the *.y files.
While e.g. glibc bumped bison requirement and just has the bison 3
compatible version, Richi said there are still systems with older bison
where we want to build gcc.
So, this patch instead determines during configure bison version, and
depending on that when building plural.c (if building it at all) tweaks
what is passed over to bison if needed.
Tested with both bison 3 and bison 1.35, in each case with reconfiguring
intl and building with make all-yes (as in my setup intl isn't normally
used).
intl/ChangeLog
2020-04-16 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/92008
* configure.ac: Add check for bison >= 3, AC_DEFINE HAVE_BISON3
and AC_SUBST BISON3_YES and BISON3_NO.
* Makefile.in (.y.c): Prefix $(YACC) invocation with @BISON3_NO@,
add @BISON3_YES@ prefixed rule to adjust the *.y source using sed
and adjust output afterwards.
* plural-exp.h (PLURAL_PARSE): If HAVE_BISON3 is defined, use
struct parse_args * type for arg instead of void *.
* plural.y: Add magic /* BISON3 ... */ comments with bison >= 3
directives.
(YYLEX_PARAM, YYPARSE_PARAM): Don't define if HAVE_BISON3 is defined.
(yylex, yyerror): Adjust prototypes and definitions if HAVE_BISON3
is defined.
* plural.c: Regenerated.
* config.h.in: Regenerated.
* configure: Regenerated.
Andrew Burgess [Sun, 7 Feb 2021 21:15:12 +0000 (21:15 +0000)]
gdb: delete SYMBOL_SECTION and MSYMBOL_SECTION macros
Delete two more symbol/section related macros. This time it's
SYMBOL_SECTION and MSYMBOL_SECTION.
As with general_symbol_info::m_name it is not currently possible to
make general_symbol_info::m_section private as general_symbol_info
must remain a POD type.
But other than failing to make the new m_section private, this change
does what you'd expect, adds a get and set member function and updates
all users to use the new functions instead of the previous wrapper
macros.
There should be no user visible change after this commit.
gdb/ChangeLog:
* coff-pe-read.c (add_pe_forwarded_sym): Make use of section_index
and set_section_index member functions where appropriate.
* coffread.c (coff_symtab_read): Likewise.
(process_coff_symbol): Likewise.
* ctfread.c (set_symbol_address): Likewise.
* dwarf2/read.c (add_partial_symbol): Likewise.
(var_decode_location): Likewise.
* language.c: Likewise.
* minsyms.c (minimal_symbol_reader::record_full): Likewise.
(compact_minimal_symbols): Likewise.
(minimal_symbol_upper_bound): Likewise.
* objfiles.c (relocate_one_symbol): Likewise.
* psympriv.h (partial_symbol::obj_section): Likewise.
(partial_symbol::address): Likewise.
* psymtab.c (partial_symtab::add_psymbol): Likewise.
* stabsread.c (scan_file_globals): Likewise.
* symmisc.c (dump_msymbols): Likewise.
* symtab.c (general_symbol_info::obj_section): Likewise.
(fixup_section): Likewise.
(get_msymbol_address): Likewise.
* symtab.h (general_symbol_info::section): Rename to...
(general_symbol_info::m_section): ...this.
(general_symbol_info::set_section_index): New member function.
(general_symbol_info::section_index): Likewise.
(SYMBOL_SECTION): Delete.
(MSYMBOL_VALUE_ADDRESS): Make use of section_index and
set_section_index member functions where appropriate.
(MSYMBOL_SECTION): Delete.
(symbol::symbol): Update to initialize 'm_section'.
* xcoffread.c (read_xcoff_symtab): Make use of set_section_index.
(process_xcoff_symbol): Likewise.
Andrew Burgess [Fri, 5 Feb 2021 22:01:48 +0000 (22:01 +0000)]
gdb: Delete SYMBOL_OBJ_SECTION and MSYMBOL_OBJ_SECTION
Replace the two macros SYMBOL_OBJ_SECTION and MSYMBOL_OBJ_SECTION with
a member function on general_symbol_info.
There should be no user visible change after this commit.
gdb/ChangeLog:
* breakpoint.c (resolve_sal_pc): Replace SYMBOL_OBJ_SECTION and
MSYMBOL_OBJ_SECTION.
* findvar.c (language_defn::read_var_value): Likewise.
* infcmd.c (jump_command): Likewise.
* linespec.c (minsym_found): Likewise.
* maint.c (maintenance_translate_address): Likewise.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Likewise.
(minimal_symbol_upper_bound): Likewise.
* parse.c (find_minsym_type_and_address): Likewise.
(operator_check_standard): Likewise.
* printcmd.c (info_address_command): Likewise.
* symmisc.c (dump_msymbols): Likewise.
(print_symbol): Likewise.
* symtab.c (general_symbol_info::obj_section): Define new
function.
(fixup_symbol_section): Replace SYMBOL_OBJ_SECTION.
(find_pc_sect_compunit_symtab): Likewise.
(find_function_start_sal): Likewise.
(skip_prologue_sal): Replace SYMBOL_OBJ_SECTION and
MSYMBOL_OBJ_SECTION.
* symtab.h (struct general_symbol_info) <obj_section>: Declare new
function.
(SYMBOL_OBJ_SECTION): Delete.
(MSYMBOL_OBJ_SECTION): Delete.
Tom de Vries [Wed, 10 Feb 2021 11:30:46 +0000 (12:30 +0100)]
[binutils] Handle presence of both .debug_ranges and .debug_rnglists
With exec:
...
$ g++ src/gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section
...
I run into:
...
$ readelf -w a.out > READELF
readelf: Error: Invalid range list entry type 126
readelf: Error: Invalid range list entry type 60
...
The executable contains both a .debug_rnglists section (for CU
cpexprs.cc) and a .debug_ranges section (for other CUs, like crti.S). But
when executing display_debug_ranges for say, section .debug_rnglists it also
tries to use the range list references related to section .debug_ranges.
Fix this by filtering out the .debug_range references when handling
.debug_rnglists and vice versa.
binutils/ChangeLog:
2021-02-10 Tom de Vries <tdevries@suse.de>
PR binutils/27371
* dwarf.c (display_debug_ranges): Filter range lists according to
section.
Tom de Vries [Wed, 10 Feb 2021 10:43:46 +0000 (11:43 +0100)]
[gdb/testsuite] Fix tcl ERROR in gdb_load_no_complaints
In commit
cf2b2075299 "[gdb/symtab] Fix element type modification in
read_array_type" I factored out new proc with_complaints out of proc
gdb_load_no_complaints, but when fixing a rebase conflict pre-commit I made a
mistake in gdb_load_no_complaints that is now causing:
...
ERROR: tcl error sourcing dw2-ranges-psym.exp.
ERROR: can't read "save": no such variable
while executing
"gdb_test_no_output "set complaints $save" """
(procedure "gdb_load_no_complaints" line 14)
invoked from within
"gdb_load_no_complaints $binfile"
...
Fix this by removing the offending line.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-02-10 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_load_no_complaints): Remove unnecessary
"Restore saved setting of complaints".
Nick Clifton [Wed, 10 Feb 2021 09:56:33 +0000 (09:56 +0000)]
Remove debugging code accidentally included with the fix for PR 27384
* listing.c (buffer_line): Remove debugging code accidentally
included with the fix for PR 27384.
Tom Tromey [Wed, 10 Feb 2021 00:35:59 +0000 (17:35 -0700)]
Fix typo in stap_parse_argument_conditionally
This fixes a typo in an error message in
stap_parse_argument_conditionally.
gdb/ChangeLog
2021-02-09 Tom Tromey <tom@tromey.com>
* stap-probe.c (stap_parse_argument_conditionally): Fix typo.
GDB Administrator [Wed, 10 Feb 2021 00:00:16 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Tue, 9 Feb 2021 22:28:16 +0000 (23:28 +0100)]
[gdb/symtab] Fix element type modification in read_array_type
When running test-case gdb.fortran/function-calls.exp with target board
unix/gdb:debug_flags=-gdwarf-5, I run into:
...
(gdb) PASS: gdb.fortran/function-calls.exp: \
p derived_types_and_module_calls::pass_cart(c)
p derived_types_and_module_calls::pass_cart_nd(c_nd)^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x0000000000400f73 in derived_types_and_module_calls::pass_cart_nd \
(c=<error reading variable: Cannot access memory at address 0xc>) at \
function-calls.f90:130^M
130 pass_cart_nd = ubound(c%d,1,4)^M
The program being debugged was signaled while in a function called from GDB.^M
GDB has restored the context to what it was before the call.^M
To change this behavior use "set unwindonsignal off".^M
Evaluation of the expression containing the function^M
(derived_types_and_module_calls::pass_cart_nd) will be abandoned.^M
(gdb) FAIL: gdb.fortran/function-calls.exp: p
...
The problem originates in read_array_type, when reading a DW_TAG_array_type
with a dwarf-5 DW_TAG_generic_subrange child. This is not supported, and the
fallout of this is that rather than constructing a new array type, the code
proceeds to modify the element type.
Fix this conservatively by issuing a complaint and bailing out in
read_array_type when not being able to construct an array type, such that we
have:
...
(gdb) maint expand-symtabs function-calls.f90^M
During symbol reading: unable to find array range \
- DIE at 0xe1e [in module function-calls]^M
During symbol reading: unable to find array range \
- DIE at 0xe1e [in module function-calls]^M
(gdb) KFAIL: gdb.fortran/function-calls.exp: no complaints in srcfile \
(PRMS: symtab/27388)
...
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-09 Tom de Vries <tdevries@suse.de>
PR symtab/27341
* dwarf2/read.c (read_array_type): Return NULL when not being able to
construct an array type. Add assert to ensure that element_type is
not being modified.
gdb/testsuite/ChangeLog:
2021-02-09 Tom de Vries <tdevries@suse.de>
PR symtab/27341
* lib/gdb.exp (with_complaints): New proc, factored out of ...
(gdb_load_no_complaints): ... here.
* gdb.fortran/function-calls.exp: Add test-case.
Andrew Burgess [Tue, 9 Feb 2021 21:41:30 +0000 (21:41 +0000)]
gdb: revert "gdb: unify parts of the Linux and FreeBSD core dumping code"
This reverts commit
82a1fd3a4935fe665cf08bc6820942c4a091184c.
It was pointed out:
https://sourceware.org/pipermail/gdb-patches/2021-February/175750.html
that commit
82a1fd3a4935 caused GDB to have an unconditional
dependency on ELF specific parts of BFD. What this means is that if
GDB and BFD are built for a non-elf target then there will be
undefined symbol references within GDB.
The right solution isn't immediately obvious. So rather than rush a
fix in I'm reverting this commit for now, and will bring it back once
I have a good solution.
gdb/ChangeLog:
* gcore.c (struct gcore_collect_regset_section_cb_data): Delete.
(gcore_collect_regset_section_cb): Delete.
(gcore_collect_thread_registers): Delete.
(gcore_build_thread_register_notes): Delete.
(gcore_find_signalled_thread): Delete.
* gcore.h: Remove 'gdbsupport/gdb_signals.h' include and delete
'gdbarch' and 'thread_info' declarations.
(gcore_build_thread_register_notes): Delete declaration.
(gcore_find_signalled_thread): Likewise.
* fbsd-tdep.c: Remove 'gcore.h' include.
(struct fbsd_collect_regset_section_cb_data): New struct.
(fbsd_collect_regset_section_cb): New function.
(fbsd_collect_thread_registers): New function.
(struct fbsd_corefile_thread_data): New struct.
(fbsd_corefile_thread): New function.
(fbsd_make_corefile_notes): Call FreeBSD specific code.
* linux-tdep.c: Remove 'gcore.h' include.
(struct linux_collect_regset_section_cb_data): New struct.
(linux_collect_regset_section_cb): New function.
(linux_collect_thread_registers): New function.
(linux_corefile_thread): Call Linux specific code.
(find_signalled_thread): New function.
(linux_make_corefile_notes): Call find_signalled_thread.
Hafiz Abid Qadeer [Tue, 9 Feb 2021 17:11:28 +0000 (17:11 +0000)]
[testsuite] Don't use 'testfile' before 'standard_testfile'.
While running tests on arm-none-eabi, I noticed following errors in some
gdb.threads tests.
ERROR: can't read "testfile": no such variable
These were being caused by ${testfile} being used before 'standard_testfile'
which sets it. This patch just moves standard_testfile before the use.
2021-02-09 Abid Qadeer <abidh@codesourcery.com>
gdb/testsuite/ChangeLog:
* gdb.threads/signal-command-handle-nopass.exp: Call
'standard_testfile' before using 'testfile'.
* gdb.threads/signal-command-multiple-signals-pending.exp: Likewise.
* gdb.threads/signal-delivered-right-thread.exp: Likewise
* gdb.threads/signal-sigtrap.exp: Likewise
Tom Tromey [Tue, 9 Feb 2021 19:15:39 +0000 (12:15 -0700)]
Avoid crash from coerce_unspec_val_to_type
With a certain Ada program, ada-lang.c:coerce_unspec_val_to_type can
cause a crash. This function may copy a value, and in the particular
case in the crash, the new value's type is smaller than the original
type. This causes coerce_unspec_val_to_type to create a lazy value --
but the original value is also not_lval, so later, when the value is
un-lazied, gdb asserts.
As with the previous patch, we believe there is a compiler bug here,
but it is difficult to reproduce, so we're not completely certain.
In the particular case we saw, the original value has record type, and
the record holds some variable-length arrays. This leads to the
type's length being 0. At the same time, the value is optimized out.
This patch changes coerce_unspec_val_to_type to handle an
optimized-out value correctly.
It also slightly restructures this code to avoid a crash should a
not_lval value wind up here. This is a purely defensive change.
This change also made it clear that value_contents_copy_raw can now be
made static, so that is also done.
gdb/ChangeLog
2021-02-09 Tom Tromey <tromey@adacore.com>
* ada-lang.c (coerce_unspec_val_to_type): Avoid making lazy
not_lval value.
* value.c (value_contents_copy_raw): Now static.
* value.h (value_contents_copy_raw): Don't declare.
Tom Tromey [Tue, 9 Feb 2021 19:15:39 +0000 (12:15 -0700)]
Avoid crash in resolve_dynamic_struct
resolve_dynamic_struct says:
gdb_assert (type->num_fields () > 0);
However, a certain Ada program has a structure with no fields but with
a dynamic size, causing this assertion to fire.
It is difficult to be certain, but we think this is a compiler bug.
However, in the meantime this assertion does not seem to be checking
any kind of internal consistency; so this patch removes it.
gdb/ChangeLog
2021-02-09 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (resolve_dynamic_struct): Handle structure with no
fields.
Tom de Vries [Tue, 9 Feb 2021 14:37:24 +0000 (15:37 +0100)]
[binutils] Handle DW_FORM_ref_sig8 in get_type_abbrev_from_form
When compiling an exec like this:
...
$ gcc -fdebug-types-section hello.c -gdwarf-5
...
we run into:
...
$ readelf -w a.out > READELF
readelf: Warning: Unexpected form 20 encountered whilst finding \
abbreviation for type
...
Fix this by handling DW_FORM_ref_sig8 conservatively in
get_type_abbrev_from_form.
binutils/ChangeLog:
2021-02-09 Tom de Vries <tdevries@suse.de>
PR binutils/27370
* dwarf.c (get_type_abbrev_from_form): Handle DW_FORM_ref_sig8.
Nick Clifton [Tue, 9 Feb 2021 14:22:23 +0000 (14:22 +0000)]
Add a sanity check of files include by .incbin.
PR 27381
* read.c (s_incbin): Check that the file to be included is a
regular, non-directory file.
* testsuite/gas/all/pr27381.s: New test source file.
* testsuite/gas/all/pr27381.d: New test control file.
* testsuite/gas/all/pr27381.err: Expected error output for the new test.
* testsuite/gas/all/gas.exp: Run the new test.
Tom de Vries [Tue, 9 Feb 2021 13:27:28 +0000 (14:27 +0100)]
[binutils] Handle DW_UT_skeleton/split_compile in process_debug_info
With this exec:
...
$ gcc -gsplit-dwarf hello.c -gdwarf-5
...
we run into:
...
$ readelf -w a.out > READELF
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
...
Fix this by handling DW_UT_skeleton and DW_UT_split_compile in
process_debug_info.
Note that this just adds the parsing of DWO_id, but not yet any printing of
it.
Tested on x86_64-linux.
binutils/ChangeLog:
2021-02-09 Tom de Vries <tdevries@suse.de>
PR binutils/27386
* dwarf.c (process_debug_info): Handling DW_UT_skeleton and
DW_UT_split_compile.
Alan Modra [Mon, 8 Feb 2021 10:36:17 +0000 (21:06 +1030)]
Remove arm-symbianelf
* configure.ac: Delete arm*-*-symbianelf* entry.
* configure: Regenerate.
bfd/
* config.bfd (arm*-*-symbianelf*): Move from obsolete to removed.
* configure.ac: Delete symbian entries.
* elf-bfd.h (enum elf_target_os): Delete is_symbian.
* elf32-arm.c: Remove symbian support. Formatting.
* targets.c: Delete symbian entries.
* configure: Regenerate.
binutils/
* testsuite/lib/binutils-common.exp (supports_gnu_osabi): Remove
symbianelf.
gas/
* Makefile.am (TARG_ENV_HFILES): Remove config/te-symbian.h.
* config/tc-arm.c (elf32_arm_target_format): Remove TE_SYMBIAN
support.
* config/te-symbian.h: Delete.
* configure.tgt: Remove arm-*-symbianelf*.
* testsuite/gas/arm/arch4t-eabi.d: Don't mention symbianelf in
target selection.
* testsuite/gas/arm/arch4t.d: Likewise.
* testsuite/gas/arm/got_prel.d: Likewise.
* testsuite/gas/arm/mapdir.d: Likewise.
* testsuite/gas/arm/mapmisc.d: Likewise.
* testsuite/gas/arm/mapsecs.d: Likewise.
* testsuite/gas/arm/mapshort-eabi.d: Likewise.
* testsuite/gas/arm/thumb-eabi.d: Likewise.
* testsuite/gas/arm/thumb.d: Likewise.
* testsuite/gas/arm/thumbrel.d: Likewise.
* Makefile.in: Regenerate.
* po/POTFILES.in: Regenerate.
ld/
* Makefile.am (ALL_EMULATION_SOURCES): Remove earmsymbian.c.
Don't include symbian dep file.
* configure.tgt: Remove arm*-*-symbianelf* entry.
* emulparams/armsymbian.sh: Delete.
* ld.texi: Don't mention symbian.
* scripttempl/armbpabi.sc: Delete.
* testsuite/ld-arm/symbian-seg1.d: Delete.
* testsuite/ld-arm/symbian-seg1.s: Delete.
* testsuite/ld-arm/arm-elf.exp: Don't run symbian-seg1.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
Nick Clifton [Tue, 9 Feb 2021 12:53:32 +0000 (12:53 +0000)]
Prevent a bad .Psize expression from triggering a memory access violation.
PR 27384
* listing.c (listing_psize): Check the result of the width
expression before assigning it to paper_width.
* testsuite/gas/all/pr27384.s: New test source file.
* testsuite/gas/all/pr27384.d: New test control file.
* testsuite/gas/all/pr27384.err: Expected errors from new test.
* testsuite/gas/all/gas.exp: Run the new test.
Nick Clifton [Tue, 9 Feb 2021 10:51:40 +0000 (10:51 +0000)]
Add a test for PR 27355 - where corrupt assembler .file directives could trigger a segmentation fault.
PR 27355
* testsuite/gas/elf/pr27355.s: New test source file.
* testsuite/gas/elf/pr27355.d: New test control file.
* testsuite/gas/elf/pr27355.err: Expected errors from new test.
* testsuite/gas/elf/elf.exp: Run the new test.
GDB Administrator [Tue, 9 Feb 2021 00:00:14 +0000 (00:00 +0000)]
Automatic date update in version.in
Mike Frysinger [Sat, 16 Jan 2021 06:00:45 +0000 (01:00 -0500)]
opcodes: tic54x: namespace exported variables
The tic54x exports some fairly generic variable names that can
conflict with programs that use them, so put proper tic54x_
prefixes on all of them.
Luis Machado [Mon, 25 Jan 2021 12:46:49 +0000 (09:46 -0300)]
Build gdb.base/gnu-ifunc.exp with lazy binding
The test expects the ifunc resolver to run lazily, at a later stage.
Depending on the distro and toolchain configuration, this is not the
case. Some configurations use non-lazy binding and thus the ifunc resolver
resolves all the ifunc references very early in the process startup, before
main.
Ubuntu is one such case. It has switched its toolchains to pass -Wl,z,now by
default, since 16.04. This wasn't a problem before 20.04 (at least for
aarch64) because the toolchains did not support ifunc's.
Forcing lazy binding makes the test run as expected, as opposed to the 80 or
so failures it showed before the change.
Tested on aarch64-linux/x86_64-linux Ubuntu 20.04.
gdb/testsuite:
2021-02-08 Luis Machado <luis.machado@linaro.org>
* gdb.base/gnu-ifunc.exp (build): Pass -Wl,z,lazy.
Nick Clifton [Mon, 8 Feb 2021 18:31:21 +0000 (18:31 +0000)]
Fix an illegal memory access when parsing a corrupt assembler file.
PR 27355
* dwarf2dbg.c (allocate_filename_to_slot): Allocate the dirs array
if it has not already been created.
Tom de Vries [Mon, 8 Feb 2021 14:18:12 +0000 (15:18 +0100)]
[gdb/testsuite] Use DW_FORM_ref_addr in gdb.dwarf2/enqueued-cu-base-addr.exp
When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-dwz, I get:
...
gdb compile failed, dwz: enqueued-cu-base-addr: \
Couldn't find DIE at [100] referenced by DW_AT_type from DIE at [d8]
...
At 0xd8 we have DIE:
...
<1><d8>: Abbrev Number: 3 (DW_TAG_variable)
<d9> DW_AT_name : foo
<dd> DW_AT_type : <0x100>
<e1> DW_AT_const_value : 1
...
referring to:
...
<1><100>: Abbrev Number: 3 (DW_TAG_base_type)
<101> DW_AT_byte_size : 4
<102> DW_AT_encoding : 5 (signed)
<103> DW_AT_name : int
...
The reference is inter-CU, but the used abbrev uses DW_FORM_ref4:
...
3 DW_TAG_variable [no children]
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_const_value DW_FORM_sdata
DW_AT value: 0 DW_FORM value: 0
...
which is for intra-CU references.
Fix this by using a '%' instead of a ':' label prefix in the dwarf assembly.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-02-08 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/enqueued-cu-base-addr.exp: Fix inter-CU reference.
Shahab Vahedi [Thu, 31 Oct 2019 16:33:08 +0000 (17:33 +0100)]
gdb: Do not interrupt atomic sequences for ARC
When stepping over thread-lock related codes (in uClibc), the inferior process
gets stuck and never manages to enter the critical section:
------8<-------
1 size_t fwrite(const void * __restrict ptr, size_t size,
2 size_t nmemb, register FILE * __restrict stream)
3 {
4 size_t retval;
5 __STDIO_AUTO_THREADLOCK_VAR;
6
7 > __STDIO_AUTO_THREADLOCK(stream);
8
9 retval = fwrite_unlocked(ptr, size, nmemb, stream);
10
11 __STDIO_AUTO_THREADUNLOCK(stream);
12
13 return retval;
14 }
------>8-------
Here, we are at line 7. Using the "next" command leads no where.
However, setting a breakpoint on line 9 and issuing "continue" works.
Looking at the assembly instructions reveals that we're dealing with the
critical section entry code [1] that should never be interrupted, in this
case by the debugger's implicit breakpoints:
------8<-------
...
1 add_s r0,r13,0x38
2 mov_s r3,1
3 llock r2,[r0] <-.
4 brne.nt r2,0,14 --. |
5 scond r3,[r0] | |
6 bne -10 --|--'
7 brne_s r2,0,84 <-'
...
------>8-------
Lines 3 until 5 (inclusive) are supposed to be executed atomically.
Therefore, GDB should never (implicitly) insert a breakpoint on lines
4 and 5, else the program will try to acquire the lock again by jumping
back to line 3 and gets stuck in an infinite loop.
The solution is to make GDB aware of these patterns so it inserts
breakpoints after the sequence -- line 6 in this example.
[1]
https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/arc/bits/atomic.h#n46
------8<-------
({ \
__typeof(oldval) prev; \
\
__asm__ __volatile__( \
"1: llock %0, [%1] \n" \
" brne %0, %2, 2f \n" \
" scond %3, [%1] \n" \
" bnz 1b \n" \
"2: \n" \
: "=&r"(prev) \
: "r"(mem), "ir"(oldval), \
"r"(newval) /* can't be "ir". scond can't take limm for "b" */\
: "cc", "memory"); \
\
prev; \
})
------>8-------
"llock" (Load Locked) loads the 32-bit word pointed by the source
operand. If the load is completed without any interruption or
exception, the physical address is remembered, in Lock Physical Address
(LPA), and the Lock Flag (LF) is set to 1. LF is a non-architecturally
visible flag and is cleared whenever an interrupt or exception takes
place. LF is also cleared (atomically) whenever another process writes
to the LPA.
"scond" (Store Conditional) will write to the destination address if
and only if the LF is set to 1. When finished, with or without a write,
it atomically copies the LF value to ZF (Zero Flag).
These two instructions together provide the mechanism for entering a
critical section. The code snippet above comes from uClibc:
-----------------------
v3 (after Tom's remarks[2]):
handle_atomic_sequence()
- no need to initialize the std::vector with "{}"
- fix typo in comments: "conditial" -> "conditional"
- add braces to the body of "if" condition because of the comment line
arc_linux_software_single_step()
- make the performance slightly more efficient by moving a few
variables after the likely "return" point.
v2 (after Simon's remarks[3]):
- handle_atomic_sequence() gets a copy of an instruction instead of
a reference.
- handle_atomic_sequence() asserts if the given instruction is an llock.
[2]
https://sourceware.org/pipermail/gdb-patches/2021-February/175805.html
[3]
https://sourceware.org/pipermail/gdb-patches/2021-January/175487.html
gdb/ChangeLog:
PR tdep/27369
* arc-linux-tdep.c (handle_atomic_sequence): New.
(arc_linux_software_single_step): Call handle_atomic_sequence().
Andrew Burgess [Fri, 15 Jan 2021 10:31:19 +0000 (10:31 +0000)]
gdb: return true in TuiWindow.is_valid only if TUI is enabled
If the user implements a TUI window in Python, and this window
responds to GDB events and then redraws its window contents then there
is currently an edge case which can lead to problems.
The Python API documentation suggests that calling methods like erase
or write on a TUI window (from Python code) will raise an exception if
the window is not valid.
And the description for is_valid says:
This method returns True when this window is valid. When the user
changes the TUI layout, windows no longer visible in the new layout
will be destroyed. At this point, the gdb.TuiWindow will no longer
be valid, and methods (and attributes) other than is_valid will
throw an exception.
From this I, as a user, would expect that if I did 'tui disable' to
switch back to CLI mode, then the window would no longer be valid.
However, this is not the case.
When the TUI is disabled the windows in the TUI are not deleted, they
are simply hidden. As such, currently, the is_valid method continues
to return true.
This means that if the users Python code does something like:
def event_handler (e):
global tui_window_object
if tui_window_object->is_valid ():
tui_window_object->erase ()
tui_window_object->write ("Hello World")
gdb.events.stop.connect (event_handler)
Then when a stop event arrives GDB will try to draw the TUI window,
even when the TUI is disabled.
This exposes two bugs. First, is_valid should be returning false in
this case, second, if the user forgot to add the is_valid call, then I
believe the erase and write calls should be throwing an
exception (when the TUI is disabled).
The solution to both of these issues is I think bound together, as it
depends on having a working 'is_valid' check.
There's a rogue assert added into tui-layout.c as part of this
commit. While working on this commit I managed to break GDB such that
TUI_CMD_WIN was nullptr, this was causing GDB to abort. I'm leaving
the assert in as it might help people catch issues in the future.
This patch is inspired by the work done here:
https://sourceware.org/pipermail/gdb-patches/2020-December/174338.html
gdb/ChangeLog:
* python/py-tui.c (gdbpy_tui_window) <is_valid>: New member
function.
(REQUIRE_WINDOW): Call is_valid member function.
(REQUIRE_WINDOW_FOR_SETTER): New define.
(gdbpy_tui_is_valid): Call is_valid member function.
(gdbpy_tui_set_title): Call REQUIRE_WINDOW_FOR_SETTER instead.
* tui/tui-data.h (struct tui_win_info) <is_visible>: Check
tui_active too.
* tui/tui-layout.c (tui_apply_current_layout): Add an assert.
* tui/tui.c (tui_enable): Move setting of tui_active earlier in
the function.
gdb/doc/ChangeLog:
* python.texinfo (TUI Windows In Python): Extend description of
TuiWindow.is_valid.
gdb/testsuite/ChangeLog:
* gdb.python/tui-window-disabled.c: New file.
* gdb.python/tui-window-disabled.exp: New file.
* gdb.python/tui-window-disabled.py: New file.
Andrew Burgess [Mon, 8 Feb 2021 11:44:51 +0000 (11:44 +0000)]
gdb/python: don't allow the user to delete window title attributes
There's a bug in the python tui API. If the user tries to delete the
window title attribute then this will trigger undefined behaviour in
GDB due to a missing nullptr check.
gdb/ChangeLog:
* python/py-tui.c (gdbpy_tui_set_title): Check that the new value
for the title is not nullptr.
gdb/testsuite/ChangeLog:
* gdb.python/tui-window.exp: Add new tests.
* gdb.python/tui-window.py (TestWindow) <__init__>: Store
TestWindow object into global the_window.
<remote_title>: New method.
(delete_window_title): New function.
Andrew Burgess [Mon, 25 Jan 2021 15:46:58 +0000 (15:46 +0000)]
gdb/tui: don't add windows to global list from tui_layout:window::apply
This commit was inspired by this mailing list patch:
https://sourceware.org/pipermail/gdb-patches/2021-January/174713.html
Currently, calling tui_layout_window::apply will add the window from
the layout object to the global tui_windows list.
Unfortunately, when the user runs the 'winheight' command, this calls
tui_adjust_window_height, which calls the tui_layout_base::adjust_size
function, which can then call tui_layout_base::apply. The consequence
of this is that when the user does 'winheight' duplicate copies of a
window can be added to the global tui_windows list.
The original patch fixed this by changing the apply function to only
update the global list some of the time.
This patch takes a different approach. The apply function no longer
updates the global tui_windows list. Instead a new virtual function
is added to tui_layout_base which is used to gather all the currently
applied windows into a vector. Finally tui_apply_current_layout is
updated to make use of this new function to update the tui_windows
list.
The benefits I see in this approach are, (a) the apply function now no
longer touches global state, this solves the immediate problem,
and (b) now that tui_windows is updated directly in the function
tui_apply_current_layout, we can drop the saved_tui_windows global.
gdb/ChangeLog:
* tui-layout.c (saved_tui_windows): Delete.
(tui_apply_current_layout): Don't make use of saved_tui_windows,
call new get_windows member function instead.
(tui_get_window_by_name): Check in tui_windows.
(tui_layout_window::apply): Don't add to tui_windows.
* tui-layout.h (tui_layout_base::get_windows): New member function.
(tui_layout_window::get_windows): Likewise.
(tui_layout_split::get_windows): Likewise.
gdb/testsuite/ChangeLog:
* gdb.tui/winheight.exp: Add more tests.
Andrew Burgess [Mon, 8 Feb 2021 11:11:24 +0000 (11:11 +0000)]
gdb/tui: restore delete of window objects
In commit:
commit
f237f998d1168139d599c550d54169cd8f94052d
Date: Mon Jan 25 18:43:19 2021 +0000
gdb/tui: remove special handling of locator/status window
I accidentally remove a call to delete the tui window objects. Now
every time GDB changes tui layout it is leaking windows.
gdb/ChangeLog:
* tui/tui-layout.c (tui_apply_current_layout): Restore the delete
of the window objects.
Andrew Burgess [Mon, 18 Jan 2021 10:03:21 +0000 (10:03 +0000)]
gdb/python: reformat an error string
While working on another patch I noticed an oddly formatted error
message in the Python code.
When 'set python print-stack message' is in effect then consider this
Python script:
class TestCommand (gdb.Command):
def __init__ (self):
gdb.Command.__init__ (self, "test-cmd", gdb.COMMAND_DATA)
def invoke(self, args, from_tty):
raise RuntimeError ("bad")
TestCommand ()
And this GDB session:
(gdb) source path/to/python/script.py
(gdb) test-cmd
Python Exception <class 'RuntimeError'> bad:
Error occurred in Python: bad
The line 'Python Exception <class 'RuntimeError'> bad:' doesn't look
terrible in this situation, the colon at the end of the first line
makes sense given the second line.
However, there are places in GDB where there is no second line
printed, for example consider this python script:
def stop_listener (e):
raise RuntimeError ("bad")
gdb.events.stop.connect (stop_listener)
Then this GDB session:
(gdb) file helloworld.exe
(gdb) start
Temporary breakpoint 1 at 0x40112a: file hello.c, line 6.
Starting program: helloworld.exe
Temporary breakpoint 1, main () at hello.c:6
6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'> bad:
In this case there is no auxiliary information displayed after the
warning, and the line ending in the colon looks weird to me.
A quick survey of the code seems to indicate that it is not uncommon
for there to be no auxiliary information line printed, its not just
the one case I found above.
I propose that the line that currently looks like this:
Python Exception <class 'RuntimeError'> bad:
Be reformatted like this:
Python Exception <class 'RuntimeError'>: bad
I think this looks fine then in either situation. The first now looks
like this:
(gdb) test-cmd
Python Exception <class 'RuntimeError'>: bad
Error occurred in Python: bad
And the second like this:
(gdb) si
0x000000000040112f 6 printf ("Hello World\n");
Python Exception <class 'RuntimeError'>: bad
There's just two tests that needed updating. Errors are checked for
in many more tests, but most of the time the pattern doesn't care
about the colon.
gdb/ChangeLog:
* python/python.c (gdbpy_print_stack): Reformat an error message.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter.exp: Update expected results.
* gdb.python/python.exp: Update expected results.
Andrew Burgess [Mon, 1 Feb 2021 11:39:39 +0000 (11:39 +0000)]
sim/rx: enable build with warnings
The rx simulator now has no build warnings. Delete the call to
SIM_AC_OPTION_WARNINGS in configure.ac, the default yes will be
provided by SIM_AC_OUTPUT.
sim/rx/ChangeLog:
* configure: Regenerate.
* configure.ac (SIM_AC_OPTION_WARNINGS): Delete call.
Andrew Burgess [Mon, 1 Feb 2021 11:37:46 +0000 (11:37 +0000)]
sim/rx: avoid pointer arithmetic on void * pointers
Pointer arithmetic on void * pointers results in a GCC warning. Avoid
the warning by casting the pointer to its actual type earlier in the
function.
sim/rx/ChangeLog:
* mem.c (mem_put_blk): Rename parameter, add cast from parameter
type to local type. Remove cast later in the function.
(mem_get_blk): Likewise.
* mem.h (mem_put_blk): Rename parameter to match definition.
(mem_get_blk): Likewise.
Andrew Burgess [Mon, 1 Feb 2021 11:28:09 +0000 (11:28 +0000)]
sim/rx: add some missing includes
In load.c there's some GCC warnings about undefined
functions (bfd_get_elf_phdr_upper_bound and bfd_get_elf_phdrs). To
get the declarations of these functions include 'elf-bfd.h'. This
headers also pulls in other elf related headers, like 'elf/internal.h'
and 'elf/common.h', so these no longer need to be explicitly included
from load.c.
In trace.c and include for trace.h is missing, again this results in
GCC warnings for missing function declarations.
sim/rx/ChangeLog:
* load.c: Replace 'elf/internal.h' and 'elf/common.h' includes
with 'elf-bfd.h' include.
* trace.c: Add 'trace.h' include.
Andrew Burgess [Mon, 1 Feb 2021 11:23:53 +0000 (11:23 +0000)]
sim/rx: use PRIx64 in printf format string
Silence a GCC compiler warning by using PRIx64 in printf format string
instead of hard coded "llx".
sim/rx/ChangeLog:
* reg.c (trace_register_changes): Use PRIx64 in printf format
string.
Andrew Burgess [Mon, 1 Feb 2021 11:16:29 +0000 (11:16 +0000)]
sim/rx: move some variable declarations to the start of the block
For sim code variables still need to be declared at the start of the
enclosing block. This silences a few GCC warnings.
sim/rx/ChangeLog:
* syscalls.c (rx_syscall): Move declaration of some variables to
the start of the enclosing block.
* trace.c (load_file_and_line): Likewise.
Andrew Burgess [Mon, 1 Feb 2021 11:12:56 +0000 (11:12 +0000)]
sim/rx: provide a format string for printf
Calling printf with the format being a non constant string results in
a GCC warning:
warning: format not a string literal and no format arguments [-Wformat-nonliteral]
Provide a constant format string to printf in the few places this
warning is triggered.
sim/rx/ChangeLog:
* reg.c (fpsw2str): Provide a format string to printf.
(trace_register_changes): Likewise.
Andrew Burgess [Thu, 28 Jan 2021 17:29:11 +0000 (17:29 +0000)]
sim/rx: delete an unused function
This function is not used.
sim/rx/ChangeLog:
* err.c (execution_error_exit_all): Delete.
Andrew Burgess [Thu, 28 Jan 2021 17:27:44 +0000 (17:27 +0000)]
sim/rx: mark some functions as static
Some functions that should be marked static.
sim/rx/ChangeLog:
* fpu.c (check_exceptions): Make static.
* gdb-if.c (handle_step): Likewise.
* mem.c (mem_put_byte): Likewise.
Andrew Burgess [Thu, 28 Jan 2021 17:24:45 +0000 (17:24 +0000)]
sim/rx: fill in missing 'void' for empty argument lists
Ensure we have 'void' inside empty argument lists. This was causing
several warnings for the rx simulator.
sim/rx/ChangeLog:
* cpu.h (trace_register_changes): Add void parameter type.
* err.c (ee_overrides): Likewise.
* mem.c (mem_usage_stats): Likewise.
(e): Likewise.
* reg.c (stack_heap_stats): Likewise.
* rx.c (pop): Likewise.
(poppc): Likewise.
(decode_opcode): Likewise.
* syscalls.c (arg): Likewise.
Andrew Burgess [Thu, 28 Jan 2021 17:17:08 +0000 (17:17 +0000)]
sim/rx: fix an issue where we try to modify a const string
While experimenting with switching on warnings for the rx simulator I
discovered this bug. In sim_do_command we get passed a 'const char *'
argument. We create a copy of this string to work with locally, but
then while processing this we accidentally switch back to reference
the original string.
sim/rx/ChangeLog:
* gdb-if.c (sim_do_command): Work with a copy of the command.
Andrew Burgess [Mon, 25 Jan 2021 18:58:37 +0000 (18:58 +0000)]
sim/rx: define sim_memory_map
The rx simulator doesn't define sim_memory_map and so fails to link
with GDB. Define it now to return NULL, this can be extended later to
return an actual memory map if anyone wants this functionality.
sim/rx/ChangeLog:
* gdb-if.c (sim_memory_map): New function.
Andrew Burgess [Fri, 22 Jan 2021 17:40:19 +0000 (17:40 +0000)]
gdb/tui: fix issue with handling the return character
My initial goal was to fix our gdb/testsuite/lib/tuiterm.exp such that
it would correctly support (some limited) scrolling of the command
window.
What I observe is that when sending commands to the tui command window
in a test script with:
Term::command "p 1"
The command window would be left looking like this:
(gdb)
(gdb) p 1$1 = 1
(gdb)
When I would have expected it to look like this:
(gdb) p 1
$1 = 1
(gdb)
Obviously a bug in our tuiterm.exp library, right???
Wrong!
Turns out there's a bug in GDB.
If in GDB I enable the tui and then type (slowly) the 'p 1\r' (the \r
is pressing the return key at the end of the string), then you do
indeed get the "expected" terminal output.
However, if instead I copy the 'p 1\r' string and paste it into the
tui in one go then I now see the same corrupted output as we do when
using tuiterm.exp.
It turns out the problem is that GDB fails when handling lots of input
arriving quickly with a \r (or \n) on the end.
The reason for this bug is as follows:
When the tui is active the terminal is in no-echo mode, so characters
sent to the terminal are not echoed out again. This means that when
the user types \r, this is not echoed to the terminal.
The characters read in are passed to readline and \r indicates that
the command line is complete and ready to be processed. However, the
\r is not included in readlines command buffer, and is NOT printed by
readline when is displays its buffer to the screen.
So, in GDB we have to manually spot the \r when it is read in and
update the display. Printing a newline character to the output and
moving the cursor to the next line. This is done in tui_getc_1.
Now readline tries to reduce the number of write calls. So if we very
quickly (as in paste in one go) the text 'p 1' to readline (this time
with no \r on the end), then readline will fetch the fist character
and add it to its internal buffer. But before printing the character
out readline checks to see if there's more input incoming. As we
pasted multiple characters, then yes, readline sees the ' ' and adds
this to its buffer, and finally the '1', this too is added to the
buffer.
Now if at this point we take a break, readline sees there is no more
input available, and so prints its buffer out.
Now when we press \r the code in tui_getc_1 kicks in, adds a \n to the
output and moves the cursor to the next line.
But, if instead we paste 'p 1\r' in one go then readline adds 'p 1' to
its buffer as before, but now it sees that there is still more input
available. Now it fetches the '\r', but this triggers the newline
behaviour, we print '\n' and move to the next line - however readline
has not printed its buffer yet!
So finally we end up on the next line. There's no more input
available so readline prints its buffer, then GDB gets passed the
buffer, handles it, and prints the result.
The solution I think is to put of our special newline insertion code
until we know that readline has finished printing its buffer. Handily
we know when this is - the next thing readline does is pass us the
command line buffer for processing. So all we need to do is hook in
to the command line processing, and before we pass the command line to
GDB's internals we do all of the magic print a newline and move the
cursor to the next line stuff.
Luckily, GDB's interpreter mechanism already provides the hooks we
need to do this. So all I do here is move the newline printing code
from tui_getc_1 into a new function, setup a new input_handler hook
for the tui, and call my new newline printing function.
After this I can enable the tui and paste in 'p 1\r' and see the
correct output.
Also the tuiterm.exp library will now see non-corrupted output.
gdb/ChangeLog:
* tui/tui-interp.c (tui_command_line_handler): New function.
(tui_interp::resume): Register tui_command_line_handler as the
input_handler.
* tui/tui-io.c (tui_inject_newline_into_command_window): New
function.
(tui_getc_1): Delete handling of '\n' and '\r'.
* tui-io.h (tui_inject_newline_into_command_window): Declare.
gdb/testsuite/ChangeLog:
* gdb.tui/scroll.exp: Tighten expected results. Remove comment
about bug in GDB, update expected results, and add more tests.
Andrew Burgess [Fri, 22 Jan 2021 16:25:15 +0000 (16:25 +0000)]
gdb/testsuite: fix implementation of delete line in tuiterm.exp
The implementation of the delete line escape sequence in tuiterm.exp
was wrong. Delete should take a count and then delete COUNT lines at
the current cursor location, all remaining lines in the scroll region
are moved up to replace the deleted lines, with blank lines being
added at the end of the scroll region.
It's not clear to me what "scroll region" means here (or at least how
that is defined), but for now I'm just treating the whole screen as
the scroll region, which seems to work fine.
In contrast the current broken implementation deletes COUNT lines at
the cursor location moving the next COUNT lines up to fill the gap.
The rest of the screen is then cleared.
gdb/testsuite/ChangeLog:
* gdb.tui/scroll.exp: New file.
* gdb.tui/tui-layout-asm-short-prog.exp: Update expected results.
* lib/tuiterm.exp (Term::_csi_M): Delete count lines, scroll
remaining lines up.
(Term::check_region_contents): New proc.
(Term::check_box_contents): Use check_region_contents.
GDB Administrator [Mon, 8 Feb 2021 00:00:11 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Sun, 7 Feb 2021 21:11:16 +0000 (13:11 -0800)]
ld: Remove x86 ISA level run-time tests
Remove x86 ISA level run-time tests since with glibc 2.33, they will fail
to run on machines with lesser x86 ISA level:
tmpdir/property-5-pie: CPU ISA level is lower than required
PR ld/27358
* testsuite/ld-i386/i386.exp: Remove property 3/4/5 run-time
tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
Hannes Domani [Tue, 5 Jan 2021 16:29:02 +0000 (17:29 +0100)]
Don't draw register sub windows outside the visible area
If the regs window is not big enough to show all registers, the
registers whose values changed are always drawn, even if they are not
in the currently visible area.
So this marks the invisible register sub windows with y=0, and skips
their rerender call in check_register_values.
gdb/ChangeLog:
2021-02-07 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-regs.c (tui_data_window::display_registers_from):
Mark invisible register sub windows.
(tui_data_window::check_register_values): Ignore invisible
register sub windows.
Hannes Domani [Tue, 5 Jan 2021 16:10:15 +0000 (17:10 +0100)]
Don't fill regs window with a negative number of spaces
Function n_spaces can't handle negative values, and returns an invalid
pointer in this case.
gdb/ChangeLog:
2021-02-07 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-regs.c (tui_data_item_window::rerender): Don't call
n_spaces with a negative value.
Hannes Domani [Tue, 5 Jan 2021 15:56:01 +0000 (16:56 +0100)]
Refresh regs window in display_registers_from
Otherwise the register window is redrawn empty when scrolling or
changing its size with winheight.
gdb/ChangeLog:
2021-02-07 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-regs.c (tui_data_window::display_registers_from):
Add refresh_window call.
Hannes Domani [Fri, 18 Dec 2020 17:23:41 +0000 (18:23 +0100)]
Also compare frame_id_is_next in frapy_richcompare
The last frame in a corrupt stack stores the frame_id of the next frame,
so these two frames currently compare as equal.
So if you have a backtrace where the oldest frame is corrupt, this happens:
(gdb) py
>f = gdb.selected_frame()
>while f.older():
> f = f.older()
>print(f == f.newer())
>end
True
With this change, that same example returns False.
gdb/ChangeLog:
2021-02-07 Hannes Domani <ssbssa@yahoo.de>
* python/py-frame.c (frapy_richcompare): Compare frame_id_is_next.
Alan Modra [Sun, 7 Feb 2021 02:53:34 +0000 (13:23 +1030)]
asan: unwind-ia64.c: stack buffer overflow
Printing "invalid" is better than printing an uninitialised buffer
and occasionally running off the end of the buffer.
* unwind-ia64.c (unw_print_xyreg): Don't leave output buffer
uninitialised on invalid input.
GDB Administrator [Sun, 7 Feb 2021 00:00:10 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom de Vries [Sat, 6 Feb 2021 22:22:03 +0000 (23:22 +0100)]
[gdb/testsuite] Fix gdb.tui/tui-layout-asm.exp with -m32
When running test-case gdb.tui/tui-layout-asm.exp with target board
unix/-m32, we run into:
...
FAIL: gdb.tui/tui-layout-asm.exp: scroll to end of assembler (scroll failed)
...
Comparing screen dumps (edited a bit to fit column width) before:
...
0 +--------------------------------------------------------------------+
1 | 0x8049194 <__libc_csu_init+68> call *-0x104(%ebp,%esi,4) |
2 | 0x804919b <__libc_csu_init+75> add $0x1,%esi |
3 | 0x804919e <__libc_csu_init+78> add $0x10,%esp |
4 | 0x80491a1 <__libc_csu_init+81> cmp %esi,%ebx |
5 | 0x80491a3 <__libc_csu_init+83> jne 0x8049188 <__...> |
6 | 0x80491a5 <__libc_csu_init+85> add $0xc,%esp |
7 | 0x80491a8 <__libc_csu_init+88> pop %ebx |
8 | 0x80491a9 <__libc_csu_init+89> pop %esi |
9 | 0x80491aa <__libc_csu_init+90> pop %edi |
10 | 0x80491ab <__libc_csu_init+91> pop %ebp |
11 | 0x80491ac <__libc_csu_init+92> ret |
12 | 0x80491ad lea 0x0(%esi),%esi |
13 | 0x80491b0 <__libc_csu_fini> ret |
14 +--------------------------------------------------------------------+
...
and after:
...
0 +--------------------------------------------------------------------+
1 | 0x804919b <__libc_csu_init+75> add $0x1,%esi |
2 | 0x804919e <__libc_csu_init+78> add $0x10,%esp |
3 | 0x80491a1 <__libc_csu_init+81> cmp %esi,%ebx |
4 | 0x80491a3 <__libc_csu_init+83> jne 0x8049188 <__...> |
5 | 0x80491a5 <__libc_csu_init+85> add $0xc,%esp |
6 | 0x80491a8 <__libc_csu_init+88> pop %ebx |
7 | 0x80491a9 <__libc_csu_init+89> pop %esi |
8 | 0x80491aa <__libc_csu_init+90> pop %edi |
9 | 0x80491ab <__libc_csu_init+91> pop %ebp |
10 | 0x80491ac <__libc_csu_init+92> ret |
11 | 0x80491ad lea 0x0(%esi),%esi |
12 | 0x80491b0 <__libc_csu_fini> ret |
13 | 0x80491b1 <__x86.get_pc_thunk.bp> mov (%esp),%ebp |
14 +--------------------------------------------------------------------+
...
it seems the mismatch comes from the extra indentation forced by the longer
<__x86.get_pc_thunk.bp> that was scrolled in.
Fix this by ignoring whitespace when comparing scrolled lines.
Tested on x86_64-linux, using -m64 and -m32.
gdb/testsuite/ChangeLog:
2021-02-06 Tom de Vries <tdevries@suse.de>
PR testsuite/26922
* gdb.tui/tui-layout-asm.exp: Ignore whitespace mismatches when
scrolling.
Mike Frysinger [Tue, 2 Feb 2021 04:51:24 +0000 (23:51 -0500)]
sim: erc32/m32c/rl78: add sim_memory_map stub for gdb
These ports don't use the common sim core, so they weren't providing
a sim_memory_map for gdb, so they failed to link with the new memory
map logic added for the sim. Add stubs to fix.
Mike Frysinger [Mon, 23 Mar 2015 04:44:54 +0000 (00:44 -0400)]
sim: watchpoints: use common sim_pc_get
Few arches implement STATE_WATCHPOINTS()->pc while all of them implement
sim_pc_get. Lets switch the sim-watch core for monitoring pc events to
the sim_pc_get API so this module works for all ports, and then we can
delete this old back channel of snooping in the port's cpu state -- the
code needs the pointer to the pc storage so that it can read out bytes
and compare them to the watchrange.
This also fixes the logic on multi-cpu sims by removing the limitation
of only being able to watch CPU0's state.
Mike Frysinger [Sat, 6 Feb 2021 17:07:05 +0000 (12:07 -0500)]
sim: add ChangeLog entries for last commits
Mike Frysinger [Sun, 17 Jan 2021 19:41:35 +0000 (14:41 -0500)]
sim: igen: drop libiberty linkage
This dir doesn't use anything from libiberty, so drop the linkage.
Mike Frysinger [Sun, 17 Jan 2021 18:48:08 +0000 (13:48 -0500)]
sim: common: switch AC_CONFIG_HEADERS
The AC_CONFIG_HEADER macro is long deprecated, so switch to the
newer form. This also gets rid of the position limitation, and
drops support for an argument to SIM_AC_COMMON which we haven't
used anywhere.
Mike Frysinger [Sun, 17 Jan 2021 18:39:03 +0000 (13:39 -0500)]
sim: drop use of bfd/configure.host
These settings might have made sense in darker compiler times, but I
think they're largely obsolete now. Looking through the values that
get used in HDEFINES, it's quite limited, and configure itself should
handle them. If we still need something, we can leverage standard
autoconf macros instead, after we get a clear user report.
TDEFINES was never set anywhere and was always empty, so prune that.
GDB Administrator [Sat, 6 Feb 2021 00:00:14 +0000 (00:00 +0000)]
Automatic date update in version.in
Alan Modra [Fri, 5 Feb 2021 12:03:08 +0000 (22:33 +1030)]
PR27349, ar breaks symlinks
PR 27349
* rename.c (smart_rename): Test for existence and type of output
file with lstat.
Paul E. Murphy [Fri, 22 Jan 2021 19:55:45 +0000 (13:55 -0600)]
gnulib: update to
776af40e0
This fixes PR27184, a failure to compile gdb due to
cdefs.h being out of sync with glibc on ppc64le targets
which are compiled with -mabi=ieeelongdouble and glibc
2.32.
Likewise, update usage of _GL_ATTRIBUTE_FORMAT_PRINTF to
_GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD.
Likewise, disable newly added rpl_free gnulib api in
gdbserver support libraries.
Likewise, undefine read/write macros before redefining them
on mingw targets.
Likewise, wrap C++ usage of free with GNULIB_NAMESPACE namespace
as needed.
Change-Id: I86517613c0d8ac8f5ea45bbc4ebe2b54a3aef29f
Simon Marchi [Fri, 5 Feb 2021 18:06:33 +0000 (13:06 -0500)]
gdb: symmisc.c: remove std_{in,out,err}
These are likely not very useful, remove them.
gdb/ChangeLog:
* symmisc.c (std_in, std_out, std_err): Remove.
(_initialize_symmisc): Don't set std_in, std_out and std_err.
Change-Id: I140bfffd7fb655d39c32333bb53924b91b1eb13c
Tom de Vries [Fri, 5 Feb 2021 16:47:07 +0000 (17:47 +0100)]
[gdb/breakpoints] Handle glibc with debuginfo in create_exception_master_breakpoint
The test-case nextoverthrow.exp is failing on targets with unstripped libc.
This is a regression since commit
1940319c0ef "[gdb] Fix internal-error in
process_event_stop_test".
The problem is that this code in create_exception_master_breakpoint:
...
for (objfile *sepdebug = obj->separate_debug_objfile;
sepdebug != nullptr; sepdebug = sepdebug->separate_debug_objfile)
if (create_exception_master_breakpoint_hook (sepdebug))
...
iterates over all the separate debug object files, but fails to handle the
case that obj itself has the debug info we're looking for.
Fix this by using the separate_debug_objfiles () range instead, which does
iterate both over obj and the obj->separate_debug_objfile chain.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR breakpoints/27330
* breakpoint.c (create_exception_master_breakpoint): Handle case that
glibc object file has debug info.
Tom de Vries [Fri, 5 Feb 2021 16:47:07 +0000 (17:47 +0100)]
[gdb/symtab] Handle DW_TAG_type_unit in process_psymtab_comp_unit
When running test-case gdb.cp/cpexprs-debug-types.exp with target board
unix/gdb:debug_flags=-gdwarf-5, I run into:
...
(gdb) file cpexprs-debug-types^M
Reading symbols from cpexprs-debug-types...^M
ERROR: Couldn't load cpexprs-debug-types into GDB (eof).
ERROR: Couldn't send delete breakpoints to GDB.
ERROR: GDB process no longer exists
GDB process exited with wait status 23054 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
...
We're running into this abort in process_psymtab_comp_unit:
...
switch (reader.comp_unit_die->tag)
{
case DW_TAG_compile_unit:
this_cu->unit_type = DW_UT_compile;
break;
case DW_TAG_partial_unit:
this_cu->unit_type = DW_UT_partial;
break;
default:
abort ();
}
...
because reader.comp_unit_die->tag == DW_TAG_type_unit.
Fix this by adding a DW_TAG_type_unit case.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR symtab/27333
* dwarf2/read.c (process_psymtab_comp_unit): Handle DW_TAG_type_unit.
Tom de Vries [Fri, 5 Feb 2021 16:47:07 +0000 (17:47 +0100)]
[gdb/breakpoints] Fix segfault for catch syscall -1
Using a hello world a.out, I run into a segfault:
...
$ gcc hello.c
$ gdb -batch a.out -ex "catch syscall -1" -ex r
Catchpoint 1 (syscall -1)
Aborted (core dumped)
...
Fix this by erroring out if a negative syscall number is used in the
catch syscall command.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR breakpoints/27313
* break-catch-syscall.c (catch_syscall_split_args): Reject negative
syscall numbers.
gdb/testsuite/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR breakpoints/27313
* gdb.base/catch-syscall.exp: Check that "catch syscall -1" is
rejected.
Tom Tromey [Fri, 5 Feb 2021 14:17:11 +0000 (07:17 -0700)]
Return unique_ptr from language_defn::get_compile_context
This changes language_defn::get_compile_context to return a
unique_ptr. This makes the ownership transfer clear.
gdb/ChangeLog
2021-02-05 Tom Tromey <tom@tromey.com>
* compile/compile-c-support.c (get_compile_context)
(c_get_compile_context, cplus_get_compile_context): Change return
type.
* language.c (language_defn::get_compile_instance): New method.
* language.h (language_defn::get_compile_instance): Change return
type. No longer inline.
* c-lang.c (c_language::get_compile_instance): Change return type.
(cplus_language::get_compile_instance): Change return type.
* c-lang.h (c_get_compile_context, cplus_get_compile_context):
Change return type.
* compile/compile.c (compile_to_object): Update.
Tom Tromey [Fri, 5 Feb 2021 14:11:01 +0000 (07:11 -0700)]
Extract symbol-writing function from parsers
I noticed that several parsers shared the same code to write a symbol
reference to an expression. This patch factors this code out into a
new function.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-02-05 Tom Tromey <tom@tromey.com>
* parser-defs.h (write_exp_symbol_reference): Declare.
* parse.c (write_exp_symbol_reference): New function.
* p-exp.y (variable): Use write_exp_symbol_reference.
* m2-exp.y (variable): Use write_exp_symbol_reference.
* f-exp.y (variable): Use write_exp_symbol_reference.
* d-exp.y (PrimaryExpression): Use write_exp_symbol_reference.
* c-exp.y (variable): Use write_exp_symbol_reference.
Nick Clifton [Fri, 5 Feb 2021 11:15:50 +0000 (11:15 +0000)]
Remove Richard Henderson as the Alpha maintainer
Tom de Vries [Fri, 5 Feb 2021 09:56:39 +0000 (10:56 +0100)]
[gdb/testsuite] Add KFAILs for PR symtab/24549
When an executable contains an index such as a .gdb_index or .debug_names
section, gdb ignores the DW_AT_subprogram attribute.
This problem has been filed as PR symtab/24549.
Add KFAILs for this PR in test-cases gdb.dwarf2/main-subprogram.exp and
gdb.fortran/mixed-lang-stack.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/main-subprogram.exp: Add KFAIL for PR symtab/24549.
* gdb.fortran/mixed-lang-stack.exp: Same.
Tom de Vries [Fri, 5 Feb 2021 09:56:39 +0000 (10:56 +0100)]
[gdb/exp] Fix assert when adding ptr to imaginary unit
I'm running into this assertion failure:
...
$ gdb -batch -ex "p (void *)0 - 5i"
gdbtypes.c:3430: internal-error: \
type* init_complex_type(const char*, type*): Assertion \
`target_type->code () == TYPE_CODE_INT \
|| target_type->code () == TYPE_CODE_FLT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...
This is a regression since commit
c34e8714662 "Implement complex arithmetic".
Before that commit we had:
...
(gdb) p (void *)0 - 5i
Argument to arithmetic operation not a number or boolean.
...
Fix this in complex_binop by throwing an error, such that we have:
...
(gdb) print (void *)0 - 5i
Argument to complex arithmetic operation not supported.
...
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR exp/27265
* valarith.c (complex_binop): Throw an error if complex type can't
be created.
gdb/testsuite/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR exp/27265
* gdb.base/complex-parts.exp: Add tests.
Tom de Vries [Fri, 5 Feb 2021 08:14:25 +0000 (09:14 +0100)]
[gdb/symtab] Fix duplicate CUs in create_cus_from_debug_names_list
When running test-case gdb.dwarf2/clang-debug-names.exp, I run into the
following warning:
...
(gdb) file clang-debug-names^M
Reading symbols from clang-debug-names...^M
warning: Section .debug_aranges in clang-debug-names has duplicate \
debug_info_offset 0xc7, ignoring .debug_aranges.^M
...
This is caused by a missing return in commit
3ee6bb113af "[gdb/symtab] Fix
incomplete CU list assert in .debug_names".
Fix this by adding the missing return, such that we have instead this warning:
...
(gdb) file clang-debug-names^M
Reading symbols from clang-debug-names...^M
warning: Section .debug_aranges in clang-debug-names \
entry at offset 0 debug_info_offset 0 does not exists, \
ignoring .debug_aranges.^M
...
which is a known problem filed as PR25969 - "Ignoring .debug_aranges with
clang .debug_names".
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR symtab/27307
* dwarf2/read.c (create_cus_from_debug_names_list): Add missing
return.
gdb/testsuite/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
PR symtab/27307
* gdb.dwarf2/clang-debug-names.exp: Check file command warnings.
Tom de Vries [Fri, 5 Feb 2021 08:14:25 +0000 (09:14 +0100)]
[gdb/symtab] Fix indentation in create_cus_from_debug_names_list
Fix indentation in !map.augmentation_is_gdb part of
create_cus_from_debug_names_list.
gdb/ChangeLog:
2021-02-05 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (create_cus_from_debug_names_list): Fix indentation.
Eli Zaretskii [Fri, 5 Feb 2021 07:05:58 +0000 (09:05 +0200)]
Fix typos in comments added in PR 27252 fix
PR 27252
* elfedit.c (check_file):
* bucomm.c (get_file_size): Fix typos in comments.
Alan Modra [Thu, 4 Feb 2021 12:50:42 +0000 (23:20 +1030)]
ld testsuite on x86_64 with --enable-shared
These tests fail since
1c9c9b9b5552, due to not being able to access
some scripts:
FAIL: Absolute non-overflowing relocs
FAIL: ld-i386/iamcu-1
FAIL: ld-i386/iamcu-2
The problem is that when built with --enable-shared the ld-new
executable sits in a .libs/ directory.
* Makefile.am (check-DEJAGNU): Set up ldscripts link in .libs.
* Makefile.in: Regenerate.
Nelson Chu [Fri, 5 Feb 2021 03:12:59 +0000 (11:12 +0800)]
RISC-V: PR27348, Remove the obsolete OP_*CUSTOM_IMM.
include/
PR 27348
* opcode/riscv.h: Remove obsolete OP_*CUSTOM_IMM.
Nelson Chu [Fri, 5 Feb 2021 02:42:31 +0000 (10:42 +0800)]
RISC-V: PR27348, Remove obsolete Xcustom support.
include/
PR 27348
* opcode/riscv-opc.h: Remove obsolete Xcustom support.
Alan Modra [Fri, 5 Feb 2021 02:29:16 +0000 (12:59 +1030)]
PR27345, binutils/arsup.c: lstat() not available on all targets
We can just use stat here, the same as is done in ar.c:open_inarch.
PR 27345
* arsup.c (ar_save): Use stat rather than lstat.
Mike Frysinger [Tue, 16 Jun 2015 15:44:48 +0000 (21:29 +0545)]
gdb: riscv: enable sim integration
Now the simulator can be loaded via gdb using "target sim".
Mike Frysinger [Thu, 21 May 2015 15:16:45 +0000 (23:16 +0800)]
sim: riscv: new port
This is a hand-written implementation that should have fairly complete
coverage for the base integer instruction set ("i"), and for the atomic
("a") and integer multiplication+division ("m") extensions. It also
covers 32-bit & 64-bit targets.
The unittest coverage is a bit weak atm, but should get better.
GDB Administrator [Fri, 5 Feb 2021 00:00:11 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Thu, 4 Feb 2021 20:45:20 +0000 (15:45 -0500)]
gdb: make target_is_non_stop_p return bool
gdb/ChangeLog:
* target.c (target_is_non_stop_p): Return bool.
* target.h (target_is_non_stop_p): Return bool.
Change-Id: Icdb37ffe917798e59b822976794d4b1b7aafd709
Shahab Vahedi [Tue, 10 Dec 2019 15:25:08 +0000 (16:25 +0100)]
gdb: Use correct feature in tdesc-regs for ARC
tdesc-regs.exp test fails for ARC because the test is not
using the correct XML files as target description. With
this change, the correct directory and files are used.
v2 (after Andrew's remark [1]):
- Update the feature file names again. Test results now:
Test run by shahab on Tue Jan 26 11:31:16 2021
Target is arc-default-elf32
Host is x86_64-unknown-linux-gnu
=== gdb tests ===
Schedule of variations:
arc-nsim
Running target arc-nsim
Running /src/gdb/testsuite/gdb.xml/tdesc-regs.exp ...
PASS: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml
PASS: gdb.xml/tdesc-regs.exp: cd to directory holding xml
PASS: gdb.xml/tdesc-regs.exp: set tdesc filename test-extra-regs.xml...
PASS: gdb.xml/tdesc-regs.exp: ptype $extrareg
PASS: gdb.xml/tdesc-regs.exp: ptype $uintreg
PASS: gdb.xml/tdesc-regs.exp: ptype $vecreg
PASS: gdb.xml/tdesc-regs.exp: ptype $unionreg
PASS: gdb.xml/tdesc-regs.exp: ptype $unionreg.v4
PASS: gdb.xml/tdesc-regs.exp: ptype $structreg
PASS: gdb.xml/tdesc-regs.exp: ptype $structreg.v4
PASS: gdb.xml/tdesc-regs.exp: ptype $bitfields
PASS: gdb.xml/tdesc-regs.exp: ptype $flags
PASS: gdb.xml/tdesc-regs.exp: ptype $mixed_flags
PASS: gdb.xml/tdesc-regs.exp: maintenance print reggroups
PASS: gdb.xml/tdesc-regs.exp: core-only.xml: set tdesc filename...
PASS: gdb.xml/tdesc-regs.exp: core-only.xml: ptype $extrareg
=== gdb Summary ===
# of expected passes 16
[1]
https://sourceware.org/pipermail/gdb-patches/2021-January/175465.html
gdb/testsuite/ChangeLog:
* gdb.xml/tdesc-regs.exp: Use correct core-regs for ARC.
Simon Marchi [Thu, 4 Feb 2021 18:35:37 +0000 (13:35 -0500)]
gdb: make record-full clear async handler in wait
For the same reason explained in the previous patch (which was for the
record-btrace target), move clearing of the async event handler of the
record-full target to the wait method.
I'm not sure if/where that target needs to re-set its async event
handler in the wait method. Since it only supports a single thread,
there probably can't be multiple events to report at the same time.
gdb/ChangeLog:
* record-full.c (record_full_async_inferior_event_handler):
Don't clear async event handler.
(record_full_base_target::wait): Clear async event handler at
beginning.
Change-Id: I146fbdb53d99e3a32766ac7cd337ac5ed7fd9adf
Simon Marchi [Thu, 4 Feb 2021 18:35:09 +0000 (13:35 -0500)]
gdb: make record-btrace clear event handler in wait
For the same reason explained in the previous patch (which was for the
remote target), move clearing of the async event handler of the
record-btrace target to the wait method.
The record-btrace target already re-sets its async event handler in its
wait method, so that part doesn't need to be changed:
/* In async mode, we need to announce further events. */
if (target_is_async_p ())
record_btrace_maybe_mark_async_event (moving, no_history);
gdb/ChangeLog:
* record-btrace.c (record_btrace_handle_async_inferior_event):
Don't clear async event handler.
(record_btrace_target::wait): Clear async event handler at
beginning.
Change-Id: Ib32087a81bf94f1b884a938c8167ac8bbe09e362
Simon Marchi [Thu, 4 Feb 2021 18:34:11 +0000 (13:34 -0500)]
gdb: make remote target clear its handler in remote_target::wait
The remote target's remote_async_inferior_event_token is a flag that
tells when it wants the infrun loop to call its wait method. The flag
is cleared in the async_event_handler's callback
(remote_async_inferior_event_handler), just before calling
inferior_event_handler. However, since inferior_event_handler may
actually call another target's wait method, there needs to be code that
checks if we need to re-raise the flag.
It would be simpler instead for remote_target::wait to clear the flag
when it returns an event and there are no more to report after that. If
another target's wait method gets called by inferior_event_handler, the
remote target's flag will stay naturally stay marked.
Note that this is already partially implemented in remote_target::wait,
since the remote target may have multiple events to report (and it can
only report one at the time):
if (target_is_async_p ())
{
remote_state *rs = get_remote_state ();
/* If there are are events left in the queue tell the event loop
to return here. */
if (!rs->stop_reply_queue.empty ())
mark_async_event_handler (rs->remote_async_inferior_event_token);
}
The code in remote_async_inferior_event_handler also checks for pending
events as well, in addition to the stop reply queue, so I've made
remote_target::wait check for that as well. I'm not completely sure
this is ok, since I don't understand very well how the pending events
mechanism works. But I figured it was safer to do this, worst case it
just leads to unnecessary calls to remote_target::wait.
gdb/ChangeLog:
* remote.c (remote_target::wait): Clear async event handler at
beginning, mark if needed at the end.
(remote_async_inferior_event_handler): Don't set or clear async
event handler.
Change-Id: I20117f5b5acc8a9972c90f16280249b766c1bf37
Simon Marchi [Thu, 4 Feb 2021 18:13:30 +0000 (13:13 -0500)]
gdb: make async event handlers clear themselves
The `ready` flag of async event handlers is cleared by the async event
handler system right before invoking the associated callback, in
check_async_event_handlers.
This is not ideal with how the infrun subsystem consumes events: all
targets' async event handler callbacks essentially just invoke
`inferior_event_handler`, which eventually calls `fetch_inferior_event`
and `do_target_wait`. `do_target_wait` picks an inferior at random,
and thus a target at random (it could be the target whose `ready` flag
was cleared, or not), and pulls one event from it.
So it's possible that:
- the async event handler for a target A is called
- we end up consuming an event for target B
- all threads of target B are stopped, target_async(0) is called on it,
so its async event handler is cleared (e.g.
record_btrace_target::async)
As a result, target A still has events to report while its async event
handler is left unmarked, so these events are not consumed. To counter
this, at the end of their async event handler callbacks, targets check
if they still have something to report and re-mark their async event
handler (e.g. remote_async_inferior_event_handler).
The linux_nat target does not suffer from this because it doesn't use an
async event handler at the moment. It only uses a pipe registered with
the event loop. It is written to in the SIGCHLD handler (and in other
spots that want to get target wait method called) and read from in
the target's wait method. So if linux_nat happened to be target A in
the example above, the pipe would just stay readable, and the event loop
would wake up again, until linux_nat's wait method is finally called and
consumes the contents of the pipe.
I think it would be nicer if targets using async_event_handler worked in
a similar way, where the flag would stay set until the target's wait
method is actually called. As a first step towards that, this patch
moves the responsibility of clearing the ready flags of async event
handlers to the invoked callback.
All async event handler callbacks are modified to clear their ready flag
before doing anything else. So in practice, nothing changes with this
patch. It's only the responsibility of clearing the flag that is
shifted toward the callee.
gdb/ChangeLog:
* async-event.h (async_event_handler_func): Add documentation.
* async-event.c (check_async_event_handlers): Don't clear
async_event_handler ready flag.
* infrun.c (infrun_async_inferior_event_handler): Clear ready
flag.
* record-btrace.c (record_btrace_handle_async_inferior_event):
Likewise.
* record-full.c (record_full_async_inferior_event_handler):
Likewise.
* remote-notif.c (remote_async_get_pending_events_handler):
Likewise.
* remote.c (remote_async_inferior_event_handler): Likewise.
Change-Id: I179ef8e99580eae642d332846fd13664dbddc0c1
Nick Alcock [Fri, 29 Jan 2021 13:33:11 +0000 (13:33 +0000)]
libctf: always name nameless types "", never NULL
The ctf_type_name_raw and ctf_type_aname_raw functions, which return the
raw, unadorned name of CTF types, have one unfortunate wrinkle: they
return NULL not only on error but when returning the name of types
without a name in writable dicts. This was unintended: it not only
makes it impossible to reliably tell if a given call to
ctf_type_name_raw failed (due to a bad string offset say), but also
complicates all its callers, who now have to check for both NULL and "".
The written-out form of CTF has no concept of a NULL pointer instead of
a string: all null strings are strtab offset 0, "". So the more we can
do to remove this distinction from the writable form, the less complex
the rest of our code needs to be.
Armour against NULL in multiple places, arranging to return "" from
ctf_type_name_raw if offset 0 is passed in, and removing a risky
optimization from ctf_str_add* that avoided doing anything if a NULL was
passed in: this added needless irregularity to the functions' API
surface, since "" and NULL should be treated identically, and in the
case of ctf_str_add_ref, we shouldn't skip adding the passed-in REF to
the list of references to be updated no matter what the content of the
string happens to be.
This means we can simplify the deduplicator a tiny bit, also fixing a
bug (latent when used by ld) where if the input dict was writable,
we failed to realise when types were nameless and could end up creating
deeply unhelpful synthetic forwards with no name, which we just banned
a few commits ago, so the link failed.
libctf/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-string.c (ctf_str_add): Treat adding a NULL as adding "".
(ctf_str_add_ref): Likewise.
(ctf_str_add_external): Likewise.
* ctf-types.c (ctf_type_name_raw): Always return "" for offset 0.
* ctf-dedup.c (ctf_dedup_multiple_input_dicts): Don't armour
against NULL name.
(ctf_dedup_maybe_synthesize_forward): Likewise.
Nick Alcock [Thu, 28 Jan 2021 15:00:11 +0000 (15:00 +0000)]
libctf: fix uninitialized variable in symbol serialization error handling
We declare a variable to hold errors at two scopes, and then initialize
the inner one and jump to a scope where only the outer one is in scope.
The consequences are minor: only the version of the error message
printed in the debugging stream is impacted.
libctf/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-create.c (ctf_serialize): Fix shadowing.
Nick Alcock [Wed, 27 Jan 2021 19:55:45 +0000 (19:55 +0000)]
libctf: prohibit nameless ints, floats, typedefs and forwards
Now that "anonymous typedef nodes" have been extirpated, we can mandate
that things that have names in C must have names in CTF too. (Unlike
the no-forwards embarrassment, the deduplicator does nothing special
with names: types that have names in C will have the same name in CTF.
So we can assume that the CTF rules and the C rules are the same.)
include/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-api.h (ECTF_NONAME): New.
(ECTF_NERR): Adjust.
libctf/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-create.c (ctf_add_encoded): Add check for non-empty name.
(ctf_add_forward): Likewise.
(ctf_add_typedef): Likewise.
Nick Alcock [Wed, 27 Jan 2021 19:41:49 +0000 (19:41 +0000)]
libctf: rip out dead code handling typedefs with no name
There is special code in libctf to handle typedefs with no name, which
the code calls "anonymous typedef nodes".
These monsters are obviously not something C programs can include: the
whole point of a ttypedef is to introduce a new name. Looking back at
the history of DWARF in GCC, the only thing (outside C++ anonymous
namespaces) which can generate a DW_TAG_typedef without a DW_AT_name is
obsolete code to handle the long-removed -feliminate-dwarf2-dups option.
Looking at OpenSolaris, typedef nodes with no name couldn't be generated
by the DWARF->CTF converter at all (and its deduplicator barfed on
them): the only reason for the existence of this code is a special case
working around a peculiarity of stabs whereby types could sometimes be
referenced before they were introduced.
We don't need to carry code in libctf to handle special cases in an
obsolete OpenSolaris converter (that yields a format that isn't readable
by libctf anyway). So drop it.
libctf/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-open.c (init_types): Rip out code to check anonymous typedef
nodes.
* ctf-create.c (ctf_add_reftype): Likewise.
* ctf-lookup.c (refresh_pptrtab): Likewise.
Nick Alcock [Sat, 16 Jan 2021 16:49:29 +0000 (16:49 +0000)]
libctf, ld: fix symtypetab and var section population under ld -r
The variable section in a CTF dict is meant to contain the types of
variables that do not appear in the symbol table (mostly file-scope
static declarations). We implement this by having the compiler emit
all potential data symbols into both sections, then delete those
symbols from the variable section that correspond to data symbols the
linker has reported.
Unfortunately, the check for this in ctf_serialize is wrong: rather than
checking the set of linker-reported symbols, we check the set of names
in the data object symtypetab section: if the linker has reported no
symbols at all (usually if ld -r has been run, or if a non-linker
program that does not use symbol tables is calling ctf_link) this will
include every single symbol, emptying the variable section completely.
Worse, when ld -r is in use, we want to force writeout of every
symtypetab entry on the inputs, in an indexed section, whether or not
the linker has reported them, since this isn't a final link yet and the
symbol table is not finalized (and may grow more symbols than the linker
has yet reported). But the check for this is flawed too: we were
relying on ctf_link_shuffle_syms not having been called if no symbols
exist, but that function is *always* called by ld even when ld -r is in
use: ctf_link_add_linker_symbol is the one that's not called when there
are no symbols.
We clearly need to rethink this. Using the emptiness of the set of
reported symbols as a test for ld -r is just ugly: the linker already
knows if ld -r is underway and can just tell us. So add a new linker
flag CTF_LINK_NO_FILTER_REPORTED_SYMS that is set to stop the linker
filtering the symbols in the symtypetab sections using the set that the
linker has reported: use the presence or absence of this flag to
determine whether to emit unindexed symtabs: we only remove entries from
the variable section when filtering symbols, and we only remove them if
they are in the reported symbol set, fixing the case where no symbols
are reported by the linker at all.
(The negative sense of the new CTF_LINK flag is intentional: the common
case, both for ld and for simple tools that want to do a ctf_link with
no ELF symbol table in sight, is probably to filter out symbols that no
linker has reported: i.e., for the simple tools, all of them.)
There's another wrinkle, though. It is quite possible for a non-linker
to add symbols to a dict via ctf_add_*_sym and then write it out via the
ctf_write APIs: perhaps it's preparing a dict for a later linker
invocation. Right now this would not lead to anything terribly
meaningful happening: ctf_serialize just assumes it was called via
ctf_link if symbols are present. So add an (internal-to-libctf) flag
that indicates that a writeout is happening via ctf_link_write, and set
it there (propagating it to child dicts as needed). ctf_serialize can
then spot when it is not being called by a linker, and arrange to always
write out an indexed, sorted symtypetab for fastest possible future
symbol lookup by name in that case. (The writeouts done by ld -r are
unsorted, because the only thing likely to use those symtabs is the
linker, which doesn't benefit from symtypetab sorting.)
Tests added for all three linking cases (ld -r, ld -shared, ld), with a
bit of testsuite framework enhancement to stop it unconditionally
linking the CTF to be checked by the lookup program with -shared, so
tests can now examine CTF linked with -r or indeed with no flags at all,
though the output filename is still foo.so even in this case.
Another test added for the non-linker case that endeavours to determine
whether the symtypetab is sorted by examining the order of entries
returned from ctf_symbol_next: nobody outside libctf should rely on
this ordering, but this test is not outside libctf :)
include/ChangeLog
2021-01-26 Nick Alcock <nick.alcock@oracle.com>
* ctf-api.h (CTF_LINK_NO_FILTER_REPORTED_SYMS): New.
ld/ChangeLog
2021-01-26 Nick Alcock <nick.alcock@oracle.com>
* ldlang.c (lang_merge_ctf): Set CTF_LINK_NO_FILTER_REPORTED_SYMS
when appropriate.
libctf/ChangeLog
2021-01-27 Nick Alcock <nick.alcock@oracle.com>
* ctf-impl.c (_libctf_nonnull_): Add parameters.
(LCTF_LINKING): New flag.
(ctf_dict_t) <ctf_link_flags>: Mention it.
* ctf-link.c (ctf_link): Keep LCTF_LINKING set across call.
(ctf_write): Likewise, including in child dictionaries.
(ctf_link_shuffle_syms): Make sure ctf_dynsyms is NULL if there
are no reported symbols.
* ctf-create.c (symtypetab_delete_nonstatic_vars): Make sure
the variable has been reported as a symbol by the linker.
(symtypetab_skippable): Mention relationship between SYMFP and the
flags.
(symtypetab_density): Adjust nonnullity. Exit early if no symbols
were reported and force-indexing is off (i.e., we are doing a
final link).
(ctf_serialize): Handle the !LCTF_LINKING case by writing out an
indexed, sorted symtypetab (and allow SYMFP to be NULL in this
case). Turn sorting off if this is a non-final link. Only delete
nonstatic vars if we are filtering symbols and the linker has
reported some.
* testsuite/libctf-regression/nonstatic-var-section-ld-r*:
New test of variable and symtypetab section population when
ld -r is used.
* testsuite/libctf-regression/nonstatic-var-section-ld-executable.lk:
Likewise, when ld of an executable is used.
* testsuite/libctf-regression/nonstatic-var-section-ld.lk:
Likewise, when ld -shared alone is used.
* testsuite/libctf-regression/nonstatic-var-section-ld*.c:
Lookup programs for the above.
* testsuite/libctf-writable/symtypetab-nonlinker-writeout.*: New
test, testing survival of symbols across ctf_write paths.
* testsuite/lib/ctf-lib.exp (run_lookup_test): New option,
nonshared, suppressing linking of the SOURCE with -shared.
H.J. Lu [Thu, 4 Feb 2021 14:02:13 +0000 (06:02 -0800)]
x86-64: Provide more info when failed to convert GOTPCREL
Provide
[hjl@gnu-cfl-2 ld]$ ./ld-new -z norelro -L/export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-x86-64 -melf32_x86_64 -Ttext=0x80000000 -o tmpdir/dump tmpdir/pr19609-7.o
tmpdir/pr19609-7.o: in function `_start':
(.text+0x2): failed to convert GOTPCREL relocation against 'foobar'; relink with --no-relax
[hjl@gnu-cfl-2 ld]$
instead of
[hjl@gnu-cfl-2 ld]$ ld -z norelro -L/export/gnu/import/git/gitlab/x86-binutils/ld/testsuite/ld-x86-64 -melf32_x86_64 -Ttext=0x80000000 -o tmpdir/dump tmpdir/pr19609-7.o
ld: failed to convert GOTPCREL relocation; relink with --no-relax
[hjl@gnu-cfl-2 ld]$
bfd/
PR ld/19609
* elf64-x86-64.c (elf_x86_64_relocate_section): Provide more
info when failed to convert GOTPCREL relocation.
ld/
PR ld/19609
* testsuite/ld-x86-64/pr19609-2a.d: Updated.
* testsuite/ld-x86-64/pr19609-2b.d: Likewise.
* testsuite/ld-x86-64/pr19609-4a.d: Likewise.
* testsuite/ld-x86-64/pr19609-4c.d: Likewise.
* testsuite/ld-x86-64/pr19609-5d.d: Likewise.
* testsuite/ld-x86-64/pr19609-7a.d: Likewise.
* testsuite/ld-x86-64/pr19609-7c.d: Likewise.
H.J. Lu [Thu, 4 Feb 2021 13:11:37 +0000 (05:11 -0800)]
ld: Restore PR ld/15146 tests
commit
7d409ac001cce916661d345bff01ed589991e762
Author: Alan Modra <amodra@gmail.com>
Date: Thu Feb 4 13:56:34 2021 +1030
PR27311, (symbol from plugin): undefined reference, hidden sym
fixed PR ld/15146. Restore PR ld/15146 tests.
PR ld/15146
* testsuite/ld-plugin/lto.exp: Run PR ld/15146 tests.
* testsuite/ld-plugin/pr15146.d: Restored.
* testsuite/ld-plugin/pr15146a.c: Likewise.
* testsuite/ld-plugin/pr15146b.c: Likewise.
* testsuite/ld-plugin/pr15146c.c: Likewise.
* testsuite/ld-plugin/pr15146d.c: Likewise.
Nelson Chu [Thu, 4 Feb 2021 08:15:03 +0000 (16:15 +0800)]
RISC-V: Removed the v0.93 bitmanip ZBA/ZBB/ZBC instructions.
bfd/
* elfxx-riscv.c (riscv_parse_prefixed_ext): Removed zb*.
gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Removed
INSN_CLASS_ZB*.
* testsuite/gas/riscv/bitmanip-insns-32.d: Removed.
* testsuite/gas/riscv/bitmanip-insns-64.d: Removed.
* testsuite/gas/riscv/bitmanip-insns.s: Removed.
include/
* opcode/riscv-opc.h: Removed macros for zb* extensions.
* opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_ZB*.
opcodes/
* riscv-opc.c (MASK_RVB_IMM): Removed.
(riscv_opcodes): Removed zb* instructions.
(riscv_ext_version_table): Removed versions for zb*.
Alan Modra [Thu, 4 Feb 2021 03:26:34 +0000 (13:56 +1030)]
PR27311, (symbol from plugin): undefined reference, hidden sym
bfd/
PR 27311
* elflink.c (elf_link_add_object_symbols): Don't pull in as-needed
libraries for IR references on pass over libraries after LTO
recompilation.
ld/
* testsuite/ld-plugin/pr27311d.c: New test.
* testsuite/ld-plugin/lto.exp: Rename pr27311 to pr27311-1, compile
and link new test as pr27311-2.
GDB Administrator [Thu, 4 Feb 2021 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Wed, 3 Feb 2021 19:36:54 +0000 (14:36 -0500)]
gdb: infrun: move stop_soon variable to inner scoped in handle_inferior_event
Moving it to an inner scope makes it clearer where it's used (only while
handling the TARGET_WAITKIND_LOADED event).
gdb/ChangeLog:
* infrun.c (handle_inferior_event): Move stop_soon variable to
inner scope.
Change-Id: Ic57685a21714cfbb38f1487ee96cea1d12b44652
Andreas Krebbel [Wed, 3 Feb 2021 11:01:12 +0000 (12:01 +0100)]
IBM Z: Add missing vector formats to .insn docs
gas/
* doc/c-s390.texi: Document vector instruction formats.
Alan Modra [Wed, 3 Feb 2021 05:27:35 +0000 (15:57 +1030)]
Re: PR27311, ld.bfd (symbol from plugin): undefined reference
This does exactly the same as making decisions based on an override
in _bfd_elf_add_default_symbol, and is simpler.
PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Revert last two changes.
(elf_link_add_object_symbols): Here too. Don't pull in as-needed
libraries when H is an indirect symbol after calling
_bfd_elf_add_default_symbol.
Alan Modra [Sun, 31 Jan 2021 15:34:41 +0000 (02:04 +1030)]
pr27270 and pr27284, ar segfaults and wrong file mode
PR 27270
PR 27284
PR 26945
* ar.c: Don't include libbfd.h.
(write_archive): Replace xmalloc+strcpy with xstrdup. Use
bfd_stat rather than fstat on iostream. Move stat and fd tests
outside of _WIN32 ifdef. Delete skip_stat variable.
* arsup.c (temp_name, real_ofd): New static variables.
(ar_open): Use make_tempname and bfd_fdopenw.
(ar_save): Adjust to suit ar_open changes. Move stat output
of _WIN32 ifdef.
* objcopy.c: Don't include libbfd.h.
(copy_file): Use bfd_stat.
projects / binutils-gdb.git / log