109481 Commits

Author SHA1 Message Date
Tiezhu Yang
552f1157c6 gdb: rename floatformats_ia64_quad to floatformats_ieee_quad
It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
to reflect the reality, and then we can clean up the related code.

As Tom Tromey said [1]:

  These files are maintained in gcc and then imported into the
  binutils-gdb repository, so any changes to them will have to
  be proposed there first.

the related changes have been merged into gcc master now [2], it is time
to do it for gdb.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b2dff6b2d9d6

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-04-02 08:36:33 +08:00
GDB Administrator
25eb664374 Automatic date update in version.in 2022-04-02 00:00:06 +00:00
John Baldwin
3181aed81c Remove unused variable. 2022-04-01 15:21:09 -07:00
Aaron Merey
e55039d181 gdb/debuginfod-support.c: Always display debuginfod errors
Errors encountered when downloading files from debuginfod servers
are not displayed if debuginfod verbosity is set to 0 (via
'set debuginfod verbose 0').

Tom recommended that these errors always be displayed, regardless
of the verbosity setting [1]. Fix this.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html
2022-04-01 16:39:18 -04:00
John Baldwin
c13566fdd5 Use I386_GSBASE_REGNUM in i386fbsd_get_thread_local_address.
32-bit x86 arches always the I386_*BASE_REGNUM values.  Only code that
needs to support both 64-bit and 32-bit arches needs to use
tdep->fsbase_regnum to compute a segment base register number.
2022-04-01 13:16:46 -07:00
John Baldwin
f3215e1526 FreeBSD/x86: Read segment base registers from NT_X86_SEGBASES.
FreeBSD kernels recently grew a new register core dump note containing
the base addresses of the %fs and %gs segments (corresponding to the
%fsbase and %gsbase registers).  Parse this note to permit inspecting
TLS variables in core dumps.  Native processes already supported TLS
via older ptrace() operations.
2022-04-01 13:16:46 -07:00
John Baldwin
b5c2367c3a Use pseudosections for NT_FREEBSD_X86_SEGBASES core dump notes.
This includes adding pseudosections when reading a core dump as well
as support for writing out a core dump note from a pseudosection.

bfd/ChangeLog:

	* elf-bfd.h (elfcore_write_x86_segbases): New.
	* elf.c (elfcore_grok_freebsd_note): Add pseudosections for
	NT_FREEBSD_X86_SEGBASES register notes.
	(elfcore_write_x86_segbases): New.
	(elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES
	register notes.
2022-04-01 13:16:46 -07:00
John Baldwin
a171378aa4 Recognize FreeBSD core dump note for x86 segment base registers.
This core dump note contains the value of the base address of the %fs
and %gs segments for both i386 and amd64 core dumps.  It is primarily
useful in resolving the address of TLS variables in core dumps.

binutils/ChangeLog:

	* readelf.c (get_freebsd_elfcore_note_type): Handle
	NT_FREEBSD_X86_SEGBASES.

include/ChangeLog:

	* elf/common.h (NT_FREEBSD_X86_SEGBASES): Define.
2022-04-01 13:16:46 -07:00
John Baldwin
e330d4c033 elfcore_grok_freebsd_note: Remove checks of note->namesz.
This function is only called if the note name is "FreeBSD", so
checking the name size is unnecessary.

bfd/ChangeLog:

	* elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.
2022-04-01 13:16:46 -07:00
Andrew Burgess
fd46a69ed4 gdb/testing/tui: add new _csi_{L,S,T}
This patch was original part of this series:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
  https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html

I've pulled this out as it might be useful ahead of the bigger series
being merged.

This commit adds:

  _csi_L - insert line
  _csi_S - pan down
  _csi_T - pan up
2022-04-01 16:22:01 +01:00
H.J. Lu
801a7eab11 x86: Remove bfd_arch_l1om and bfd_arch_k1om
Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been
removed from gas, ld and opcodes.

bfd/

	* Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo.
	(ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c.
	* archures.c (bfd_mach_l1om): Removed.
	(bfd_mach_l1om_intel_syntax): Likewise.
	(bfd_mach_k1om): Likewise.
	(bfd_mach_k1om_intel_syntax): Likewise.
	(bfd_k1om_arch): Likewise.
	(bfd_l1om_arch): Likewise.
	(bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch
	references.
	* config.bfd (targ_selvecs): Remove l1om_elf64_vec.
	l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec.
	(targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch.
	* configure.ac (k1om_elf64_vec): Removed.
	(k1om_elf64_fbsd_vec): Likewise.
	(l1om_elf64_vec): Likewise.
	(l1om_elf64_fbsd_vec): Likewise.
	* cpu-k1om.c: Removed.
	* cpu-l1om.c: Likewise.
	* elf64-x86-64.c (elf64_l1om_elf_object_p): Removed.
	(elf64_k1om_elf_object_p): Likewise.
	(l1om_elf64_vec): Removed.
	(l1om_elf64_fbsd_vec): Likewise.
	(k1om_elf64_vec): Likewise.
	(k1om_elf64_fbsd_vec): Likewise.
	(ELF_TARGET_OS): Undefine.
	* targets.c (_bfd_target_vector): Remove k1om_elf64_vec,
	k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec.
	* Makefile.in: Regenerate.
	* bfd-in2.h: Likewise.
	* configure: Likewise.

opcodes/

	* configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references.
	* disassemble.c (disassembler): Likewise.
	* configure: Regenerate.
2022-03-31 18:58:53 -07:00
Simon Marchi
89ab947e7f gdb/ctf: pass partial symtab's filename to buildsym_compunit
I noticed that the CTF symbol reader passes the objfile's name to all
buildsym_compunit instances it creates.  The result is that all
compunit_symtabs created have the same name, that of the objfile:

    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000286760)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x6210003911d0)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x621000275c10)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x621000286710)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }

Notice the two "name libbabeltrace2.so.0.0.0".

Change it to pass the partial_symtab's filename instead.  The output
becomes:

    { objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000295610)
        debugformat ctf
        producer (null)
        name libbabeltrace2.so.0.0.0
        dirname (null)
        blockvector ((struct blockvector *) 0x6210003a15d0)
        user ((struct compunit_symtab *) (null))
            { symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x621000288700)
        debugformat ctf
        producer (null)
        name current-thread.c
        dirname (null)
        blockvector ((struct blockvector *) 0x6210002955c0)
        user ((struct compunit_symtab *) (null))
            { symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }

Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
its name.  This is because the CTF symbol reader really creates a
partial symtab named like this.  It appears to be because the debug info
contains information that has been factored out of all CUs and is at the
"top-level" of the objfile, outside any real CU.  So it creates a
partial symtab and an artificial CU that's named after the objfile.

Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
2022-03-31 21:26:58 -04:00
Simon Marchi
af7047e858 gdb: print compunit_symtab name in "maint info symtabs"
I think it would make sense to print a compunit_symtab's name in "maint
info symtabs".  If you are looking for a given CU in the list, that's
probably the field you will be looking at.  As the doc of
compunit_symtab::name says, it is not meant to be a reliable file name,
it is for debugging purposes (and "maint info symtabs" exists for
debugging purposes).

Sample output with the new field:

    (gdb) maintenance info symtabs
    { objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
      { ((struct compunit_symtab *) 0x621000131630)
        debugformat DWARF 5
        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
        name test.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000131d10)
        user ((struct compunit_symtab *) (null))
            { symtab test.c ((struct symtab *) 0x6210001316b0)
              fullname (null)
              linetable ((struct linetable *) 0x621000131d40)
            }
            { symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
      { ((struct compunit_symtab *) 0x6210001170a0)
        debugformat DWARF 5
        producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
        name foo.c
        dirname /home/simark/build/binutils-gdb-one-target/gdb
        blockvector ((struct blockvector *) 0x621000131580)
        user ((struct compunit_symtab *) (null))
            { symtab foo.c ((struct symtab *) 0x621000117120)
              fullname (null)
              linetable ((struct linetable *) 0x6210001315b0)
            }
            { symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150)
              fullname (null)
              linetable ((struct linetable *) 0x0)
            }
      }
    }

Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
2022-03-31 21:26:53 -04:00
Simon Marchi
8458fb44b4 gdb/ctf: don't create a buildsym_compunit when building partial symbols
I am trying to do some changes to buildsym_compunit, so I am auditing
the current uses.  Something seems odd with this use of
buildsym_compunit (that this patch removes).

A buildsym_compunit is normally used when building a compunit_symtab.
That is, when expanding a partial symtab into a full compunit symtab.
In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
is only used when creating partial symtabs.  At this moment, I don't
see how that's useful.  ctf_start_archive creates a new
buildsym_compunit and starts a subfile.  But that buildsym_compunit is
never used again.  It's just overriden in ctf_start_symtab, which means
we leak the old buildsym_compunit, I suppose.

Remove ctf_start_archive completely.  Add an assert in
ctf_start_symtab to verify that we are not overwriting an existing
buildsym_compunit (meaning we'd leak the existing one).  This assert
triggers without the other part of the fix.  When doing:

  $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
  ...
  (gdb) maintenance expand-symtabs
  /home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.

Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
2022-03-31 21:26:48 -04:00
Tom Tromey
8839e3f3b0 Style URLs in GDB output
I noticed that GDB will display URLs in a few spots.  This changes
them to be styled.  Originally I thought I'd introduce a new "url"
style, but there aren't many places to use this, so I just reused
filename styling instead.  This patch also changes the debuginfod URL
list to be printed one URL per line.  I think this is probably a bit
easier to read.
2022-03-31 18:01:38 -06:00
GDB Administrator
d7abb2c4bd Automatic date update in version.in 2022-04-01 00:00:12 +00:00
Simon Marchi
59f837cb11 gdb: initialize ctf_context::builder in create_partial_symtab
I built a random project with -gctf, in order to test the CTF support in
GDB.  With my ASan/UBSan/etc-enabled build of GDB, I get:

    $ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
    ...
    Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
    /home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
    0xbebebebebebebebe: note: pointer points here

The 0xbebebebebebebebe value is a sign that the ctf_context::builder
field is uninitialized.  The problem probably goes under the radar if
the field happens to be zero-initialized, because ctf_start_archive
contains this code:

  if (ccx->builder == nullptr)
    {
      ccx->builder = new buildsym_compunit (of,
		      of->original_name, nullptr, language_c, 0);

If the field was zero-initialized (by chance), this will create a new
buildsym_compunit.  But if the field was purposely filled with random
bytes by one of the sanitizers, we won't create a buildsym_compunit here
and we'll continue with ccx->builder equal to 0xbebebebebebebebe.

Fix this the easy way by initializing ccx->builder where the other
ctf_context fields are initialized (yeah, this code could be made nicer
C++, but I am going for the obvious fix here).

With this patch, this passes cleanly on my system:

  $ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
  # of expected passes            40

... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
system gcc does not have it.

Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
2022-03-31 16:35:56 -04:00
Tom Tromey
49a82d50c0 Remove dbx mode
This patch removes gdb's dbx mode.  Regression tested on x86-64 Fedora
34.
2022-03-31 13:48:07 -06:00
H.J. Lu
0653f01479 gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml
1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
them into a single keys.xml.
2. Enable PKU for x32 to fix:

$ gdbserver :123456 x32-program
...
.../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
.
Unknown register pkru requested

on Tiger Lake.
2022-03-31 10:25:26 -07:00
Simon Marchi
5a0c4a06eb gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
The check removed by this patch, using current_inferior, looks wrong.
When debugging multiple inferiors with the Linux native target and
linux_handle_extended_wait is called, there's no guarantee about which
is the current inferior.  The vfork-done event we receive could be for
any inferior.  If the vfork-done event is for a non-current inferior, we
end up wrongfully ignoring it.  As a result, the core never processes a
TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
is never cleared, and breakpoints are never reinserted.  However,
because the Linux native target decided to ignore the event, it resumed
the thread - while breakpoints out.  And that's bad.

The proposed fix is to remove this check.  Always report vfork-done
events and let infrun's logic decide if it should be ignored.  We don't
save much cycles by filtering the event here.

Add a test that replicates the situation described above.  See comments
in the test for more details.

Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
2022-03-31 13:07:21 -04:00
Simon Marchi
20471e00e2 gdbserver/linux: set lwp !stopped when failing to resume
I see some failures, at least in gdb.multi/multi-re-run.exp and
gdb.threads/interrupted-hand-call.exp.  Running `stress -C $(nproc)` at
the same time as the test makes those tests relatively frequent.

Let's take gdb.multi/multi-re-run.exp as an example.  The failure looks
like this, an unexpected "no resumed":

    continue
    Continuing.
    No unwaited-for children left.
    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit

The situation is:

 - Inferior 1 is stopped somewhere, it won't really play a role here.
 - Inferior 2 has 2 threads, both stopped.
 - We resume inferior 2, the leader thread is expected to exit, making
   the process exit.

From GDB's perspective, a failing run looks like this:

    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #1
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: T0506:20dcffffff7f0000;07:20dcffffff7f0000;10:9551555555550000;thread:pae4cd.ae4cd;core:e;
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   713933.713933.0 [Thread 713933.713933],
      [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
      [infrun] clear_step_over_info: clearing step over info
      [infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
      [infrun] handle_signal_stop: stop_pc=0x555555555195
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] process_event_stop_test: no stepping, continue
      [remote] Sending packet: $Z0,555555555194,1#8e
      [remote] Packet received: OK
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
      [remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
      [remote] Packet received: OK
      [remote] Sending packet: $vCont;c:pae4cd.-1#9f
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit
    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #0
      [infrun] random_pending_event_thread: None found.
      [remote] wait: enter
        [remote] Packet received: N
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   -1.0.0 [process -1],
      [infrun] print_target_wait_results:   status->kind = NO_RESUMED
      [infrun] handle_inferior_event: status->kind = NO_RESUMED
      [remote] Sending packet: $Hgp0.0#ad
      [remote] Packet received: OK
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] stop_waiting: stop_waiting
      [remote] Sending packet: $qXfer:threads:read::0,1000#92
      [remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="40b6c6f7ff7f0000"/>\n</threads>\n
      [infrun] infrun_async: enable=0
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
    [infrun] fetch_inferior_event: exit

We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
When the test passes, we get an EXITED status to indicate the process
has exited.

From GDBserver's point of view, it looks like this.  The logs contain
some logging I added and that are part of this patch.

    [remote] getpkt: getpkt ("vCont;c:pae4cf.-1");  [no ack sent]
    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 713935
      [threads] proceed_one_lwp: lwp 713935
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 713936
      [threads] proceed_one_lwp: lwp 713936
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at 7ffff7d35a95: step=0
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
      [threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 713935
      [threads] wait_for_event_filtered: exit (no unwaited-for LWP)
    sigchld_handler
      [threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
    [threads] wait_1: exit

What happens is:

 - We resume the leader (713935) successfully.
 - The leader exits.
 - We resume the secondary thread (713936), we get ESRCH.  This is
   expected this the leader has exited.
 - resume_one_lwp_throw throws, it's caught by resume_one_lwp.
 - resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
   failure can be explained by the LWP becoming zombie, and swallows the
   error.
 - Note that this means that the secondary lwp still has stopped==1.
 - wait_1 is called, probably because linux_process_target::resume marks
   the async pipe at the end.
 - The exit event isn't ready yet, probably because the machine is under
   load, so waitpid returns nothing.
 - check_zombie_leaders detects that the leader is zombie and deletes
 - We try to find a resumed (non-stopped) LWP to get an event from,
   there's none since the leader (that was resumed) is now deleted, and
   the secondary thread is still marked stopped.
   wait_for_event_filtered returns -1, causing wait_1 to return
   NO_RESUMED.

What I notice here is that there is some kind of race between the
availability of the process' exit notification and the call to wait_1
that results from marking the async pipe at the end of resume.

I think what we want from this wait_1 invocation is to keep waiting, as
we will eventually get thread exit notifications for both of our
threads.

The fix I came up with is to mark the secondary thread as !stopped (or
resumed) when we fail to resume it.  This makes wait_1 see that there is
at least one resume lwp, so it won't return NO_RESUMED.  I think this
makes sense to consider it resumed, because we are going to receive an
exit event for it.  Here's the GDBserver logs with the fix applied:

    [threads] resume: enter
      [threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
      [threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
      [threads] get_pc: pc is 0x555555555195
      [threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
      [threads] get_pc: pc is 0x7ffff7d35a95
      [threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
      [threads] resume: Resuming, no pending status or step over needed
      [threads] resume_one_thread: resuming LWP 724597
      [threads] proceed_one_lwp: lwp 724597
      [threads] resume_one_lwp_throw:   continue from pc 0x555555555195
      [threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
      [threads] resume_one_thread: resuming LWP 724598
      [threads] proceed_one_lwp: lwp 724598
      [threads] resume_one_lwp_throw:   continue from pc 0x7ffff7d35a95
      [threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
      [threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
    [threads] resume: exit
    [threads] wait_1: enter
      [threads] wait_1: [<all threads>]
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
      [threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
      [threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
      [threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
      [threads] delete_lwp: deleting 724597
      [threads] wait_for_event_filtered: sigsuspend'ing
    sigchld_handler
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
      [threads] filter_event: 724598 exited
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
      [threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
      [threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
    sigchld_handler
      [threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
    [threads] wait_1: exit

Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
2022-03-31 13:04:22 -04:00
Simon Marchi
7820b634f7 gdb/testsuite/tui: implement _csi_P proc
Since commit 3cd522938792 ("Change the pager to a ui_file"), I see these
errors when running gdb.tui/scroll.exp:

    ERROR: invalid command name "_csi_P"
        while executing
    "::gdb_tcl_unknown _csi_P 2"
        ("uplevel" body line 1)
        invoked from within
    "uplevel 1 ::gdb_tcl_unknown $args"
        (procedure "::unknown" line 5)
        invoked from within
    "_csi_P 2"
        ("eval" body line 1)
        invoked from within
    "eval _csi_$cmd $params"

It looks like GDB is emitting a CSI that it did not emit before, the
"Delete character" one:

  https://vt100.net/docs/vt510-rm/DCH.html

Implement it.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
2022-03-31 12:54:56 -04:00
Simon Marchi
29d210012a gdb: fix use of fprintf_filtered in top.c
A race condition in how patches were pushed causes this build failure:

      CXX    top.o
    /home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’:
    /home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’?
     1622 |   fprintf_filtered (stream, _("\
          |   ^~~~~~~~~~~~~~~~

fprintf_filtered has been removed, gdb_printf must be used now.  Fix
this.

Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b
2022-03-31 12:52:16 -04:00
Richard Sandiford
025f768ffc aarch64: Relax check for RNG system registers
FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
to earlier architectures as well.  GAS previously made the RNG registers
conditional on having both armv8.5-a and +rng, but only +rng should be
required.

This seems to be the only feature that was handled like this.

opcodes/
	* aarch64-opc.c (SR_RNG): Don't require V8_5.

gas/
	* testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
	test.
2022-03-31 17:51:16 +01:00
Eli Zaretskii
fa8a0804b8 * gdb/top.c (print_gdb_configuration): Announce --enable-threading.
This includes the reporting of --enable/disable-threading as part of
the GDB configuration description.
2022-03-31 19:22:18 +03:00
Simon Marchi
4f5539f026 gdb/infrun: add reason parameter to stop_all_threads
Add a "reason" parameter, only used to show in debug messages what is
the reason for stopping all threads.  This helped me understand the
debug logs while adding some new uses of stop_all_threads, so I am
proposing to merge it.

Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55
2022-03-31 11:32:33 -04:00
Simon Marchi
6e6e87de92 gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*
I forgot to do this before pushing the previous commit.

Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805
2022-03-31 11:13:21 -04:00
Simon Marchi
b653576623 gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off
The particular behavior we have when using that combination of settings
doesn't seem tested at all (at least, I don't find it if I grep for "Can
not resume the parent process").  Add a simple test for that.

Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5
2022-03-31 11:08:47 -04:00
Nick Clifton
add0eb9d6e Accept the + character as part of filenames for MRI scripts. 2022-03-31 15:43:42 +01:00
Rainer Orth
5530c021ce Fix procfs.c compilation
procfs.c doesn't compile on Solaris:

/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
 3302 |   gdb_argv built_argv (args);
      |   ^~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
 3303 |   for (char *arg : built_argv)
      |                    ^~~~~~~~~~
      |                    buildargv

Fixed by including  "gdbsupport/buildargv.h".

Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
2022-03-31 10:34:52 +02:00
GDB Administrator
07e9e57ca6 Automatic date update in version.in 2022-03-31 00:00:06 +00:00
Simon Marchi
e5f7752a04 gdb/testsuite: add tests for Term
While trying to review Andrew's patch here [1], I thought I spotted a
bug in the handling of a CSI, but I had no way to know for sure.  So I
thought it would be useful to have unit tests for the handling of
control characters and control sequences of our toy terminal
implementation.  It might help avoid chasing bugs in the GDB TUI when in
reality it's a problem with the testsuite's terminal implementation.

Add the gdb.tui/tuiterm.exp file to do that.  All currently supported
control sequences and characters are tested, except _csi_m (the one that
handles colors and stuff).  _csi_m should probably be tested too, but it
will require more work.

Fix a few issues that the tests spotted:

 - backspace: according to [3] (table 4-1), a backspace when the cursor
   is at the beginning of a line should have no effect.  Our
   implementation did wrap to the end of the previous line.  Change our
   implementation to match the doc (and the test).
 - insert character: this control sequence is supposed to insert blank
   characters, shifting all the rest of the line right.  The current
   implementation moves N characters right, but it overwrites the
   characters on the right instead of shifting them.  It also doesn't
   insert blank characters at the cursor.
 - Cursor down, forward, next line: off-by-one error when reaching the
   end of the display.
 - erase in display, line: off-by-one errors.
 - vertical line position absolute: allowed setting the cursor outside
   the display, when it should clamp it to the display size.

I found that this web page [2] gave some good clues on the expected
behavior of some control characters or sequences that some other pages
didn't.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
[2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
[3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3

Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
2022-03-30 16:27:11 -04:00
Tom Tromey
47ccd6b84b Only allow QUIT on the main thread
Pedro pointed out that gdb worker threads should not react to quits.
While I don't think that the new DWARF reader can call QUIT from a
worker thread (and I don't think the existing minsym threading code
can either), it seems safest to address this before checking in the
new code.  This patch arranges for the QUIT macro to only work on the
main thread.
2022-03-30 13:39:48 -06:00
Tom Tromey
cd1c3a4544 Use gdb_printf and gdb_vprintf in more places
Luis pointed out that I missed a spot in the gdb_printf conversion --
namely aarch64-nat.c.  While looking at this, I found another spot in
darwin-nat.c that I also missed.  I can't build either of these, but I
think this patch should fix the problems.
2022-03-30 09:32:18 -06:00
Tom Tromey
c50e54825b Consolidate definition of current_directory
I noticed that both gdbserver and gdb define current_directory.
However, as it is referenced by gdbsupport, it seemed better to define
it there as well.  This patch also moves the declaration to
pathstuff.h.  Tested by rebuilding.
2022-03-30 09:08:48 -06:00
Tom Tromey
d537777dfe Decode "dynamic" interface types in Ada
In Ada, if a class implements an interface and has a dynamic
superclass, then the "offset to top" -- the offset that says how to
turn a pointer to the interface into a pointer to the whole object --
is stored in the object itself.  This patch changes GDB to understand
this.

Because this only touches Ada code, and because Joel already reviewed
it internally, I am checking it in.
2022-03-30 09:01:04 -06:00
Jeff Law
5321c31bc7 Fix for MUL instruction on the v850
* sim/v850/simops.c (Multiply64): Properly test if we need to
	negate either of the operands.

	* sim/testsuite/v850/mul.cgs: New test.
2022-03-29 20:08:35 -04:00
GDB Administrator
c09115ad6e Automatic date update in version.in 2022-03-30 00:00:07 +00:00
Tom Tromey
ad8b9970d4 Remove two unused hooks
I noticed that a couple of deprecated hooks aren't ever called, so
they can't really be used by Insight.  This patch removes them
entirely.  I checked the Insight sources, and these aren't mentioned
there, either.
2022-03-29 13:50:22 -06:00
Tom Tromey
ebfc93611b Remove unnecessary calls to wrap_here and gdb_flush
Various spots in gdb currently know about the wrap buffer, and so are
careful to call wrap_here to be certain that all output has been
flushed.

Now that the pager is just an ordinary stream, this isn't needed, and
a simple call to gdb_flush is enough.

Similarly, there are places where gdb prints to gdb_stderr, but first
flushes gdb_stdout.  stderr_file already flushes gdb_stdout, so these
aren't needed.
2022-03-29 12:46:25 -06:00
Tom Tromey
6b0c115423 Minor comment updates in utils.h
This patch updates some comments in utils.h to more closely reflect
the new reality.
2022-03-29 12:46:25 -06:00
Tom Tromey
179d59a3ee Remove vfprintf_styled
Nothing calls vfprintf_styled any more, so remove it.
2022-03-29 12:46:25 -06:00
Tom Tromey
7e9e74b6a8 Remove ui_out_flag::unfiltered_output
There is no longer any need for ui_out_flag::unfiltered_output --
nothing ever sets this flag.  This used to be needed to make the
_unfiltered output work, but now only printf_unfiltered can be used,
and it uses the puts_unfiltered method.  This patch removes the flag
and the dead code.
2022-03-29 12:46:25 -06:00
Tom Tromey
bed009b9d8 Rename fprintf_symbol_filtered
fprintf_symbol_filtered is misnamed, because whether filtering happens
is now up to the stream.  This renames it to fprintf_symbol, which
isn't a great name (the first "f" doesn't mean much and the second one
is truly meaningless here), but "print_symbol" was already taken.
2022-03-29 12:46:25 -06:00
Tom Tromey
9fbf7f083e Rename puts_filtered_tabular
puts_filtered_tabular is now misnamed, because whether filtering
happens is now up to the stream.  So, rename it.  (This function is
pretty weird, and should probably be rewritten to avoid using the
chars_printed global, and moved into objc-lang.c.  However, I haven't
done so.)
2022-03-29 12:46:25 -06:00
Tom Tromey
d0b1020bf1 Rename print_spaces_filtered
print_spaces_filtered is now misnamed, because whether filtering
happens is up to the stream.  So, rename it.
2022-03-29 12:46:24 -06:00
Tom Tromey
6cb06a8cda Unify gdb printf functions
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions.  This is done under the name
"gdb_printf".  Most of this patch was written by script.
2022-03-29 12:46:24 -06:00
Tom Tromey
a11ac3b3e8 Unify gdb putc functions
Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions.  This is done under the name
"gdb_putc".  Most of this patch was written by script.
2022-03-29 12:46:24 -06:00
Tom Tromey
0426ad513f Unify gdb puts functions
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions.  This is done under the name
"gdb_puts".  Most of this patch was written by script.
2022-03-29 12:46:24 -06:00
Tom Tromey
19a7b8ab87 Unify vprintf functions
Now that filtered and unfiltered output can be treated identically, we
can unify the vprintf family of functions: vprintf_filtered,
vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered.  (For
the gdb_stdout variants, recall that only printf_unfiltered gets truly
unfiltered output at this point.)  This removes one such function and
renames the remaining two to "gdb_vprintf".  All callers are updated.
Much of this patch was written by script.
2022-03-29 12:46:24 -06:00