| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
binutils/
* objcopy.c (compare_gnu_build_notes): Fix comparison results
for overlapping ranges so that (A == B) == (B == A) holds.
|
|
After commit 999d6dff80f cpu-plugin.c is no longer begin used.
* Makefile.am (ALL_MACHINES): Remove cpu-plugin.lo.
(ALL_MACHINES_CFILES): Remove cpu-plugin.c.
* Makefile.in: Regenerate.
* cpu-plugin.c: Remove.
* archures.c (enum bfd_architecture): Remove bfd_arch_plugin.
(bfd_plugin_arch): Remove declaration.
* bfd-in2.h: Regenerate.
* po/SRC-POTFILES.in: Regenerate.
|
|
movsxd is a 64-bit only instruction. It supports both 16-bit and 32-bit
destination registers. Its AT&T mnemonic is movslq which only supports
64-bit destination register. There is also a discrepancy between AMD64
and Intel64 on movsxd with 16-bit destination register. AMD64 supports
32-bit source operand and Intel64 supports 16-bit source operand.
This patch updates movsxd encoding and decoding to alow 16-bit and 32-bit
destination registers. It also handles movsxd with 16-bit destination
register for AMD64 and Intel 64.
gas/
PR binutils/25445
* config/tc-i386.c (check_long_reg): Also convert to QWORD for
movsxd.
* doc/c-i386.texi: Add a node for AMD64 vs. Intel64 ISA
differences. Document movslq and movsxd.
* testsuite/gas/i386/i386.exp: Run PR binutils/25445 tests.
* testsuite/gas/i386/x86-64-movsxd-intel.d: New file.
* testsuite/gas/i386/x86-64-movsxd-intel64-intel.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64-inval.l: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64-inval.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd-intel64.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd-inval.l: Likewise.
* testsuite/gas/i386/x86-64-movsxd-inval.s: Likewise.
* testsuite/gas/i386/x86-64-movsxd.d: Likewise.
* testsuite/gas/i386/x86-64-movsxd.s: Likewise.
opcodes/
PR binutils/25445
* i386-dis.c (MOVSXD_Fixup): New function.
(movsxd_mode): New enum.
(x86_64_table): Use MOVSXD_Fixup and movsxd_mode on movsxd.
(intel_operand_size): Handle movsxd_mode.
(OP_E_register): Likewise.
(OP_G): Likewise.
* i386-opc.tbl: Remove Rex64 and allow 32-bit destination
register on movsxd. Add movsxd with 16-bit destination register
for AMD64 and Intel64 ISAs.
* i386-tbl.h: Regenerated.
|
|
binutils/
* testsuite/lib/binutils-common.exp (big_or_little_endian): Replace
case statement with switch statement.
gas/
* testsuite/gas/all/gas.exp: Replace case statements with switch
statements.
* testsuite/gas/elf/elf.exp: Likewise.
* testsuite/gas/macros/macros.exp: Likewise.
* testsuite/lib/gas-defs.exp: Likewise.
ld/
* testsuite/ld-elfvers/vers.exp: Replace case statements with
switch statements.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.
|
|
This fixes the preferred disassembly for cfinv. The Armv8.4-a instruction
overlaps with the possible encoding space for msr. This because msr allows you
to use unallocated encoding space using the general sA_B_cC_cD_E form.
However when an encoding does become allocated then we need to ensure that it's
used as the preferred disassembly. The problem with cfinv is that its mask has
all bits sets because it has no arguments.
This causes issues for the Alias resolver in gas as it uses the mask to build
alias graph. In this case it can't do it since it thinks almost everything
would alias with cfinv. So instead we can only fix this by moving cfinv before
msr.
gas/ChangeLog:
PR 25403
* testsuite/gas/aarch64/armv8_4-a.d: Add cfinv.
* testsuite/gas/aarch64/armv8_4-a.s: Likewise.
opcodes/ChangeLog:
PR 25403
* aarch64-tbl.h (struct aarch64_opcode): Re-order cfinv.
* aarch64-asm-2.c: Regenerate
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.
|
|
I noticed a couple of minor issues in ctfread.c, both fixed by this
patch:
* ctf_fp_info was not indented properly; and
* _initialize_ctfread is no longer needed
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* ctfread.c (struct ctf_fp_info): Reindent.
(_initialize_ctfread): Remove.
Change-Id: I72707b74bc59e6e426b3a7bc8843d96c0d786f1e
|
|
bfd/
PR ld/25458
* elflink.c (_bfd_elf_gc_mark_rsec): Mark all weak aliases.
ld/
PR ld/25458
* testsuite/ld-elf/pr25458.map: New file.
* testsuite/ld-elf/pr25458.rd: Likewise.
* testsuite/ld-elf/pr25458a.s: Likewise.
* testsuite/ld-elf/pr25458b.s: Likewise.
* testsuite/ld-elf/shared.exp: Run PR ld/25458 test.
|
|
|
|
This patch removes the "readin" and "compunit_symtab" members from
partial_symtab, replacing them with methods. Then it introduces a new
"standard_psymtab" class, which restores these members; and changes
the symbol readers to use this intermediate class as the base class of
their partial symtab subclasses.
The reason for this is to make it possible for a symbol reader to
implement an alternate mapping between partial and full symbol tables.
This is important in order to be able to share psymtabs across
objfiles -- whether a psymtab has been "readin" is objfile-dependent,
as are the pointers to the full symbol tables.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* psymtab.c (partial_map_expand_apply)
(psym_find_pc_sect_compunit_symtab, psym_lookup_symbol)
(psymtab_to_symtab, psym_find_last_source_symtab, dump_psymtab)
(psym_print_stats, psym_expand_symtabs_for_function)
(psym_map_symbol_filenames, psym_map_matching_symbols)
(psym_expand_symtabs_matching)
(partial_symtab::read_dependencies, maintenance_info_psymtabs)
(maintenance_check_psymtabs): Use new methods.
* psympriv.h (struct partial_symtab) <readin_p,
get_compunit_symtab>: New methods.
<readin, compunit_symtab>: Remove members.
(struct standard_psymtab): New.
(struct legacy_psymtab): Derive from standard_psymtab.
* dwarf2read.h (struct dwarf2_psymtab): Derive from
standard_psymtab.
* ctfread.c (struct ctf_psymtab): Derive from standard_psymtab.
Change-Id: Idb923f196d7e03bf7cb9cfc8134ed06dd3f211ce
|
|
Most of the symbol readers have code to iterate over a partial symtabs
dependencies, expanding each one and optionally printing a message.
Now that the "second-stage" psymtab expansion is available as a
method, these implementations can all be merged.
This patch also changes a couple more warnings into assertions.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_psymtab_to_symtab_1): Call
read_dependencies. Add assert.
* psymtab.c (partial_symtab::read_dependencies): New method.
* psympriv.h (struct partial_symtab) <read_dependencies>: New
method.
* mdebugread.c (psymtab_to_symtab_1): Call read_dependencies.
* dwarf2read.c (dwarf2_psymtab::expand_psymtab): Call
read_dependencies.
* dbxread.c (dbx_psymtab_to_symtab_1): Call read_dependencies.
Add assert.
Change-Id: I8151e05677794e90223edc1a4cb70f7f69137d46
|
|
The symbol readers generally used two functions to expand a partial
symtab: an outer function (now the "read_symtab" method), and an inner
function, typically named something like "psymtab_to_symtab".
This patch changes this second step to be a method on partial_symtab,
and updates all the callers. For legacy_psymtab, a new function
pointer member is introduced.
This patch enables a subsequent cleanup.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_psymtab_to_symtab_1): Change argument order.
Call expand_psymtab.
(xcoff_read_symtab): Call expand_psymtab.
(xcoff_start_psymtab, xcoff_end_psymtab): Set
legacy_expand_psymtab.
* psympriv.h (struct partial_symtab) <expand_psymtab>: New
method.
(struct legacy_psymtab) <expand_psymtab>: Implement.
<legacy_expand_psymtab>: New member.
* mdebugread.c (mdebug_read_symtab): Call expand_psymtab.
(parse_partial_symbols): Set legacy_expand_psymtab.
(psymtab_to_symtab_1): Change argument order. Call
expand_psymtab.
(new_psymtab): Set legacy_expand_psymtab.
* dwarf2read.h (struct dwarf2_psymtab) <expand_psymtab>: Declare.
* dwarf2read.c (dwarf2_psymtab::read_symtab): Call
expand_psymtab.
(dwarf2_psymtab::expand_psymtab): Rename from
psymtab_to_symtab_1. Call expand_psymtab.
* dbxread.c (start_psymtab): Set legacy_expand_psymtab.
(dbx_end_psymtab): Likewise.
(dbx_psymtab_to_symtab_1): Change argument order. Call
expand_psymtab.
(dbx_read_symtab): Call expand_psymtab.
* ctfread.c (struct ctf_psymtab) <expand_psymtab>: Declare.
(ctf_psymtab::expand_psymtab): Rename from psymtab_to_symtab.
(ctf_psymtab::read_symtab): Call expand_psymtab.
Change-Id: Ic39a2d7aa7b424088d910b59dbd21271fa1c3430
|
|
Each symbol reader implemented its own "Reading..." messages, and most
of them double-checked that a previously-expanded psymtab could not be
re-read.
This patch consolidates the message-printing, and changes these checks
into asserts.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_read_symtab): Remove prints. Add assert.
* psymtab.c (psymtab_to_symtab): Print verbose "Reading"
messages.
* mdebugread.c (mdebug_read_symtab): Remove prints.
* dwarf2read.c (dwarf2_psymtab::read_symtab): Remove prints. Add
assert.
* dbxread.c (dbx_read_symtab): Remove prints. Add assert.
Change-Id: I795be9710d42708299bb7b44972cffd27aec9413
|
|
This introduces a new partial_symtab::read_symtab method, and updates
the symbol readers to subclass partial_symtab and implement this
method. The old read_symtab and read_symtab_private members are
removed.
In practice, only DWARF and CTF are truly updated to take advantage of
the new setup. The other symbol readers are less actively maintained,
and so this patch also introduces a "legacy_psymtab", which
essentially works the same way as the old partial_symtab.
(Note that, without more knowledge of the interaction between these
symbol readers, fixing this to remove the new (small) overhead is not
trivial, because these readers copy the read_symtab pointer between
partial symtabs.)
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (this_symtab_psymtab, read_xcoff_symtab)
(xcoff_psymtab_to_symtab_1, xcoff_read_symtab)
(xcoff_start_psymtab, xcoff_end_psymtab, scan_xcoff_symtab): Use
legacy_symtab.
* stabsread.h (dbx_end_psymtab): Use legacy_symtab.
* psymtab.c (psymtab_to_symtab): Call method.
(dump_psymtab): Update.
* psympriv.h (struct partial_symtab): Add virtual destructor.
<read_symtab>: New method.
(struct legacy_symtab): New.
* mdebugread.c (mdebug_read_symtab): Use legacy_psymtab.
(struct pst_map) <pst>: Now a legacy_psymtab.
(parse_procedure, parse_partial_symbols, psymtab_to_symtab_1)
(new_psymtab): Use legacy_psymtab.
* dwarf2read.h (struct dwarf2_psymtab): New.
(struct dwarf2_per_cu_data) <psymtab>: Use it.
* dwarf2read.c (dwarf2_create_include_psymtab)
(dwarf2_build_include_psymtabs, create_type_unit_group)
(create_partial_symtab, process_psymtab_comp_unit_reader)
(build_type_psymtabs_reader, build_type_psymtab_dependencies)
(set_partial_user): Use dwarf2_psymtab.
(dwarf2_psymtab::read_symtab): Rename from dwarf2_read_symtab.
(psymtab_to_symtab_1, process_full_comp_unit)
(process_full_type_unit, dwarf2_ranges_read)
(dwarf2_get_pc_bounds, psymtab_include_file_name)
(dwarf_decode_lines): Use dwarf2_psymtab.
* dwarf-index-write.c (psym_index_map): Use dwarf2_psymtab.
(add_address_entry_worker, write_one_signatured_type)
(recursively_count_psymbols, recursively_write_psymbols)
(write_one_signatured_type, psyms_seen_size, write_gdbindex)
(write_debug_names): Likewise.
* dbxread.c (struct header_file_location): Take a legacy_psymtab.
<pst>: Now a legacy_psymtab.
(find_corresponding_bincl_psymtab): Return a legacy_psymtab.
(read_dbx_symtab, start_psymtab, dbx_end_psymtab)
(dbx_psymtab_to_symtab_1, read_ofile_symtab): Use legacy_psymtab.
* ctfread.c (struct ctf_psymtab): New.
(ctf_start_symtab, ctf_end_symtab, psymtab_to_symtab): Take a
ctf_psymtab.
(ctf_psymtab::read_symtab): Rename from ctf_read_symtab.
(create_partial_symtab): Return a ctf_psymtab.
(scan_partial_symbols): Update.
Change-Id: Ia57a828786867d6ad03200af8f996f48ed15285e
|
|
This turns start_psymtab_common into a constructor, and then changes
the callers to use "new" directly. This completes the psymtab
allocation transition -- now it is possible for symbol readers to
subclass struct partial_symtab.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_start_psymtab): Use new.
* psymtab.c (partial_symtab::partial_symtab): New constructor,
renamed from start_psymtab_common.
* psympriv.h (struct partial_symtab): Add new constructor.
(start_psymtab_common): Don't declare.
* mdebugread.c (parse_partial_symbols): Use new.
* dwarf2read.c (create_partial_symtab): Use new.
* dbxread.c (start_psymtab): Use new.
* ctfread.c (create_partial_symtab): Use new.
Change-Id: I5a0217bcb52bcfa442559771954bb66bd9ccbf02
|
|
This is the next step in getting the symbol readers to allocate
psymtabs themselves: change allocate_psymtab to be an ordinary
constructor, and then use "new" at the previous call sites. Note that
this doesn't get us all the way -- start_psymtab_common is still
allocating a partial symtab.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Use new.
* psymtab.c (start_psymtab_common): Use new.
(partial_symtab::partial_symtab): Rename from allocate_psymtab.
Update.
* psympriv.h (struct partial_symtab): Add parameters to
constructor. Don't inline.
(allocate_psymtab): Don't declare.
* mdebugread.c (new_psymtab): Use new.
* dwarf2read.c (dwarf2_create_include_psymtab): Use new.
* dbxread.c (dbx_end_psymtab): Use new.
Change-Id: Iffeae64c925050b90b9916cbc36e15b26ff42226
|
|
Currently, partial symbol tables are allocated by a method in
psymtab_storage. However, eventually we want to subclass partial
symtabs in the symbol readers, so the calls to "new" will have to
happen there. This patch is a first step, moving the allocation from
psymtab_storage and into allocate_psymtab.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* psymtab.h (class psymtab_storage) <install_psymtab>: Rename from
allocate_psymtab. Update documentation.
* psymtab.c (psymtab_storage::install_psymtab): Rename from
allocate_psymtab. Do not use new.
(allocate_psymtab): Use new. Update.
Change-Id: Iba6a9bf3ee1e78062fdb9f007c3010f826f64bc8
|
|
This changes a few fields in partial_symtab to have type bool.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_psymtab_to_symtab_1): Update.
* psymtab.c (psym_print_stats): Update.
* psympriv.h (struct partial_symtab) <readin,
psymtabs_addrmap_supported, anonymous>: Now bool.
* mdebugread.c (psymtab_to_symtab_1): Update.
* dwarf2read.c (create_type_unit_group, create_partial_symtab)
(build_type_psymtabs_reader, psymtab_to_symtab_1)
(process_full_comp_unit, process_full_type_unit): Update.
* dbxread.c (dbx_psymtab_to_symtab_1): Update.
* ctfread.c (psymtab_to_symtab): Update.
Change-Id: I206761d083493589049ea0bc785ed6542339234d
|
|
This changes psymtabs to be allocated with new and destroyed with
delete. As a consequence, the psymtab free-list is also removed.
The motivation for this is to let symbol readers subclass
partial_symtab.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* mdebugread.c (parse_partial_symbols): Use discard_psymtab.
* psymtab.h (class psymtab_storage) <free_psymtabs>: Remove.
* psymtab.c (psymtab_storage): Delete psymtabs.
(psymtab_storage::allocate_psymtab): Use new.
(psymtab_storage::discard_psymtab): Use delete.
* psympriv.h (struct partial_symtab): Add constructor and
initializers.
Change-Id: I4e78ac538fc0ea52b57489c1afb8f935a30941ef
|
|
machoread.c does not need to include psympriv.h.
gdb/ChangeLog
2020-01-26 Tom Tromey <tom@tromey.com>
* machoread.c: Do not include psympriv.h.
Change-Id: I6362bd2e95e7416cb9bae3d48b69dd6dbe4f2cc8
|
|
From what I can tell, The m68k floating point target feature should
apparently always be called "org.gnu.gdb.coldfire.fp" -- even when the
primary feature is not "coldfire", because m68k_gdbarch_init only
checks for this feature when assigning register numbers.
However, the floating point registers are expected to match what gdb
thinks are the register sizes for the primary feature. For example,
if the main feature is "coldfire", then the floating point registers
should be 64 bits.
See this note for some an instance of this confusion:
https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg04564.html
This patch documents the oddity.
Let me know what you think. An alternate approach here might be to
make gdb adapt to the register sizes as actually reported. I'm not
sure if this makes sense or not.
gdb/doc/ChangeLog
2020-01-26 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (M68K Features): Document floating-point feature
correspondence.
Change-Id: I4cd86acbe3449a29ce38327524c508c206b25b8f
|
|
|
|
Mention in NEWS the new option and the set/show commands.
Document in gdb.texinfo the new option and the set/show commands.
gdb/ChangeLog
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Mention the new option and the set/show commands.
gdb/doc/ChangeLog
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Attach): Document the new option and the
set/show commands.
(Connecting): Reference the exec-file-mismatch option.
|
|
Modify gdb.base/attach.exp to test the behaviour of the option
exec-file-mismatch. Note that this test can also be run using/
make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" TESTS=gdb.base/attach.exp
to test the behaviour of attaching to running program using a gdb server.
Note: when running the test with a gdbserver, the tests in
test_command_line_attach_run fail because the command "run" is not supported.
I tried to extend the condition
if ![isnative] then {
unsupported "commandline attach run test"
return 0
}
but unclear to me how to best do that. The below trials all failed
to work properly:
if { ![isnative] || [target_is_gdbserver] } then {
if { ![isnative] || [use_gdb_stub] } then {
if { ![isnative] || [is_remote target] } then {
=> could never obtain a condition that was true with gdbserver.
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/attach.exp: Test 'set exec-file-mismatch'.
|
|
This option allows to tell GDB to detect and possibly handle mismatched exec-files.
A recurrent problem with GDB is that GDB uses the wrong exec-file
when using the attach/detach commands successively.
Also, in case the user specifies a file on the command line but attaches
to the wrong PID, this error is not made visible and gives a not user
understandable behaviour.
For example:
$ gdb
...
(gdb) atta 2682 ############################################ PID running 'sleepers' executable
Attaching to process 2682
[New LWP 2683]
[New LWP 2684]
[New LWP 2685]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) det
Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
[Inferior 1 (process 2682) detached]
(gdb) atta 31069 ############################################ PID running 'gdb' executable
Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
0x00007f43c23478a0 in ?? ()
(gdb) bt
#0 0x00007f43c23478a0 in ?? ()
#1 0x0000558909e3ad91 in ?? ()
#2 0x0000202962646700 in ?? ()
#3 0x00007ffc69c74e70 in ?? ()
#4 0x000055890c1d2350 in ?? ()
#5 0x0000000000000000 in ?? ()
(gdb)
The second attach has kept the executable of the first attach.
(in this case, 31069 is the PID of a GDB, that has nothing to do
with the first determined 'sleepers' executable).
Similarly, if specifying an executable, but attaching to a wrong pid,
we get:
gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
...
Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
(gdb) atta 31069 ############################################ PID running 'gdb' executable
Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
0x00007f43c23478a0 in ?? ()
(gdb) bt
#0 0x00007f43c23478a0 in ?? ()
#1 0x0000558909e3ad91 in ?? ()
#2 0x0000202962646700 in ?? ()
#3 0x00007ffc69c74e70 in ?? ()
#4 0x000055890c1d2350 in ?? ()
#5 0x0000000000000000 in ?? ()
(gdb)
And it is unclear to the user what has happened/what is going wrong.
This patch series implements a new option:
(gdb) apropos exec-file-mismatch
set exec-file-mismatch -- Set exec-file-mismatch handling (ask|warn|off).
show exec-file-mismatch -- Show exec-file-mismatch handling (ask|warn|off).
(gdb) help set exec-file-mismatch
Set exec-file-mismatch handling (ask|warn|off).
Specifies how to handle a mismatch between the current exec-file name
loaded by GDB and the exec-file name automatically determined when attaching
to a process:
ask - warn the user and ask whether to load the determined exec-file.
warn - warn the user, but do not change the exec-file.
off - do not check for mismatch.
"ask" means: in case of mismatch between the current exec-file name
and the automatically determined exec-file name of the PID we are attaching to,
give a warning to the user and ask whether to load the automatically determined
exec-file.
"warn" means: in case of mismatch, just give a warning to the user.
"off" means: do not check for mismatch.
This fixes PR gdb/17626.
There was a previous trial to fix this PR.
See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html
This trial was however only fixing the problem for the automatically
determined executable files when doing attach.
It was differentiating the 'user specified executable files' ("sticky")
from the executable files automatically found by GDB.
But such user specified sticky executables are in most cases due
to a wrong manipulation by the user, giving unexpected results
such as backtrace showing no function like in the above example.
This patch ensures that whenever a process executable can be
determined, that the user is warned if there is a mismatch.
The same tests as above then give:
(gdb) atta 2682
Attaching to process 2682
[New LWP 2683]
[New LWP 2684]
[New LWP 2685]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f5ff829f603 in select () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) det
Detaching from program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 2682
[Inferior 1 (process 2682) detached]
(gdb) atta 31069
Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
Setting up the environment for debugging gdb.
...
Reading symbols from /usr/lib/debug/.build-id/60/6df9c355103e82140d513bc7a25a635591c153.debug...
0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
(top-gdb) bt
During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f43c23478ad
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'
During symbol reading: cannot get low and high bounds for subprogram DIE at 0x12282a7
During symbol reading: Child DIE 0x12288ba and its abstract origin 0x1228b26 have different parents
During symbol reading: DW_AT_call_target target DIE has invalid low pc, for referencing DIE 0x1229540 [in module /bd/home/philippe/gdb/git/build_fixes/gdb/gdb]
#0 0x00007f43c23478a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1 0x0000558909e3ad91 in poll (__timeout=-1, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 gdb_wait_for_event (block=block@entry=1) at ../../fixes/gdb/event-loop.c:772
#3 0x0000558909e3aef4 in gdb_do_one_event () at ../../fixes/gdb/event-loop.c:347
#4 0x0000558909e3b085 in gdb_do_one_event () at ../../fixes/gdb/common/common-exceptions.h:219
#5 start_event_loop () at ../../fixes/gdb/event-loop.c:371
During symbol reading: Member function "~_Sp_counted_base" (offset 0x1c69bf7) is virtual but the vtable offset is not specified
During symbol reading: Multiple children of DIE 0x1c8f5a0 refer to DIE 0x1c8f0ee as their abstract origin
#6 0x0000558909ed3b78 in captured_command_loop () at ../../fixes/gdb/main.c:331
#7 0x0000558909ed4b6d in captured_main (data=<optimized out>) at ../../fixes/gdb/main.c:1174
#8 gdb_main (args=<optimized out>) at ../../fixes/gdb/main.c:1190
#9 0x0000558909c1e9a8 in main (argc=<optimized out>, argv=<optimized out>) at ../../fixes/gdb/gdb.c:32
(top-gdb)
gdb /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
...
Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers...
(gdb) atta 31069
Attaching to program: /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers, process 31069
warning: Mismatch between current exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers
and automatically determined exec-file /bd/home/philippe/gdb/git/build_fixes/gdb/gdb
exec-file-mismatch handling is currently "ask"
Load new symbol table from "/bd/home/philippe/gdb/git/build_fixes/gdb/gdb"? (y or n) y
Reading symbols from /bd/home/philippe/gdb/git/build_fixes/gdb/gdb...
Setting up the environment for debugging gdb.
....
In other words, it now works as intuitively expected by the user.
If ever the user gave the correct executable on the command line,
then attached to the wrong pid, then confirmed loading the wrong executable,
the user can simply fix this by detaching, and attaching to the correct pid,
GDB will then tell again to the user that the exec-file might better
be loaded.
The default value of "ask" is chosen instead of e.g. "warn" as in most
cases, switching of executable will be the correct action,
and in any case, the user can decide to not load the executable,
as GDB asks a confirmation to the user to load the new executable.
For settings "ask" and "warn", the new function validate_exec_file ()
tries to get the inferior pid exec file and compares it with the current
exec file. In case of mismatch, it warns the user and optionally load
the executable.
This function is called in the attach_command implementation to cover
most cases of attaching to a running process.
It must also be called in remote.c, as the attach command is not supported
for all types of remote gdbserver.
gdb/ChangeLog
2020-01-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* exec.c (exec_file_mismatch_names, exec_file_mismatch_mode)
(show_exec_file_mismatch_command, set_exec_file_mismatch_command)
(validate_exec_file): New variables, enums, functions.
(exec_file_locate_attach, print_section_info): Style the filenames.
(_initialize_exec): Install show_exec_file_mismatch_command and
set_exec_file_mismatch_command.
* gdbcore.h (validate_exec_file): Declare.
* infcmd.c (attach_command): Call validate_exec_file.
* remote.c ( remote_target::remote_add_inferior): Likewise.
|
|
|
|
This commit improves GDB's handling of inline functions when there are
more than one inline function in a stack, so for example if we have a
stack like:
main -> aaa -> bbb -> ccc -> ddd
And aaa, bbb, and ccc are all inline within main GDB should (when
given sufficient debug information) be able to step from main through
aaa, bbb, and ccc. Unfortunately, this currently doesn't work, here's
an example session:
(gdb) start
Temporary breakpoint 1 at 0x4003b0: file test.c, line 38.
Starting program: /project/gdb/tests/inline/test
Temporary breakpoint 1, main () at test.c:38
38 global_var = 0;
(gdb) step
39 return aaa () + 1;
(gdb) step
aaa () at test.c:39
39 return aaa () + 1;
(gdb) step
bbb () at test.c:39
39 return aaa () + 1;
(gdb) step
ccc () at test.c:39
39 return aaa () + 1;
(gdb) step
ddd () at test.c:32
32 return global_var;
(gdb) bt
#0 ddd () at test.c:32
#1 0x00000000004003c1 in ccc () at test.c:39
#2 bbb () at test.c:26
#3 aaa () at test.c:14
#4 main () at test.c:39
Notice that once we get to line 39 in main, GDB keeps reporting line
39 in main as the location despite understanding that the inferior is
stepping through the nested inline functions with each use of step.
The problem is that as soon as the inferior stops we call
skip_inline_frames (from inline-frame.c) which calculates the
inferiors current state in relation to inline functions - it figures
out if we're in an inline function, and if we are counts how many
inline frames there are at the current location.
So, in our example above, when we step from line 38 in main to line 39
we stop at a location that is simultaneously in all of main, aaa, bbb,
and ccc. The block structure reflects the order in which the
functions would be called, with ccc being the most inner block and
main being the most outer block. When we stop GDB naturally finds the
block for ccc, however within skip_inline_frames we spot that bbb,
aaa, and main are super-blocks of the current location and that each
layer represents an inline function. The skip_inline_frames then
records the depth of inline functions (3 in this case for aaa, bbb,
and ccc) and also the symbol of the outermost inline function (in this
case 'aaa' as main isn't an inline function, it just has things inline
within it).
Now GDB understands the stack to be main -> aaa -> bbb -> ccc,
however, the state initialised in skip_inline_frames starts off
indicating that we should hide 3 frames from the user, so we report
that we're in main at line 39. The location of main, line 39 is
derived by asking the inline function state for the last symbol in the
stack (aaa in this case), and then asking for it's location - the
location of an inlined function symbol is its call site, so main, line
39 in this case.
If the user then asks GDB to step we don't actually move the inferior
at all, instead we spot that we are in an inline function stack,
lookup the inline state data, and reduce the skip depth by 1. We then
report to the user that GDB has stopped. GDB now understands that we
are in 'aaa'. In order to get the precise location we again ask GDB
for the last symbol from the inline data structure, and we are again
told 'aaa', we then get the location from 'aaa', and report that we
are in main, line 39.
Hopefully it's clear what the mistake here is, once we've reduced the
inline skip depth we should not be using 'aaa' to compute the precise
location, instead we should be using 'bbb'. That is what this patch
does.
Now, when we call skip_inline_frames instead of just recording the
last skipped symbol we now record all symbols in the inline frame
stack. When we ask GDB for the last skipped symbol we return a symbol
based on how many frames we are skipping, not just the last know
symbol.
With this fix in place, the same session as above now looks much
better:
(gdb) start
Temporary breakpoint 1 at 0x4003b0: file test.c, line 38.
Starting program: /project/gdb/tests/inline/test
Temporary breakpoint 1, main () at test.c:38
38 global_var = 0;
(gdb) s
39 return aaa () + 1;
(gdb) s
aaa () at test.c:14
14 return bbb () + 1;
(gdb) s
bbb () at test.c:26
26 return ccc () + 1;
(gdb) s
ccc () at test.c:20
20 return ddd () + 1;
(gdb) s
ddd () at test.c:32
32 return global_var;
(gdb) bt
#0 ddd () at test.c:32
#1 0x00000000004003c1 in ccc () at test.c:20
#2 bbb () at test.c:26
#3 aaa () at test.c:14
#4 main () at test.c:39
gdb/ChangeLog:
* frame.c (find_frame_sal): Move call to get_next_frame into more
inner scope.
* inline-frame.c (inilne_state) <inline_state>: Update argument
types.
(inilne_state) <skipped_symbol>: Rename to...
(inilne_state) <skipped_symbols>: ...this, and change to a vector.
(skip_inline_frames): Build vector of skipped symbols and use this
to reate the inline_state.
(inline_skipped_symbol): Add a comment and some assertions, fetch
skipped symbol from the list.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-many-frames.c: New file.
* gdb.dwarf2/dw2-inline-many-frames.exp: New file.
Change-Id: I99def5ffb44eb9e58cda4b449bf3d91ab0386c62
|
|
Don't reorder line table entries for the same address when sorting the
line table, maintain the compiler given line order. Usually this will
reflect the order in which lines are conceptually encountered at a
given address.
Consider this example:
/* 1 */ volatile int global_var;
/* 2 */ int __attribute__ ((noinline))
/* 3 */ bar ()
/* 4 */ {
/* 5 */ return global_var;
/* 6 */ }
/* 7 */ static inline int __attribute__ ((always_inline))
/* 8 */ foo ()
/* 9 */ {
/* 10 */ return bar ();
/* 11 */ }
/* 12 */ int
/* 13 */ main ()
/* 14 */ {
/* 15 */ global_var = 0;
/* 16 */ return foo ();
/* 17 */ }
GCC 10 currently generates a line table like this (as shown by
objdump):
CU: ./test.c:
File name Line number Starting address
test.c 4 0x4004b0
test.c 5 0x4004b0
test.c 6 0x4004b6
test.c 6 0x4004b7
test.c 14 0x4003b0
test.c 15 0x4003b0
test.c 16 0x4003ba
test.c 10 0x4003ba
test.c 10 0x4003c1
The interesting entries are those for lines 16 and 10 at address
0x4003ba, these represent the call to foo and the inlined body of
foo.
With the current line table sorting GDB builds the line table like
this (as shown by 'maintenance info line-table'):
INDEX LINE ADDRESS
0 14 0x00000000004003b0
1 15 0x00000000004003b0
2 10 0x00000000004003ba
3 16 0x00000000004003ba
4 END 0x00000000004003c1
5 4 0x00000000004004b0
6 5 0x00000000004004b0
7 END 0x00000000004004b7
Notice that entries 2 and 3 for lines 10 and 16 are now in a different
order to the line table as given by the compiler. With this patch
applied the order is now:
INDEX LINE ADDRESS
0 14 0x00000000004003b0
1 15 0x00000000004003b0
2 16 0x00000000004003ba
3 10 0x00000000004003ba
4 END 0x00000000004003c1
5 4 0x00000000004004b0
6 5 0x00000000004004b0
7 END 0x00000000004004b7
Notice that entries 2 and 3 are now in their original order again.
The consequence of the incorrect ordering is that when stepping
through inlined functions GDB will display the wrong line for the
inner most frame. Here's a GDB session before this patch is applied:
Starting program: /home/andrew/tmp/inline/test
Temporary breakpoint 1, main () at test.c:15
15 /* 15 */ global_var = 0;
(gdb) step
16 /* 16 */ return foo ();
(gdb) step
foo () at test.c:16
16 /* 16 */ return foo ();
(gdb) step
bar () at test.c:5
5 /* 5 */ return global_var;
The step from line 15 to 16 was fine, but the next step should have
taken us to line 10, instead we are left at line 16. The final step
to line 5 is as expected.
With this patch applied the session goes better:
Starting program: /home/andrew/tmp/inline/test
Temporary breakpoint 1, main () at test.c:15
15 /* 15 */ global_var = 0;
(gdb) step
16 /* 16 */ return foo ();
(gdb) step
foo () at test.c:10
10 /* 10 */ return bar ();
(gdb) step
bar () at test.c:5
5 /* 5 */ return global_var;
We now visit the lines as 15, 16, 10, 5 as we would like.
The reason for this issue is that the inline frame unwinder is
detecting that foo is inlined in main. When we stop at the shared
address 0x4003ba the inline frame unwinder first shows us the outer
frame, this information is extracted from the DWARF's
DW_TAG_inlined_subroutine entries and passed via GDB's block data.
When we step again the inlined frame unwinder moves us up the call
stack to the inner most frame at which point the frame is displayed as
normal, with the location for the address being looked up in the line
table.
As GDB uses the last line table entry for an address as "the" line to
report for that address it is critical that GDB maintain the order of
the line table entries. In the first case, by reordering the line
table we report the wrong location.
I had to make a small adjustment in find_pc_sect_line in order to
correctly find the previous line in the line table. In some line
tables I was seeing an actual line entry and an end of sequence marker
at the same address, before this commit these would reorder to move
the end of sequence marker before the line entry (end of sequence has
line number 0). Now the end of sequence marker remains in its correct
location, and in order to find a previous line we should step backward
over any end of sequence markers.
As an example, the binary:
gdb/testsuite/outputs/gdb.dwarf2/dw2-ranges-func/dw2-ranges-func-lo-cold
Has this line table before the patch:
INDEX LINE ADDRESS
0 48 0x0000000000400487
1 END 0x000000000040048e
2 52 0x000000000040048e
3 54 0x0000000000400492
4 56 0x0000000000400497
5 END 0x000000000040049a
6 62 0x000000000040049a
7 END 0x00000000004004a1
8 66 0x00000000004004a1
9 68 0x00000000004004a5
10 70 0x00000000004004aa
11 72 0x00000000004004b9
12 END 0x00000000004004bc
13 76 0x00000000004004bc
14 78 0x00000000004004c0
15 80 0x00000000004004c5
16 END 0x00000000004004cc
And after this patch:
INDEX LINE ADDRESS
0 48 0x0000000000400487
1 52 0x000000000040048e
2 END 0x000000000040048e
3 54 0x0000000000400492
4 56 0x0000000000400497
5 END 0x000000000040049a
6 62 0x000000000040049a
7 66 0x00000000004004a1
8 END 0x00000000004004a1
9 68 0x00000000004004a5
10 70 0x00000000004004aa
11 72 0x00000000004004b9
12 END 0x00000000004004bc
13 76 0x00000000004004bc
14 78 0x00000000004004c0
15 80 0x00000000004004c5
16 END 0x00000000004004cc
When calling find_pc_sect_line with the address 0x000000000040048e, in
both cases we find entry #3, we then try to find the previous entry,
which originally found this entry '2 52 0x000000000040048e',
after the patch it finds '2 END 0x000000000040048e', which
cases the lookup to fail.
By skipping the END marker after this patch we get back to the correct
entry, which is now #1: '1 52 0x000000000040048e', and
everything works again.
gdb/ChangeLog:
* buildsym.c (lte_is_less_than): Delete.
(buildsym_compunit::end_symtab_with_blockvector): Create local
lambda function to sort line table entries, and use
std::stable_sort instead of std::sort.
* symtab.c (find_pc_sect_line): Skip backward over end of sequence
markers when looking for a previous line.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-inline-stepping.c: New file.
* gdb.dwarf2/dw2-inline-stepping.exp: New file.
Change-Id: Ia0309494be4cfd9dcc554f30209477f5f040b21b
|
|
In this commit:
commit d9b3de22f33e400f7f409cce3acf6c7dab07dd79
Date: Wed May 27 14:44:29 2015 -0700
Add struct to record dwarf line number state machine.
I believe an unintended change was made to how we store the DWARF line
table, the end of sequence markers between sequences of lines were
lost from the line table.
This commit fixes this small oversight and restores the end of
sequence markers.
Given that we've survived this long without noticing is clearly an
indication that this isn't that serious, however, a later patch that I
am developing would benefit from having the markers in place, so I'd
like to restore them.
Having the markers also means that the output of 'maintenance info
line-table' now more closely reflects the DWARF line table.
I've taken this opportunity to improve how 'maintenance info
line-table' displays the end of sequence markers - it now uses the END
keyword, rather than just printing an entry with line number 0. So we
see this:
INDEX LINE ADDRESS
0 12 0x00000000004003b0
1 17 0x00000000004003b0
2 18 0x00000000004003b0
3 END 0x00000000004003b7
4 5 0x00000000004004a0
5 6 0x00000000004004a0
6 END 0x00000000004004a7
Instead of what we would have seen, which was this:
INDEX LINE ADDRESS
0 12 0x00000000004003b0
1 17 0x00000000004003b0
2 18 0x00000000004003b0
3 0 0x00000000004003b7
4 5 0x00000000004004a0
5 6 0x00000000004004a0
6 0 0x00000000004004a7
I've added a small test that uses 'maintenance info line-table' to
ensure that we don't regress this again.
gdb/ChangeLog:
* dwarf2read.c (lnp_state_machine::record_line): Include
end_sequence parameter in debug print out. Record the line if we
are at an end_sequence marker even if it's not the start of a
statement.
* symmisc.c (maintenance_print_one_line_table): Print end of
sequence markers with 'END' not '0'.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Update line table parsing test.
* gdb.dwarf2/dw2-ranges-base.exp: Add new line table parsing test.
Change-Id: I002f872248db82a1d4fefdc6b51ff5dbf932d8a8
|
|
Looking at older versions of the patch, I confirmed that the odd comment
I referred to earlier was indeed from the removal of the sx support. It
also explains an oddly formatted switch statement. This patch fixes both
minor problems.
bfd/
* elfxx-riscv.c (riscv_get_prefix_class): Format s case like others.
(riscv_parse_prefixed_ext): Fix s extension comment and reword to
avoid over long line.
Change-Id: I1cb62e4a16188270f029b6376e4b1684000d6c7a
|
|
This fixes a latent bug exposed by the multi-target patch (5b6d1e4fa
"Multi-target support), and then fixes two other latent bugs exposed
by fixing that first latent bug.
The symptom described in the bug report is that starting a first
inferior, then trying to run a second (multi-threaded) inferior twice,
causes libthread_db to fail to load, along with other erratic
behavior:
(gdb) run
Starting program: /tmp/foo
warning: td_ta_new failed: generic error
Going a bit deeply, I found that if the two inferiors have different
symbols, we can see that just after inferior 2 exits, we are left with
inferior 2 selected, which is correct, but the symbols in scope belong
to inferior 1, which is obviously incorrect...
This problem is that there's a path in
scoped_restore_current_thread::restore() that switches to no thread
selected, and switches the current inferior, but leaves the current
program space as is, resulting in leaving the program space pointing
to the wrong program space (the one of the other inferior). This was
happening after handling TARGET_WAITKIND_NO_RESUMED, which is an event
that triggers after TARGET_WAITKIND_EXITED for the previous inferior
exit. Subsequent symbol lookups find the symbols of the wrong
inferior.
The fix is to use switch_to_inferior_no_thread in that problem spot.
This function was recently added along with the multi-target work
exactly for these situations.
As for testing, this patch adds a new testcase that tests symbol
printing just after inferior exit, which exercises the root cause of
the problem more directly. And then, to cover the use case described
in the bug too, it also exercises the lithread_db.so mis-loading, by
using TLS printing as a proxy for being sure that threaded debugging
was activated sucessfully. The testcase fails without the fix like
this, for the "print symbol just after exit" bits:
...
[Inferior 1 (process 8719) exited normally]
(gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: continue until exit
print re_run_var_1
No symbol "re_run_var_1" in current context.
(gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: print re_run_var_1
...
And like this for the "libthread_db.so loading" bits:
(gdb) run
Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run
warning: td_ta_new failed: generic error
[New LWP 27001]
Thread 1.1 "multi-re-run" hit Breakpoint 3, all_started () at /home/pedro/gdb/binutils-gdb/build/../src/gdb/testsuite/gdb.multi/multi-re-run.c:44
44 }
(gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: running to all_started in runto
print tls_var
Cannot find thread-local storage for LWP 27000, executable file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run:
Cannot find thread-local variables on this target
(gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: print tls_var
As mentioned, that fix above goes on to expose a couple other latent
bugs. This commit fixes those as well.
The first latent bug exposed is in
infrun.c:handle_vfork_child_exec_or_exit. The current code is leaving
inf->pspace == NULL while calling clone_program_space. The idea was
to make it so that the breakpoints module doesn't use this inferior's
pspace to set breakpoints. With that, any
scoped_restore_current_thread use from within clone_program_space
tries to restore a NULL program space, which hits an assertion:
Attaching after Thread 0x7ffff74b8700 (LWP 27276) vfork to child process 27277]
[New inferior 2 (process 27277)]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
/home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:243: internal-error: void set_current_program_space(program_space*): Assertion `pspace != NULL' faile
d.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/vfork-follow-child-exit.exp: detach-on-fork=off: continue (GDB internal error)
That NULL pspace idea was legitimate, but it's no longer necessary,
since commit b2e586e850db ("Defer breakpoint reset when cloning
progspace for fork child"). So the fix is to just set the inferior's
program space earlier.
The other latent bug exposed is in exec.c. When exec_close is called
from the program_space destructor, it is purposedly called with a
current program space that is not the current inferior's program
space. The problem is that the multi-target work added some code to
remove_target_sections that loops over all inferiors, and uses
scoped_restore_current_thread to save/restore the previous
thread/inferior/frame state. This makes it so that exec_close returns
with the current program space set to the current inferior's program
space, which is exactly what we did not want. Then the program_space
destructor continues into free_all_objfiles, but it is now running
that method on the wrong program space, resulting in:
Reading symbols from /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads...
Reading symbols from /usr/lib/debug/usr/lib64/libpthread-2.26.so.debug...
Reading symbols from /usr/lib/debug/usr/lib64/libm-2.26.so.debug...
Reading symbols from /usr/lib/debug/usr/lib64/libc-2.26.so.debug...
Reading symbols from /usr/lib/debug/usr/lib64/ld-2.26.so.debug...
[Inferior 3 (process 9583) exited normally]
/home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:170: internal-error: void program_space::free_all_objfiles(): Assertion `so->objfile == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited (GDB internal error)
The fix is to use scoped_restore_current_pspace_and_thread instead of
scoped_restore_current_thread.
gdb/ChangeLog:
2020-01-24 Pedro Alves <palves@redhat.com>
PR gdb/25410
* thread.c (scoped_restore_current_thread::restore): Use
switch_to_inferior_no_thread.
* exec.c: Include "progspace-and-thread.h".
(add_target_sections, remove_target_sections):
scoped_restore_current_pspace_and_thread instead of
scoped_restore_current_thread.
* infrun.c (handle_vfork_child_exec_or_exit): Assign the pspace
and aspace to the inferior before calling clone_program_space.
Remove stale comment.
gdb/testsuite/ChangeLog:
2020-01-24 Pedro Alves <palves@redhat.com>
PR gdb/25410
* gdb.multi/multi-re-run-1.c: New.
* gdb.multi/multi-re-run-2.c: New.
* gdb.multi/multi-re-run.exp: New.
|
|
So far this was only possible indirectly when invoked from the gdb directory.
This makes the install-strip target independent from gdb.
2020-01-24 Hannes Domani <ssbssa@yahoo.de>
* Makefile.in (install-strip): New target.
(install_sh, INSTALL_STRIP_PROGRAM, STRIP): New variables.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* configure.ac: Add AM_PROG_INSTALL_STRIP.
|
|
Fixes a compile error because the class is actually called
arm_netbsd_nat_target.
gdb/ChangeLog:
2020-01-24 Christian Biesinger <cbiesinger@google.com>
* arm-nbsd-nat.c (arm_nbsd_nat_target::fetch_registers): Rename to...
(arm_netbsd_nat_target::fetch_registers): ...this.
(arm_nbsd_nat_target::store_registers): Rename to...
(arm_netbsd_nat_target::store_registers): ...this.
Change-Id: Ibebfab9edeff48f54c32d0745afda1d74d31de92
|
|
Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only version I
tested). types.h does not define register_t by default.
We already use this define elsewhere, notably in bsd-kvm.c.
In file included from ../../gdb/arm-nbsd-nat.c:28:
/usr/include/machine/frame.h:54:2: error: unknown type name 'register_t'; did you mean '__register_t'?
register_t tf_spsr;
^
/usr/include/machine/types.h:77:14: note: '__register_t' declared here
typedef int __register_t;
^
There are other compile errors that this does not fix.
gdb/ChangeLog:
2020-01-24 Christian Biesinger <cbiesinger@google.com>
* arm-nbsd-nat.c: Define _KERNTYPES to get the declaration of
register_t.
Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e
|
|
On NetBSD, pthread_setname_np takes a printf-style format string plus
one argument:
https://netbsd.gw.com/cgi-bin/man-cgi?pthread_setname_np++NetBSD-current
This patch makes thread-pool.c handle that.
gdbsupport/ChangeLog:
2020-01-24 Christian Biesinger <cbiesinger@google.com>
* thread-pool.c (set_thread_name): Add an overload for the NetBSD
version of pthread_setname_np.
Change-Id: I61e664a813eaa7f52b6811b1a43e08ac3082d8ef
|
|
PR 25447
* coffgen.c (_bfd_coff_close_and_cleanup): Do not clear the keep
syms and keep strings flags as these may have been set in order to
prevent a bogus call to free.
|
|
Fix a:
make: *** No rule to make target '.../gdb/gdbserver/arch/arm.c', needed by 'TAGS'. Stop.
error produced by `make TAGS' by making the list of sources processed
match actual file locations and by moving host-specific object files
listed in DEPFILES to nat/ or target/ subdirectories as appropriate so
that the location of the corresponding source file can be mechanically
determined.
gdb/gdbserver/
* Makefile.in (SFILES): Adjust paths to point to real files.
(OBS): Move waitstatus.o to target/waitstatus.o.
(TAGS): Transform paths appropriately.
(%.o): Rename to...
(nat/%.o): ... this pattern rule.
(%.o): Rename to...
(target/%.o): ... this pattern rule.
* configure.srv: Adjust paths throughout to include nat/ prefix
with the revant files.
* configure.ac: Add `nat' and `target' to CONFIG_SRC_SUBDIR.
* configure: Regenerate.
|
|
Complement commit 7ea814144a31 ("Fully disentangle gdb and gdbserver"),
<https://sourceware.org/ml/gdb-patches/2002-02/msg00692.html> (from
2002!), and remove a recipe to include config files in `make TAGS',
which are no longer used by `gdbserver' as from that commit.
gdb/gdbserver/
* Makefile.in (TAGS): Remove config files from the recipe.
|
|
* readelf.c (get_build_id): Fix warning messages about corrupt
notes.
|
|
regset_from_core_section doesn't exist anymore; it has been replaced
by the iterate_over_regset_sections gdbarch method. Update comments
accordingly to not confuse readers.
gdb/ChangeLog:
2020-01-24 Christian Biesinger <cbiesinger@google.com>
* aarch64-fbsd-tdep.c (aarch64_fbsd_iterate_over_regset_sections):
Update comment.
* aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections):
Likewise.
* arm-fbsd-tdep.c (arm_fbsd_iterate_over_regset_sections): Likewise.
* gdbcore.h (deprecated_add_core_fns): Update comment to point to
the correct replacement (iterate_over_regset_sections).
* riscv-fbsd-tdep.c (riscv_fbsd_iterate_over_regset_sections):
Update comment.
Change-Id: I5eea4d18e15edae5d6dfd5d0d6241e5b2ae40daa
|
|
This is an update of this patch:
https://sourceware.org/ml/gdb-patches/2018-09/msg00884.html
This patch attempts to address PR gdb/23718 by re-enabling stdin
whenever an exception is caught during gdb.execute().
When Python gdb.execute() is called, an exception could occur (e.g. the
target disappearing), which is then converted into a Python exception. If
stdin was disabled before the exception is caught, it is not re-enabled,
because the exception doesn't propagate to the top level of the event loop,
whose catch block would otherwise enable it.
The result is that when execution of a Python script completes, GDB does
not prompt or accept input, and is effectively hung.
This change rectifies the issue by re-enabling stdin in the catch block of
execute_gdb_command, prior to converting the exception to a Python
exception.
Since this patch was originally posted I've added a test, and also I
converted the code to re-enable stdin from this:
SWITCH_THRU_ALL_UIS ()
{
async_enable_stdin ();
}
to simply this:
async_enable_stdin ();
My reasoning is that we only need the SWITCH_THRU_ALL_UIS if, at the time
the exception is caught, the current_ui might be different than at the time
we called async_disable_stdin. Within python's execute_gdb_command I think
it should be impossible to switch current_ui, so the SWITCH_THRU_ALL_UIS
isn't needed.
gdb/ChangeLog:
PR gdb/23718
* gdb/python/python.c (execute_gdb_command): Call
async_enable_stdin in catch block.
gdb/testsuite/ChangeLog:
PR gdb/23718
* gdb.server/server-kill-python.exp: New file.
Change-Id: I1cfc36ee9f8484cc1ed82be9be338353db6bc080
|
|
If we catch an exception in start_event_loop's call to
gdb_do_one_event, then it is possible that the current_ui has changed
since we called async_disable_stdin. If that's the case then calling
async_enable_stdin will be called on the wrong UI.
To solve this problem we wrap the call to async_enable_stdin with
SWITCH_THRU_ALL_UIS, this causes us to try and re-enable stdin for all
UIs, which will catch any for which we called async_disable_stdin.
gdb/ChangeLog:
* event-loop.c (start_event_loop): Wrap async_enable_stdin with
SWITCH_THRU_ALL_UIS.
gdb/testsuite/ChangeLog:
* gdb.server/multi-ui-errors.c: New file.
* gdb.server/multi-ui-errors.exp: New file.
Change-Id: I1e18deff2e6f4e17f7a13adce3553eb001cad93b
|
|
This started as a patch to enable the asm window to handle attempts to
disassemble invalid memory, but it ended up expanding into a
significant rewrite of how the asm window handles scrolling. These
two things ended up being tied together as it was impossible to
correctly test scrolling into invalid memory when the asm window would
randomly behave weirdly while scrolling.
Things that should work nicely now; scrolling to the bottom or top of
the listing with PageUp, PageDown, Up Arrow, Down Arrow and we should
be able to scroll past small areas of memory that don't have symbols
associated with them. It should also be possible to scroll to the
start of a section even if there's no symbol at the start of the
section.
Adding tests for this scrolling was a little bit of a problem. First
I would have liked to add tests for PageUp / PageDown, but the tuiterm
library we use doesn't support these commands right now due to only
emulating a basic ascii terminal. Changing this to emulate a more
complex terminal would require adding support for more escape sequence
control codes, so I've not tried to tackle that in this patch.
Next, I would have liked to test scrolling to the start or end of the
assembler listing and then trying to scroll even more, however, this
is a problem because in a well behaving GDB a scroll at the start/end
has no effect. What we need to do is:
- Move to start of assembler listing,
- Send scroll up command,
- Wait for all curses output,
- Ensure the assembler listing is unchanged, we're still at the
start of the listing.
The problem is that there is no curses output, so how long do we wait
at step 3? The same problem exists for scrolling to the bottom of the
assembler listing. However, when scrolling down you can at least see
the end coming, so I added a test for this case, however, this feels
like an area of code that is massively under tested.
gdb/ChangeLog:
PR tui/9765
* minsyms.c (lookup_minimal_symbol_by_pc_section): Update header
comment, add extra parameter, and update to store previous symbol
when appropriate.
* minsyms.h (lookup_minimal_symbol_by_pc_section): Update comment,
add extra parameter.
* tui/tui-disasm.c (tui_disassemble): Update header comment,
remove unneeded parameter, add try/catch around gdb_print_insn,
rewrite to add items to asm_lines vector.
(tui_find_backward_disassembly_start_address): New function.
(tui_find_disassembly_address): Updated throughout.
(tui_disasm_window::set_contents): Update for changes to
tui_disassemble.
(tui_disasm_window::do_scroll_vertical): No need to adjust the
number of lines to scroll.
gdb/testsuite/ChangeLog:
PR tui/9765
* gdb.tui/tui-layout-asm.exp: Add scrolling test for asm window.
Change-Id: I323987c8fd316962c937e73c17d952ccd3cfa66c
|
|
This is triggered by simply scrolling off the end of the dissasembly
window. This commit doesn't fix the actual exception that is being
thrown, which will still need to be fixed, but makes sure that we
don't ever throw an exception out to readline.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>
PR tui/9765
* tui/tui-io.c (tui_getc): Rename to ...
(tui_getc_1): ... this.
(tui_get): New, reimplent as try/catch wrapper around tui_getc_1.
Change-Id: I2e32a401ab34404b2132ec82a3e1c17b9b723e41
|
|
|
|
The pattern
objfile->section_offsets[SECT_OFF_TEXT (objfile)]
... appears very often, to get the offset of the text section of an
objfile. I thought it would be more readable to write it as:
objfile->text_section_offset ()
... so I added this method and used it where possible. I also added
data_section_offset, although it is not used as much.
gdb/ChangeLog:
* objfiles.h (ALL_OBJFILE_OSECTIONS): Move up.
(SECT_OFF_DATA): Likewise.
(SECT_OFF_RODATA): Likewise.
(SECT_OFF_TEXT): Likewise.
(SECT_OFF_BSS): Likewise.
(struct objfile) <text_section_offset, data_section_offset>: New
methods.
* amd64-windows-tdep.c (amd64_windows_find_unwind_info): Use
objfile::text_section_offset.
* coff-pe-read.c (add_pe_forwarded_sym): Likewise.
* coffread.c (coff_symtab_read): Likewise.
(enter_linenos): Likewise.
(process_coff_symbol): Likewise.
* ctfread.c (get_objfile_text_range): Likewise.
* dtrace-probe.c (dtrace_probe::get_relocated_address):
Use objfile::data_section_offset.
* dwarf2-frame.c (execute_cfa_program): Use
objfile::text_section_offset.
(dwarf2_frame_find_fde): Likewise.
* dwarf2read.c (create_addrmap_from_index): Likewise.
(create_addrmap_from_aranges): Likewise.
(dw2_find_pc_sect_compunit_symtab): Likewise.
(process_psymtab_comp_unit_reader): Likewise.
(add_partial_symbol): Likewise.
(add_partial_subprogram): Likewise.
(process_full_comp_unit): Likewise.
(read_file_scope): Likewise.
(read_func_scope): Likewise.
(read_lexical_block_scope): Likewise.
(read_call_site_scope): Likewise.
(dwarf2_rnglists_process): Likewise.
(dwarf2_ranges_process): Likewise.
(dwarf2_ranges_read): Likewise.
(dwarf_decode_lines_1): Likewise.
(new_symbol): Likewise.
(dwarf2_fetch_die_loc_sect_off): Likewise.
(dwarf2_per_cu_text_offset): Likewise.
* hppa-bsd-tdep.c (hppabsd_find_global_pointer): Likewise.
* hppa-tdep.c (read_unwind_info): Likewise.
* ia64-tdep.c (ia64_find_unwind_table): Likewise.
* psympriv.h (struct partial_symtab): Likewise.
* psymtab.c (find_pc_sect_psymtab): Likewise.
* solib-svr4.c (enable_break): Likewise.
* stap-probe.c (relocate_address): Use
objfile::data_section_offset.
* xcoffread.c (enter_line_range): Use
objfile::text_section_offset.
(read_xcoff_symtab): Likewise.
|
|
We encounter this error when building on macOS with GCC.
CXX darwin-nat.o
/src-local/binutils-gdb/gdb/darwin-nat.c: In member function 'ptid_t darwin_nat_target::wait_1(ptid_t, target_waitstatus*)':
/src-local/binutils-gdb/gdb/darwin-nat.c:1264:18: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
for (inferior *inf : all_inferiors (this))
^~~
/src-local/binutils-gdb/gdb/darwin-nat.c:1205:20: note: shadowed declaration is here
struct inferior *inf;
^~~
Fix it by moving the declaration of `inf` in the specific scopes that
need it. I think it's clearer this way anyway, as it shows that it's
not the same `inf` that is used in these different scopes.
Thanks to Iain Sandoe for reporting this. I did not see this error at
first, because I compile with the default system compiler on macOS,
which is clang. The compiler flag we try to enable for this is
`-Wshadow=local`, which is not one recognized by clang. I checked to
see if there would a version of the -Wshadow* warnings [1] we could
enable for clang, that would catch this, but the only one that would is
`-Wshadow` itself, and this is too invasive for us (which is why we
enabled just -Wshadow=local in the first place).
[1] https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow
gdb/ChangeLog:
* darwin-nat.c (darwin_nat_target::wait_1): Move `inf`
declaration to narrower scopes.
|
|
The darwin-nat.c file doesn't build since the multi-target changes
(5b6d1e4f, "Multi-target support"). This patch makes it build. I have
access to a macOS vm, so I am able to build it, but I wasn't able to
successfully codesign it and try to actually debug something, so I don't
know if it works. I don't have much more time to put on this to figure
it out, so I thought I'd sent the patch anyway, as it's at least a step
in the right direction.
The bulk of the patch is to change a bunch of functions to be methods of
the darwin_nat_target object, so that this can pass `this` to
find_inferior_ptid and other functions that now require a
process_stratum_target pointer.
The darwin_ptrace_him function (renamed to darwin_nat_target::ptrace_him
in this patch) is passed to fork_inferior as the `init_trace_fun`
parameter. Since the method can't be passed as a plain function pointer
(we need the `this` pointer), I changed the `init_trace_fun` parameter
of fork_inferior to be a gdb::function_view, so we can pass a lambda and
capture `this`.
The changes in darwin-nat.h are only to move definition higher in the
file, so that forward declarations are not needed.
gdb/ChangeLog:
* darwin-nat.h (struct darwin_exception_msg, enum
darwin_msg_state, struct darwin_thread_info, darwin_thread_t):
Move up.
(class darwin_nat_target) <wait_1, check_new_threads,
decode_exception_message, decode_message, stop_inferior,
init_thread_list, ptrace_him, cancel_breakpoint>: Declare.
* darwin-nat.c (darwin_check_new_threads): Rename to...
(darwin_nat_target::check_new_threads): ... this.
(darwin_suspend_inferior_it): Remove.
(darwin_decode_exception_message): Rename to...
(darwin_nat_target::decode_exception_message): ... this.
(darwin_nat_target::resume): Pass target to find_inferior_ptid.
(darwin_decode_message): Rename to...
(darwin_nat_target::decode_message): ... this.
(cancel_breakpoint): Rename to...
(darwin_nat_target::cancel_breakpoint): ... this.
(darwin_wait): Rename to...
(darwin_nat_target::wait_1): ... this. Use range-based for loop
instead of iterate_over_inferiors.
(darwin_nat_target::wait): Call wait_1 instead of darwin_wait.
(darwin_stop_inferior): Rename to...
(darwin_nat_target::stop_inferior): ... this.
(darwin_nat_target::kill): Call wait_1 instead of darwin_wait.
(darwin_init_thread_list): Rename to...
(darwin_nat_target::init_thread_list): ... this.
(darwin_ptrace_him): Rename to...
(darwin_nat_target::ptrace_him): ... this.
(darwin_nat_target::create_inferior): Pass lambda function to
fork_inferior.
(darwin_nat_target::detach): Call stop_inferior instead of
darwin_stop_inferior.
* fork-inferior.h (fork_inferior): Change init_trace_fun
parameter to gdb::function_view.
* fork-inferior.c (fork_inferior): Likewise.
|
|
Each time a dll is loaded, update_solib_list is called.
This in turn calls deep down xfer_partial -> windows_xfer_shared_libraries,
which calls windows_xfer_shared_library for each loaded dll,
and pe_text_section_offset reads the dll for the text section offset.
Also if the data provided by xfer_partial is bigger than 4K,
then all of this is done for each 4K chunk (see target_read_alloc_1).
Caching of the text section offset improves the startup time of
an application with >300 dynamically loaded plugins from 2m10s to 10s.
And the shutdown time improves from 2m to 2s.
gdb/ChangeLog:
2020-01-23 Hannes Domani <ssbssa@yahoo.de>
* i386-cygwin-tdep.c (core_process_module_section): Update.
* windows-nat.c (struct lm_info_windows): Add text_offset.
(windows_xfer_shared_libraries): Update.
* windows-tdep.c (windows_xfer_shared_library):
Add text_offset_cached argument.
* windows-tdep.h (windows_xfer_shared_library): Update.
|
|
|
|
PR 25444
* elf.c (assign_file_positions_for_load_sections): Avoid divide
by zero when p_align is zero.
|
