Handle multiple target events before commit resume

Modify fetch_inferior_event to fetch (and handle) events from the target
as long as it provides events.

When resuming a thread that has hit a breakpoint (and it was decided
that it should be resumed), don't commit_resume just yet.  Wait until
the target has no more events to provide to do so.

Change-Id: Ia223a7d95dd5a4844c6a96e1125fb03d3e295584

gdb: add target_ops::supports_displaced_step

A previous patch added some `displaced_step_prepare` and
`displaced_step_finish` methods to allow a target_ops to implement
displaced stepping.  The default implementation is to defer to the
gdbarch.

However, there is still a `gdbarch_supports_displaced_stepping` check in
infrun.c, that decides if we should use displaced stepping or not.  So
if a target_ops implemented displaced stepping, independently of the
gdbarch, displaced stepping wouldn't be used.

Add the target_ops::supports_displaced_step method, with a default
behavior of checking if the gdbarch supports it (which is in sync with
the default implementations of displaced_step_prepare and
displaced_step_finish).

gdb: don't require displaced step copy_insn to be implemented in prepare/finish are

The gdbarch verification currently requires that the gdbarch
displaced_step_prepare and displaced_step_finish methods are provided if
displaced_step_copy_insn is (and not provided if it isn't).

displaced_step_copy_insn is used by the
multiple_displaced_buffer_manager class, but a gdbarch could very well
decide to implement prepare and finish without that, and without
requiring copy_insn.

Remove the dependency in the gdbarch verification between prepare/finish
and copy_insn.  Now, prepare and finish must be both provided or both
not-provided.

Since multiple_displaced_buffer_manager uses the `copy_insn` and `fixup`
gdbarch methods, it now asserts that they are present for the thread
architecture in its `prepare` method.

gdb: add target_ops methods for displaced stepping

Currently, the gdbarch is responsible for preparing the threads for
displaced stepping.  Since some targets specifically provide some
resources for displaced stepping, add some target_ops methods to make it
possible for targets to override the default behavior.  The default
behavior, for targets that don't override it, is to defer to the
gdbarch.

gdb: use two displaced step buffers on amd64-linux

At least as observed with gcc 9, there is enough space at _start to have
two displaced stepping buffers of 16 bytes.

An alternative way is to call mmap in the inferior to allocate one or
more executable pages.  However, this is more intrusive.

gdb: change single_displaced_buffer_manager into multiple_displaced_buffer_manager

single_displaced_buffer_manager, introduced in a previous patch, is
responsible for managing the access to a single displaced step buffer.
We'll want to be able to use more than one, so change it to
multiple_displaced_buffer_manager, which receives a collection of
buffer addresses at construction, instead of a single buffer address.

The callers keep passing a single buffer, however, so there is not
expected behavior change.

gdb: stop trying to prepare displaced steps for an inferior when it returns _UNAVAILABLE

Once we got one _UNAVAILABLE for a given inferior, don't try to prepare
other threads for displaced stepping for that inferior during this
execution of start_step_over.

gdb: move displaced stepping logic to gdbarch, allow starting concurrent displaced steps

Move displaced step logic to gdbarch
====================================

Currently, the task of preparing for a thread to execute a displaced
step is driven by the displaced_step_prepare_throw function.  It does
obviously some calls to the gdbarch to do the specific operations but
the high-level logic is in displaced_step_prepare_throw.  The steps are
roughly:

- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer

Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_fixup).  The steps are roughly:

- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
  registers or memory to do as if the instruction had been executed in
  its original location)

In order to allow some architectures to change how this is done (in
particular to allow using multiple displaced step buffers or sharing
displaced step buffers between threads), this patch makes the whole task
of preparing and finishing a displaced step gdbarch operations.

Two new gdbarch methods are added, with the following sematics:

  - gdbarch_displaced_step_prepare: Prepare for the given thread to
    execute a displaced step.  Upon return, everything should be ready
    for GDB to single step it.
  - gdbarch_displaced_step_finish: Apply any fixup required to
    compensate for the fact that the instruction was executed at
    different place than its original pc. Release any resources that was
    allocated for this displaced step.

The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
(renamed from displaced_step_fixup) offloads to
gdbarch_displaced_step_finish.

To keep the existing behavior, the logic that was previously implemented
in infrun.c is moved to a new displaced-stepping.c file.  Architectures
currently using displaced stepping are modified to use that new file to
implement the gdbarch methods.

Allow starting concurrent displaced steps
=========================================

Currently, there can only be a single displaced step in progress for
each inferior.  This is enforced in start_step_over:

      /* If this inferior already has a displaced step in process,
 don't start a new one.  */
      if (displaced_step_in_progress (tp->inf))
continue;

Since we want to allow concurrent displaced steps, we need to remove
this constraint.  The core part of GDB handling displaced steps, in
infrun.c, now tries to start as many step-overs as possible.  The
implementation provided by the gdbarch is responsible to decide whether
a given can do a displaced step at this time, and if it is, prepare it.

gdb: rename displaced_step_closure to displaced_step_copy_insn_closure

Since we're going to introduce other "displaced step" functions, make it
clear that it's the return type of the displaced_step_copy_insn family
of functions.

gdb: rename things related to step over chains

Rename step_over_queue_head to global_thread_step_over_chain_head, to
make it more obvious when reading code that we are touching the global
queue.  Rename all functions that operate on it to have "global" in
their name, to make it clear on which chain they operate on.

I also reworded a few comments in gdbthread.h.  They implied that the
step over chain is per-inferior, when in reality there is only one
global chain, as far as I understand.

Small clean up of use_displaced_stepping

This function returns the result of a quite big condition.  I think it
would be more readeable if it was broken up in smaller pieces and
commented.  This is what this patch does.

I also introduced gdbarch_supports_displaced_stepping, since it shows
the intent better than checking for gdbarch_displaced_step_copy_insn_p.
I also used that new function in displaced_step_prepare_throw.

I also updated the comment on top of can_use_displaced_stepping, which
seemed a bit outdated with respect to non-stop.  The comment likely
dates from before it was possible to have targets that always operate
non-stop under the hood, even when the user-visible mode is all-stop.

No functional changes intended.

gdb/ChangeLog:

* infrun.c (gdbarch_supports_displaced_stepping): New.
(use_displaced_stepping): Break up conditions in smaller pieces.
Use gdbarch_supports_displaced_stepping.
(displaced_step_prepare_throw): Use
gdbarch_supports_displaced_stepping.

gdb: introduce displaced_step_closure_up type alias

To help with readability, add the type displaced_step_closure_up, an
alias for std::unique_ptr<displaced_step_closure>, and use it throughout
the code base.

gdb/ChangeLog:

* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Use
displaced_step_closure_up.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
(struct displaced_step_closure_up):
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn):
Likewise.
* gdbarch.sh (displaced_step_copy_insn): Likewise.
* gdbarch.c, gdbarch.h: Re-generate.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Use
displaced_step_closure_up.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* infrun.h (displaced_step_closure_up): New type alias.
(struct displaced_step_inferior_state) <step_closure>: Change
type to displaced_step_closure_up.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Use
displaced_step_closure_up.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.

gdb: make gdbarch_displaced_step_copy_insn return an std::unique_ptr

This callback dynamically allocates a specialized displaced_step_closure, and
gives the ownership of the object to its caller.  So I think it would make
sense for the callback to return an std::unique_ptr, this is what this patch
implements.

gdb/ChangeLog:

* gdbarch.sh (displaced_step_copy_insn): Change return type to an
std::unique_ptr.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* infrun.c (displaced_step_prepare_throw): Adjust to std::unique_ptr
change.
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Change return
type to std::unique_ptr.
* aarch64-tdep.h (aarch64_displaced_step_copy_insn): Likewise.
* amd64-tdep.c (amd64_displaced_step_copy_insn): Likewise.
* amd64-tdep.h (amd64_displaced_step_copy_insn): Likewise.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Likewise.
* i386-linux-tdep.c (i386_linux_displaced_step_copy_insn): Likewise.
* i386-tdep.c (i386_displaced_step_copy_insn): Likewise.
* i386-tdep.h (i386_displaced_step_copy_insn): Likewise.
* rs6000-tdep.c (ppc_displaced_step_copy_insn): Likewise.
* s390-tdep.c (s390_displaced_step_copy_insn): Likewise.

gdb: cleanup of displaced_step_inferior_state::reset/displaced_step_clear

displaced_step_inferior_state::reset and displaced_step_clear appear to
have the same goal, but they don't do the same thing.
displaced_step_inferior_state::reset clears more things than
displaced_step_clear, but it misses free'ing the closure, which
displaced_step_clear does.

This patch replaces displaced_step_clear's implementation with just a call to
displaced_step_inferior_state::reset.  It then changes
displaced_step_inferior_state::step_closure to be a unique_ptr, to indicate the
fact that displaced_step_inferior_state owns the closure (and so that it is
automatically freed when the field is reset).

The test gdb.base/step-over-syscall.exp caught a problem when doing this, which
I consider to be a latent bug which my cleanup exposes.  In
handle_inferior_event, in the TARGET_WAITKIND_FORKED case, if we displaced-step
over a fork syscall, we make sure to restore the memory that we used as a
displaced-stepping buffer in the child.  We do so using the
displaced_step_inferior_state of the parent.  However, we do it after calling
displaced_step_fixup for the parent, which clears the information in the
parent's displaced_step_inferior_state.  It worked fine before, because
displaced_step_clear didn't completely clear the displaced_step_inferior_state
structure, so the required information (in this case the gdbarch) was
still available after clearing.

I fixed it by making GDB restore the child's memory before calling the
displaced_step_fixup on the parent.  This way, the data in the
displaced_step_inferior_state structure is still valid when we use it for the
child.  This is the error you would get in
gdb.base/step-over-syscall.exp without this fix:

    /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3911: internal-error: ULONGEST gdbarch_max_insn_length(gdbarch*): Assertion `gdbarch != NULL' failed.

gdb/ChangeLog:

* infrun.c (get_displaced_step_closure_by_addr): Adjust to
std::unique_ptr.
(displaced_step_clear): Rename to...
(displaced_step_reset): ... this.  Just call displaced->reset ().
(displaced_step_clear_cleanup): Rename to...
(displaced_step_reset_cleanup): ... this.
(displaced_step_prepare_throw): Adjust to std::unique_ptr.
(displaced_step_fixup): Likewise.
(resume_1): Likewise.
(handle_inferior_event): Restore child's memory before calling
displaced_step_fixup on the parent.
* infrun.h (displaced_step_inferior_state) <reset>: Adjust
to std::unique_ptr.
<step_closure>: Change type to std::unique_ptr.

Update copyright and license

Add GPL license with an AMD copyright in rocm gdb tests related files.
Set env HIP_ENABLE_DEFERRED_LOADING in testsuite

Change-Id: I4f03e80768992d741c19497d2a6755d284cc0b1b

Correct list of supported AMD GPU devices

Change-Id: Id9116a4f6810dfa3a47a0d1fcc84954b1cf6e399

Update user manual with AMD GPU issues

- Describe the issues with setting breakpoints using source line
  position when the corresponding code object is not loaded due to
  deferred code object loading.
- Describe an issue with instruction single stepping the S_ENDPGM
  instruction.

Change-Id: I5067571498e77bb845c0a6e1454e6b649788a32e

Rename deferred code object loading environment variable

- Rename the environment variable to control deferred code object
  loading from HIP_ENABLE_LAZY_KERNEL_LOADING to
  HIP_ENABLE_DEFERRED_LOADING.

Change-Id: I514a2c2e200954ba42f031528361f8b2e5eb4fbc

Correct typo in deferred code object user manual description

Change-Id: Ib0ea0062757c312d0a989b9c7a9fb185ef3f8790

Add legal requested disclaimer to README

Change-Id: Ibc39099dc484660635f90746964afa0fe3202884

Add description to disable deferred code object loading for AMD GPU

- The environent has been renamed to HIP_ENABLE_LAZY_KERNEL_LOADING
  and is now implemented.

Change-Id: I74d7ba76bfdb8d055eece7df0241642d8cd8103d

Comment out mention of HIP_DISABLE_LAZY_KERNEL_LOADING

- The environment variable to control deferred code object loading is
  not currently implemented so comment out its description.

Change-Id: Ic280ce43bb03e25839066090c10951e7204f483b

Update README file

- Editorial review
- Update CentOS 8.1 and RHEL8.1 build package requirements.

Change-Id: I3a8989b4d1bd221f828be29dcc509ef8568fb745

Update ROCgdb User Manual

- Update list of known issues.
- Add additional suggestions for working with many threads.

Change-Id: Ie2c576818a91a1eade0951b4a7628ce2d5b4dd84

Update the amdgcn disassembler

The ROCdbgapi disassembler now uses a symbolizer to print address
operands.

Depends-On: I8f12a37ee4c2b9a196f111f454e9c2fd26961f2e
Change-Id: I145c8f2d99eab8071e0d02eb686f53e11d4afd8c

Added delete breakpoint tests for device code

Change-Id: I1b049e6703127a0522ed6c5a6b51161c45cf1156

nonstop mode test for ROCgdb

Change-Id: I27546c8178e8b681a0ac29166d193dea519aa11d

Update README file and use of updated ROCdbgapi header

- Add support for additional OS distributions to README.
- Allow ROCdbgapi to use incomplete struct types for client opaque
  types by adding reinterpret_cast.

Change-Id: I06b277cb46ee35c97467cc3a04abcc390d156d24

Update the solib list when the target is deactivated

Since the code objects are no longer accessible after the runtime
is unloaded, we need to refresh the solist to avoid "Cannot access
memory" errors if trying to access stale code objects.

Change-Id: I298025a599e6d9118a44070197102201594bc2e3

Don't mark the process as exited when detaching

rocm_target_inferior_exit is shared between target::mourn_inferior
(the process has exited) and to target::detach (the process is still
running). Move the call to amd_dgapi_process_detach to the target
function instead of the inferior_exit callback.

Change-Id: I323eb5ae609e3097feab81a9bb9721df2a675acb

Fix stop_reason reporting

If the dbgapi stop_reason has both exceptions and a breakpoint or
single-step, we should report the exceptions. Also, add debug_trap,
assert_trap, and other_trap as reasons to report a SIGTRAP.

Change-Id: I1b3c18aff894cea0818f35f76b66de10724ebc24

Revise compile flag of gdb test for hip program.

Change-Id: If6ecba593b6637340650fa9704edb2b30832e9f9

Unregister the the rocm event handler

When the target closes, unregister our event handler from the
event loop.

Change-Id: Ic3c072c4de6f90c2c55a1d681a9a2d7e4c507609

Set the vector registers type's name

The "maintenance print register-groups" command reported the vector
registers type did not have a name, so set the name when we create it.

Before:

(gdb) maintenance print register-groups
 Name         Nr  Rel Offset    Size  Type            Groups
 v0            0    0      0     256 *1              all,general,vector
 ...
*1: Register type's name NULL.

After:

(gdb) maintenance print register-groups
 Name         Nr  Rel Offset    Size  Type            Groups
 v0            0    0      0     256 int32_t[64]     all,general,vector
...

Change-Id: I17fc4ddad488186f44f166dfd3577b33d80e98ad

Use the process's comm value for GPU threads name

Instead of using the dispatched kernel's name as the thread name,
use the process's comm value.  This will match the CPU threads, and
still allow to differentiate threads from different inferiors.

Change-Id: I0746f1d4cdbdd44e9f0ea65997ca9be80ef95bb6

Add  new multi-GPU multi-func test in gdb.rocm.

Change-Id: I682b5502f9bc4fad963b1d650b4128c3da1e0bb5

Check the amd-dbgapi library version

Make sure the loaded debugger library version is greater than or
equal to the one used to build ROCgdb.

Change-Id: I6a651a721c1e3066a6f95a15caebbe1d207eda87

Change regcache list to be an hash map

The regcache objects created for threads are stored in a linked list,
regcache::current_regcache.

This may result in bad performance when debugging a lot of threads, as GDB
needs to walk the linked list to fetch a regcache given a ptid.

This patch replaces the linked list with an std::unordered_map, indexed by
(ptid, arch).  The lookups, in get_thread_arch_aspace_regcache, should become
faster when the number of threads grow.  With a small number of threads, it
will probably be a bit slower to do an hash map lookup than to walk a few
linked list nodes,  but it should not be perceptible.

The function registers_changed_ptid deletes all regcaches related to a given
ptid (there could be multiple, with different arches).  Since the hash map is
indexed by (ptid, arch), we can't do a simple lookup, so we fall back on
iterating on all the hash map values.  It should be the same complexity as what
we have today.  This function is called when resuming execution, so it would be
nice to find a more efficient way to do this.

Similarly, the function regcache_thread_ptid_changed is called when a thread
changes ptid, so it needs to look up all regcaches for a given ptid.  This one
also iterates on all the hash map values.  However, it is not called often
(mostly when creating an inferior, on some specific platforms), so it shouldn't
be a problem.

Change-Id: I01c9af327b472422b432b71b6c4737424839d254

Make find_thread_ptid lookup thread map instead of iterate

Now that inferior threads are stored in a map, change the
find_thread_ptid function to look up a thread using std::map::find,
instead of iterating on all of the inferior's threads.

Change-Id: I0041380775fa2bfffdb6e78847d980015b670708

Change inferior thread list to be a thread map

Remove the inferior::thread_list linked list, replace with
inferior::thread_map, an std::map indexed by ptid.  This should make it
faster to look up a thread from its ptid.

Change-Id: I0ac4832542d8427625e330ff9dc3e7f989b164e8

Fix indentation in print_thread_info_1

Change-Id: Ic18155aea3fb2df4e3428f5f5d5ad4e727160b85

Handle code object URIs

The URI is decoded and the file is opened on the target. Only
file:// is currently supported.

Change-Id: Ifc7869cab60b98f6d4f1645fc2f4ab7c1c767b6d

Update get_os_pid

Return AMD_DBGAPI_STATUS_ERROR_PROCESS_EXITED if the process has
exited.

Change-Id: Ibb9137552e74628ec46633d18f88473fd8b97195

Error message cleanup

Don't print an error message when reading/writing memory fails,
only return TARGET_XFER_EOF.

Change-Id: Iba9c8279e6f5db37344c5eeb8d45cc56902c90ab

re-organize rocm gdb test to follow gdb test naming convention.

Change-Id: Ib2c4f9894dbd9de91e23a041c61c83c20c9cbaad

modified ROCm Thread to AMDGPU Thread in test

Change-Id: I459797d5b8138228d99d34d41e24ce96517f4368

amdgcn: Add Navi1x support

bfd ChangeLog:
        * archures.c: Add gfx10 definitions.
        * cpu-amdgcn.c: Likewise.
        * elf64-amdgcn.c: Likewise.

Change-Id: Ieb4dd551836a990d2cdc883f6d7e52984f6dd9e3

Update the documentation

Add additional packages needed to generate the documentation on CentOS.

Change-Id: I355f3a95d4f484ab746e3d3985a031df5c0b24e5

Correct README-ROCM.md spelling

Change-Id: I0940dad0e54161bb4d0f869944722eb6eb8ec443

Merge branch 'gdb-9-branch' into amd-staging-rocgdb-9

Change-Id: I87c1d275efe8128a2615286a6192e3e7163545a4

Set GDB version number to 9.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 9.1.

Automatic date update in version.in

Make fputs_unfiltered use fputs_maybe_filtered

This patch redefines fputs_unfiltered in utils.c, with new behavior to
forward parameters to fputs_maybe_filtered.  This makes
fputs_unfiltered identical to fputs_filtered, except filtering is
disabled.

Some callers of fputs_unfiltered have been updated to use ui_file_puts
where they were using other ui_file_* functions anyway for IO.

This fixes the problem I saw with \032\032post-prompt annotation being
flushed to stdout in the wrong order.

gdb/ChangeLog
2020-02-05  Iain Buclaw  <ibuclaw@gdcproject.org>

PR gdb/25190:
        * gdb/remote-sim.c (gdb_os_write_stderr): Update.
        * gdb/remote.c (remote_console_output): Update.
        * gdb/ui-file.c (fputs_unfiltered): Rename to...
        (ui_file_puts): ...this.
        * gdb/ui-file.h (ui_file_puts): Add declaration.
        * gdb/utils.c (emit_style_escape): Update.
        (flush_wrap_buffer): Update.
        (fputs_maybe_filtered): Update.
        (fputs_unfiltered): Add function.

Change-Id: I17ed5078f71208344f2f8ab634a6518b1af6e213

Make gdb_flush also flush the wrap buffer

This changes gdb_flush to also flush the internal wrap buffer.  A few
places needed to continue using the previous approach, so this also
introduces ui_file_flush for those.

gdb/ChangeLog
2020-02-05  Iain Buclaw  <ibuclaw@gdcproject.org>

        * gdb/event-loop.c (gdb_wait_for_event): Update.
        * gdb/printcmd.c (printf_command): Update.
        * gdb/remote-fileio.c (remote_fileio_func_write): Update.
        * gdb/remote-sim.c (gdb_os_flush_stdout): Update.
        (gdb_os_flush_stderr): Update.
        * gdb/remote.c (remote_console_output): Update.
        * gdb/ui-file.c (gdb_flush): Rename to...
        (ui_file_flush): ...this.
        (stderr_file::write): Update.
        (stderr_file::puts): Update.
        * gdb/ui-file.h (gdb_flush): Rename to...
        (ui_file_flush): ...this.
        * gdb/utils.c (gdb_flush): Add function.
        * gdb/utils.h (gdb_flush): Add declaration.

Change-Id: I7ca143d30f03dc39f218f6e880eb9bca9e15af39

Revert basenames_may_differ patch

Commit a0c1ffedc regressed certain cases coming from Eclipse.
See PR breakpoints/24915.

This patch reverts the commit for the gdb 9 release.

gdb/ChangeLog
2020-02-07  Tom Tromey  <tromey@adacore.com>

PR breakpoints/24915:
* source.c (find_and_open_source): Do not check basenames_may_differ.

gdb/testsuite/ChangeLog
2020-02-07  Tom Tromey  <tromey@adacore.com>

PR breakpoints/24915:
* gdb.base/annotate-symlink.exp: Use setup_xfail.

Change-Id: Iadbf42f35eb40c95ad32b2108ae25d8f199998bd

Automatic date update in version.in

Update documentation

- Update README-ROCM.md
- Remove unnecessary @indent from gdb.texinfo copyright block
- Correct spelling mistake in gdb.texinfo

Change-Id: I56dde693570119683bfcc86d85ae8eebe522eff5

Update AMD GPU chip names.

Change-Id: Id893a23603fd39ffc7972580bcc25286a7c4805d

Add heterogeneous debugging support and AMD GPU information.

Change-Id: I1a7d9a3837abc48174f4da6e88ea3cdc1f918176

Resubmiting Tests for showing various information in hip device code

Change-Id: I33906bdcc953118bf76c37d66a9bed16886fbcb7

Merge branch 'gdb-9-branch' into amd-staging-rocgdb-9

Change-Id: I6427b9979d8e5f92d50dd8cdefa923568a33260e

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Implement '--enable-src-release-build' option and make src-release.sh use it

The generation of snapshots has been broken since we've disable
in-tree builds for GDB.  Given that src-release.sh performs a build
before creating the release tarball, and that this build is performed
in-tree, the solution we found is to implement a new top-level
configure flag called '--enable-src-release-build' which disables the
in-tree build restriction, and then make src-release.sh use it.

ChangeLog:
2020-02-01  Sergio Durigan Junior  <sergiodj@redhat.com>
    Eli Zaretskii  <eliz@gnu.org>

* configure.ac: Don't abort the build if trying to build GDB in tree
_and_ invoking with '--enable-src-release-build'.
* configure: Regenerate.
* src-release.sh (do_proto_toplev): Invoke 'configure' using

Change-Id: Ic6dd55accd9a03e62fe498f7fd704fb67f44bfa9

libctf: compilation failure on MinGW due to missing errno values

This commit fixes a compilation failure in a couple of libctf files
due to the use of EOVERFLOW and ENOTSUP, which are not defined
when compiling on MinGW.

libctf/ChangeLog:

PR binutils/25155:
* ctf-create.c (EOVERFLOW): If not defined by system header,
redirect to ERANGE as a poor man's substitute.
* ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead.

This one is how Eli implemented it. I think this implementation
has a weakness in the following sense: If other units in libctf
start using those constants, we'll get the same error again.
Also, I'm wondering whether their use is documented as part of
the official libtcf API or not -- users might be writing code
that tests for these, and if the system doesn't support them,
how would they know what errno code to use in its place. This
argues for a having that information in one of libctf's header
files. I think it would be nice to have those in ctf-decls.h,
but I think we'll need to include <errno.h> in ctf-decls.h if
we decide to define those macros there.

Rather than second-guess what the CTF developers would prefer,
I'm starting by sending Eli's patch, to see what you guys think.

Thanks,
--
Joel

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix library segment-address for 64bit values

The address was written as a long value, but long is always a 32bit value
on Windows, which lead to truncated addresses.
The solution was to use paddress instead.

gdb/gdbserver/ChangeLog:

2020-01-28  Hannes Domani  <ssbssa@yahoo.de>

* server.c (handle_qxfer_libraries): Write segment-address with
paddress.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Abort configure immediately if building GDB in tree

The move of gnulib to the top src directory is causing the GDB build
to break if configured in tree. We hope to lift that limitation at
some point but, in the meantime, this commit allows us to abort
the initial configure right away with a clear error message should
the user attempt to build in tree.

ChangeLog:

        * configure.ac: Abort the build with an error if trying to build
        GDB in tree.
        * configure: Regenerate.

Automatic date update in version.in

Automatic date update in version.in

Use malloc/free in the dbgapi callbacks

Replace xmalloc/xfree with malloc/free for the allocate_memory/
deallocate_memory callbacks. The dbgapi requires nullptr to be
returned if the memory cannot be allocated, but xmalloc throws
an internal gdb error in such cases.

gdb/ChangeLog:

        * gdb/rocm-tdep.c: Adjust callbacks.

Depends-On: Id4af9dcd08b66acb6a9e9997c28a2807a5e0652e
Change-Id: I1cf6a4f6e96d8b86b716291f03a22dfbd5d83262

Fix issues with multiple inferiors

Issue #1:
Thread 3 "bit_extract_kernel" hit Breakpoint 1, bit_extract_kernel ()
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) info threads
amd_dbgapi_wave_list failed (rc=-14)

An inferior may not have yet been attached when update_thread_list is
called. The inferior should be skipped if its process_id is null.

Issue #2:
Thread 3 "bit_extract_kernel" hit Breakpoint 1, bit_extract_kernel ()
(gdb) add-inferior -exec /bin/ls
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /bin/ls...
(No debugging symbols found in /bin/ls)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (/bin/ls)]
(gdb) run
Starting program: /bin/ls
Warning:
Cannot insert breakpoint -8.
Cannot access memory at address 0x7fffedaa265b

Internal ROCgdbapi breakpoints should not be re-evaluated for new
inferiors. They are inserted for a specific process_id, and removed
when the process is detached.

gdb/ChangeLog:
        * gdb/rocm-tdep.c: Skip inferiors without process_ids. Override
        breakpoint_ops::re_set for rocm internal breakpoints to
        disable re-evaluation.

Change-Id: Icb0be93b74aae1cf80c7f1657cf6d01e16eb8efb

Fix build error in gdb/rocm-tdep.c

This patch fixes the following build error:
../../gdb/rocm-tdep.c: In function ‘void async_file_flush()’:
../../gdb/rocm-tdep.c:205:1: error: no previous declaration for ‘void async_file_flush()’ [-Werror=missing-declarations]
 async_file_flush (void)
 ^~~~~~~~~~~~~~~~

Change-Id: Ia5be169ce25452e40eeba0b6ff29d3c07db2795c

Merge branch 'gdb-9-branch' into amd-staging-rocgdb-9

Change-Id: I8bae375370df2248e4e9330060455f93cce3eed2

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Don't define _FORTIFY_SOURCE on MinGW

Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564

To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.

gdb/ChangeLog:

2020-01-10  Christian Biesinger  <cbiesinger@google.com>

* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.

Change-Id: Ide6870ab57198219a2ef78bc675768a789ca2b1d

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in