PR28401, invalid section name lookup

The PR28401 testcase has a section named "", ie. an empty string.
This results in some silly behaviour in load_debug_section, and
dump_dwarf_section.  Fix that.  Note that this patch doesn't correct
the main complaint in PR28401, "failed to allocate", since malloc
failures on sections having huge bogus sizes are to be expected.  We
can't safely catch all such cases by comparing with file size, for
example, where sections contain compressed data.

PR 28401
* objdump.c (load_debug_section): Don't attempt to retrieve
empty name sections.
(dump_dwarf_section): Likewise.

Automatic date update in version.in

[gdb/testsuite] Make tui testing less verbose

Currently, tui testing is rather verbose.  When using these RUNTESTFLAGS to
pick up all tui tests (17 in total):
...
rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \
  | xargs grep -l tuiterm_env) )
...
we have:
...
$ wc -l gdb.log
120592 gdb.log
...

Most of the output is related to controlling the tui screen, but that does
not give a top-level sense of how the test-case progresses.

Put differently: a lot of bandwith is used to describe how we arrive at a
certain tui screen state.  But we don't actually always show the state we
arrive at, unless there's a FAIL.

And if there's say, a PASS that should actually be FAILing, it's hard to
detect.

Fix this by:
- dropping the -log on the call to verbose in _log.  We still can get the
  same info back using runtest -v.
- dumping the screen or box that we're checking, also when the test passes.

Brings down verbosity to something more reasonable:
...
$ wc -l gdb.log
3221 gdb.log
...

Tested on x86_64-linux.

[gdb/testsuite] Add Term::dump_box in lib/tuiterm.exp

Factor out new proc Term::get_region and use it to implement a
new proc Term::dump_box, similar to Term::dump_screen.

Tested on x86_64-linux.

gdb: Remove deprecated assertion in setting::get

The commit 702991711a91bd47b209289562843a11e7009396 (gdb: Have setter
and getter callbacks for settings) makes it possible for a setting not
to be backed by a memory buffer but use callback functions instead to
retrieve or set the setting's value.

An assertion was not properly updated to take into account that the
m_var member (which points to a memory buffer, if used) might be nullptr
if the setting uses callback functions.  If the setting is backed by a
memory buffer, the m_var has to be non nullptr, which is already checked
before the pointer is dereferenced.

This commit removes this assertion as it is not valid anymore.

Remove 'varsize-limit'

This makes the Ada-specific "varsize-limit" a synonym for
"max-value-size", and removes the Ada-specific checks of the limit.

I am not certain of the history here, but it seems to me that this
code is fully obsolete now.  And, removing this makes it possible to
index large Ada arrays without triggering an error.  A new test case
is included to demonstrate this.

Allow lazy 'zero' value

This changes value_zero to create a lazy value.  In many cases,
value_zero is called in expression evaluation to wrap a type in a
non-eval context.  It seems senseless to allocate a buffer in these
cases.

A new 'is_zero' flag is added so we can preserve the existing
assertions in value_fetch_lazy.

A subsequent patch will add a test where creating a zero value would
fail, due to the variable size check.  However, the contents of this
value are never needed, and so creating a lazy value avoids the error
case.

Add lval_funcs::is_optimized_out

This adds an is_optimized_out function pointer to lval_funcs, and
changes value_optimized_out to call it.  This new function lets gdb
determine if a value is optimized out without necessarily fetching the
value.  This is needed for a subsequent patch, where an attempt to
access a lazy value would fail due to the value size limit -- however,
the access was only needed to determine the optimized-out state.

[gdb/testsuite] Fix FAIL in gdb.mi/mi-nsmoribund.exp

Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-nsmoribund.exp: print done = 1
Expecting: ^(.*[^M
]+)?([^
]*^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"[^M
]+[(]gdb[)] ^M
[ ]*)
103-exec-continue --all^M
=library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\
  host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\
  ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M
103^running^M
*running,thread-id="5"^M
(gdb) ^M
FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output)
...

The regexp expect running messages for all threads, but we only get one for
thread 5.

The test-case uses non-stop mode, and when the exec-continue --all command is
issued, thread 5 is stopped and all other threads are running.  Consequently,
only thread 5 is resumed, and reported as running.

Fix this by updating the regexp.

Tested on x86_64-linux.

gdb/python: fix memory leak in python inferior code

When a user creates a gdb.Inferior object for the first time a new
Python object is created.  This object is then cached within GDB's
inferior object using the registry mechanism (see
inferior_to_inferior_object in py-inferior.c, specifically the calls
to inferior_data and set_inferior_data).

The Python Reference to the gdb.Inferior object held within the real
inferior object ensures that the reference count on the Python
gdb.Inferior object never reaches zero while the GDB inferior object
continues to exist.

At the same time, the gdb.Inferior object maintains a C++ pointer back
to GDB's real inferior object.  We therefore end up with a system that
looks like this:

                   Python Reference
                         |
                         |
    .----------.         |          .--------------.
    |          |------------------->|              |
    | inferior |                    | gdb.Inferior |
    |          |<-------------------|              |
    '----------'         |          '--------------'
                         |
                         |
                    C++ Pointer

When GDB's inferior object is deleted (say the inferior exits) then
py_free_inferior is called (thanks to the registry system), this
function looks up the Python gdb.Inferior object and sets the C++
pointer to nullptr and finally reduces the reference count on the
Python gdb.Inferior object.

If at this point the user still holds a reference to the Python
gdb.Inferior object then nothing happens.  However, the gdb.Inferior
object is now in the non-valid state (see infpy_is_valid in
py-inferior.c), but otherwise, everything is fine.

However, if there are no further references to the Python gdb.Inferior
object, or, once the user has given up all their references to the
gdb.Inferior object, then infpy_dealloc is called.

This function currently checks to see if the inferior pointer within
the gdb.Inferior object is nullptr or not.  If the pointer is nullptr
then infpy_dealloc immediately returns.

Only when the inferior point in the gdb.Inferior is not nullptr do
we (a) set the gdb.Inferior reference inside GDB's inferior to
nullptr, and (b) call the underlying Python tp_free function.

There are a number things wrong here:

  1.  The Python gdb.Inferior reference within GDB's inferior object
  holds a reference count, thus, setting this reference to nullptr
  without first decrementing the reference count would leak a
  reference, however...

  2. As GDB's inferior holds a reference then infpy_dealloc will never
  be called until GDB's inferior object is deleted.  Deleting a GDB
  inferior ohject calls py_free_inferior, and so gives up the
  reference.  At this point there is no longer a need to call
  set_inferior_data to set the field back to NULL, that field must
  have been cleared in order to get the reference count to zero, which
  means...

  3. If we know that py_free_inferior must be called before
  infpy_dealloc, then we know that the inferior pointer in
  gdb.Inferior will always be nullptr when infpy_dealloc is called,
  this means that the call to the underlying tp_free function will
  always be skipped.  Skipping this call will cause Python to leak the
  memory associated with the gdb.Inferior object, which is what we
  currently always do.

Given all of the above, I assert that the C++ pointer within
gdb.Inferior will always be nullptr when infpy_dealloc is called.
That's what this patch does.

I wrote a test for this issue making use of Pythons tracemalloc
module, which allows us to spot this memory leak.

[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp

Following 2 test points are failing with clang compiler

(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_nofb print
(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_loopfb print

As in commit f677852bbda "[gdb/testsuite] Use function_range in
gdb.dwarf2/dw2-abs-hi-pc.exp", the problem is that the CU and functions
have an empty address range, due to using asm labels in global scope,
which is a known source of problems, as explained in the comment of proc
function_range in gdb/testsuite/lib/dwarf.exp.  Hence fix this also by
using function_range.

Tested on x86_64-linux with gcc and clang.

gdb/python: add a new gdb_exiting event

Add a new event, gdb.events.gdb_exiting, which is called once GDB
decides it is going to exit.

This event is not triggered in the case that GDB performs a hard
abort, for example, when handling an internal error and the user
decides to quit the debug session, or if GDB hits an unexpected,
fatal, signal.

This event is triggered if the user just types 'quit' at the command
prompt, or if GDB is run with '-batch' and has processed all of the
required commands.

The new event type is gdb.GdbExitingEvent, and it has a single
attribute exit_code, which is the value that GDB is about to exit
with.

The event is triggered before GDB starts dismantling any of its own
internal state, so, my expectation is that most Python calls should
work just fine at this point.

When considering this functionality I wondered about using the
'atexit' Python module.  However, this is triggered when the Python
environment is shut down, which is done from a final cleanup.  At
this point we don't know for sure what other GDB state has already
been cleaned up.

gdb/python: update events test to handle missing exit_code

The test gdb.python/py-events.exp sets up a handler for the gdb.exited
event.  Unfortunately the handler is slightly broken, it assumes that
the exit_code attribute will always be present.  This is not always
the case.

In a later commit I am going to add more tests to py-events.exp test
script, and in so doing I expose the bug in our handling of gdb.exited
events.

Just to be clear, GDB itself is fine, it is the test that is not
written correctly according to the Python Events API.

So, in this commit I fix the Python code in the test, and extend the
test case to exercise more paths through the Python code.

Additionally, I noticed that the gdb.exited event is used as an
example in the documentation for how to write an event handler.
Unfortunately the same bug that we had in our test was also present in
the example code in the manual.

So I've fixed that too.

After this commit there is no functional change to GDB.

Automatic date update in version.in

Use unique_xmalloc_ptr<char> when demangling

I noticed that some methods in language_defn could use
unique_xmalloc_ptr<char> rather than a plain 'char *'.  This patch
implements this change, fixing up the fallout and changing
gdb_demangle to also return this type.  In one spot, std::string is
used to simplify some related code, and in another, an auto_obstack is
used to avoid manual management.

Regression tested on x86-64 Fedora 34.

Minor boolean fix in windows-nat.c

I noticed a spot in windows-nat.c that used '1' rather than the more
appropriate 'true'.  This patch fixes it.

[gdb/build] Add CXX_DIALECT to CXX

Say we use a gcc version that (while supporting c++11) does not support c++11
by default, and needs an -std setting to enable it.

If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
we'd have:
...
CXX="g++ -std=gnu++11"
...

That mechanism however has the following problem (quoting from commit
0bcda685399):
...
the top level Makefile passes CXX down to subdirs, and that overrides whatever
gdb/Makefile may set CXX to.  The result would be that a make invocation from
the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a
make invocation at the top level would not.
...

Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
does:
...
CXX=g++
CXX_DIALECT=-std=gnu++11
...

The problem reported in PR28318 is that using the custom instead of the
default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
support fail.

We could simply add $CXX_DIALECT to the test for std::thread support, but
that would have to be repeated for each added c++ support test.

Instead, fix this by doing:
...
CXX="g++ -std=gnu++11"
CXX_DIALECT=-std=gnu++11
...

This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
some situations:
...
$ touch src/gdb/dwarf2/read.c
$ ( cd build/gdb; make V=1 dwarf2/read.o )
g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
...

However, both settings are needed:
 - the switch in CXX for the std::thread tests (and other tests)
 - the switch in CXX_DIALECT so it can be appended in Makefiles, to
   counteract the fact that the top-level Makefile overrides CXX

The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
AX_CXX_COMPILE_STDCXX from autoconf-archive.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28318

[gdb/symtab] Use unrelocated addresses in call_site

Consider test-case gdb.trace/entry-values.exp with target board
unix/-fPIE/-pie.

Using this command we have an abbreviated version, and can see the correct
@entry values for foo:
...
$ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
  -ex start \
  -ex "break foo" \
  -ex "set print entry-values both" \
  -ex continue
Temporary breakpoint 1 at 0x679

Temporary breakpoint 1, 0x0000555555554679 in main ()
Breakpoint 2 at 0x55555555463e

Breakpoint 2, 0x000055555555463e in foo (i=0, i@entry=2, j=2, j@entry=3)
...

Now, let's try the same again, but run directly to foo rather than stopping at
main:
...
$ gdb -q -batch outputs/gdb.trace/entry-values/entry-values \
  -ex "break foo" \
  -ex "set print entry-values both" \
  -ex run
Breakpoint 1 at 0x63e

Breakpoint 1, 0x000055555555463e in foo (i=0, i@entry=<optimized out>, \
  j=2, j@entry=<optimized out>)
...

So, what explains the difference?  Noteworthy, this is a dwarf assembly
test-case, with debug info for foo and bar, but not for main.

In the first case:
- we run to main
- this does not trigger expanding debug info, because there's none for main
- we set a breakpoint at foo
- this triggers expanding debug info.  Relocated addresses are used in
  call_site info (because the exec is started)
- we continue to foo, and manage to find the call_site info

In the second case:
- we set a breakpoint at foo
- this triggers expanding debug info.  Unrelocated addresses are used in
  call_site info (because the exec is not started)
- we run to foo
- this triggers objfile_relocate1, but it doesn't update the call_site
  info addresses
- we don't manage to find the call_site info

We could fix this by adding the missing call_site relocation in
objfile_relocate1.

This solution however is counter-trend in the sense that we're trying to
work towards the situation where when starting two instances of an executable,
we need only one instance of debug information, implying the use of
unrelocated addresses.

So, fix this instead by using unrelocated addresses in call_site info.

Tested on x86_64-linux.

This fixes all remaining unix/-fno-PIE/-no-pie vs unix/-fPIE/-pie
regressions, like f.i. PR24892.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24892

Co-Authored-By: Tom de Vries <tdevries@suse.de>

[gdb/symtab] C++-ify call_site

- add constructor
- add member function call_site::pc ()

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>

[gdb/symtab] Add call_site_eq and call_site_hash

In commit b4c919f7525 "[gdb/symtab] Fix htab_find_slot call in
read_call_site_scope" , I removed the comment:
...
It must be the first field as we overload core_addr_hash and core_addr_eq for
it.
...
for field pc of struct call_site.

However, this was not tested, and when indeed moving field pc to the second
location, we run into a testsuite failure in gdb.trace/entry-values.exp.

This is caused by core_addr_eq (the eq_f function for the htab) being
called with a pointer to the pc field (as passed into htab_find_slot) and a
pointer to a hash table element.  Now that pc is no longer the first field,
the pointer to hash table element no longer points to the pc field.

This could be fixed by simply reinstating the comment, but we're trying to
get rid of this kind of tricks that make refactoring more difficult.

Instead, fix this by:
- reverting commit b4c919f7525, apart from the comment removal, such that
  we're passing a pointer to element to htab_find_slot
- updating the htab_find_slot call in compunit_symtab::find_call_site
  in a similar manner
- adding a call_site_eq and call_site_hash, and using these in the hash table
  instead of core_addr_eq and core_addr_hash.

Tested on x86_64-linux, both with and without a trigger patch that moves pc to
the second location in struct call_site.

Fix remote-sim.c compilation

The change "make string-like set show commands use std::string
variable" caused remote-sim.c to fail to build.  The issue is that the
code does:

  const std::string &sysroot = gdb_sysroot;
  if (is_target_filename (sysroot))
    sysroot += strlen (TARGET_SYSROOT_PREFIX);

... which isn't valid.

This patch changes this code to use a 'const char *' again, fixing the
build.

[gdb/testsuite] update analyze-racy-logs.py to python3

Since python 2 is no longer supported on most distributions, update the
script to run under python while while still being runnable under
python2.

gdbsupport: remove attempt to define TARGET_WORD_SIZE

In the gdbsupport configure.ac file, there is an attempt to define
TARGET_WORD_SIZE.  This is done by running grep on the file
../bfd/bfd-in3.h.

The problem with this is, the file bfd-in3.h is generated into the bfd
build directory when bfd is configured, and there is no dependency
between the gdbsupport module and the bfd module, so, for example, if
I do:

  $ ../src/configure
  $ make all-gdbsupport

Then bfd will neither be configured, or built.  In this case
TARGET_WORD_SIZE ends up being defined, but with no value because the
grep on bfd-in3.h fails.

However, it turns out that this doesn't matter; we don't actually use
TARGET_WORD_SIZE anywhere.

My proposal in this commit is to just remove the definition of
TARGET_WORD_SIZE, the alternative would be to add a dependency between
configure-gdbsupport and configure-bfd into Makefile.def, but adding a
dependency for something we don't need seems pretty pointless.

sim: add --info-target for listing supported BFD targets

It can be difficult to guess the exact bfd name, so add an option to
list all the targets that the current build supports.  This aligns with
other simulator options like --info-architecture.

Automatic date update in version.in

gdb: Setting setter return a bool to tell if the value changed

GDB can notify observers when a parameter is changed.

To do that, do_set_command (in gdb/cli/cli-setshow.c) compares the new
value against the old one before updating it, and based on that notifies
observers.  This looks like something like:

    int valuechanged = 0;
    switch (cmd->var.type ())
    {
    case var_integer:
      {
        LONGEST new_val = parse_and_eval_long (arg)
        if (new_val != cmd->var.get<int> ())
        {
          cmd->var.get<int> (new_val);
          value_changes = 1;
        }
      }
    case var_uinteger:
    case var_zuinteger:
      {
        unsigned int val
          = parse_cli_var_uinteger (c->var->type (), &arg, true);
        if (c->var->get<unsigned int> () != val)
          {
            c->var->set<unsigned int> (val);
            option_changed = true;
          }
      }
    case...
      /* And so on for all possible var_types.  */
    }

This comparison is done for each possible var_type, which leads to
unnecessary logic duplication.

In this patch I propose to move all those checks in one place within the
setting setter method.  This limits the code duplication and simplifies
the do_set_command implementation.

This patch also changes slightly the way a value change is detected.
Instead of comparing the user provided value against the current value
of the setting, we compare the value of the setting before and after the
set operation.  This is meant to handle edge cases where trying to set
an unrecognized value would be equivalent to a noop (the actual value
remains unchanged).  Doing this requires that the original value needs
to be copied before the update, which can be non trivial for
std::string.

There should be no user visible change introduced by this commit.

Tested on x86_64 GNU/Linux.

[1] https://review.lttng.org/c/binutils-gdb/+/5831/41

Change-Id: If064b9cede3eb56275aacd2b286f74eceb1aed11

gdb: Have setter and getter callbacks for settings

The main motivation behind this improvement is to help the
implementation of a patch Simon Marchi is preparing to fix a bug when
MI or Python try to access parameters that are inferior dependent (see
PR/28085).

This commit extends the previous ones, which introduces the setting
object to represent a static variable whose value can be set or shown
with the appropriate commands.  This patch proposes that a setting can
either contain a pointer to a static variable holding a setting, or
pointers to a pair of setter and getter callback functions.

The callbacks functions can be used to retrieve or change the value with
custom logic.  This is useful when the source of truth for a given
setting is not contained in the variable pointed to by the setting
instance.

Given that the callback function call is hidden within the setting
abstraction introduced earlier, none of the sites accessing the setting
needs to be updated.  The registered getter or setter is used whatever
the way to access it is (through MI, Python, Guile, the "with" command
and the $_gdb_setting / $_gdb_setting_str convenience functions).

All the add_setshow_*_cmd are given a new overload that will accept the
pair of function pointers (set / get functions) instead of the pointer
to a global variable.

Tested on GNU/Linux x86_64 with no regression observed.

Change-Id: Ieb81fef57550632ff66e6aa85f637372a226be8c
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>

gdb: make string-like set show commands use std::string variable

String-like settings (var_string, var_filename, var_optional_filename,
var_string_noescape) currently take a pointer to a `char *` storage
variable (typically global) that holds the setting's value.  I'd like to
"mordernize" this by changing them to use an std::string for storage.

An obvious reason is that string operations on std::string are often
easier to write than with C strings.  And they avoid having to do any
manual memory management.

Another interesting reason is that, with `char *`, nullptr and an empty
string often both have the same meaning of "no value".  String settings
are initially nullptr (unless initialized otherwise).  But when doing
"set foo" (where `foo` is a string setting), the setting now points to
an empty string.  For example, solib_search_path is nullptr at startup,
but points to an empty string after doing "set solib-search-path".  This
leads to some code that needs to check for both to check for "no value".
Or some code that converts back and forth between NULL and "" when
getting or setting the value.  I find this very error-prone, because it
is very easy to forget one or the other.  With std::string, we at least
know that the variable is not "NULL".  There is only one way of
representing an empty string setting, that is with an empty string.

I was wondering whether the distinction between NULL and "" would be
important for some setting, but it doesn't seem so.  If that ever
happens, it would be more C++-y and self-descriptive to use
optional<string> anyway.

Actually, there's one spot where this distinction mattered, it's in
init_history, for the test gdb.base/gdbinit-history.exp.  init_history
sets the history filename to the default ".gdb_history" if it sees that
the setting was never set - if history_filename is nullptr.  If
history_filename is an empty string, it means the setting was explicitly
cleared, so it leaves it as-is.  With the change to std::string, this
distinction doesn't exist anymore.  This can be fixed by moving the code
that chooses a good default value for history_filename to
_initialize_top.  This is ran before -ex commands are processed, so an
-ex command can then clear that value if needed (what
gdb.base/gdbinit-history.exp tests).

Another small improvement, in my opinion is that we can now easily
give string parameters initial values, by simply initializing the global
variables, instead of xstrdup-ing it in the _initialize function.

In Python and Guile, when registering a string-like parameter, we
allocate (with new) an std::string that is owned by the param_smob (in
Guile) and the parmpy_object (in Python) objects.

This patch started by changing all relevant add_setshow_* commands to
take an `std::string *` instead of a `char **` and fixing everything
that failed to build.  That includes of course all string setting
variable and their uses.

string_option_def now uses an std::string also, because there's a
connection between options and settings (see
add_setshow_cmds_for_options).

The add_path function in source.c is really complex and twisted, I'd
rather not try to change it to work on an std::string right now.
Instead, I added an overload that copies the std:string to a `char *`
and back.  This means more copying, but this is not used in a hot path
at all, so I think it is acceptable.

Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93
Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>

gdb: Introduce setting construct within cmd_list_element

cmd_list_element can contain a pointer to data that can be set and / or
shown.  This is achieved with the void* VAR member which points to the
data that can be accessed, while the VAR_TYPE member (of type enum
var_types) indicates how to interpret the data pointed to.

With this pattern, the user of the cmd_list_element needs to know what
is the storage type associated with a given VAR_TYPES in order to do
the proper casting.  No automatic safeguard is available to prevent
miss-use of the pointer.  Client code typically looks something like:

switch (c->var_type)
{
  case var_zuinteger:
    unsigned int v = *(unsigned int*) c->var;
    ...
    break;
  case var_boolean:
    bool v = *(bool *) c->var;
    ...
    break;
  ...
}

This patch proposes to add an abstraction around the var_types and void*
pointer pair.  The abstraction is meant to prevent the user from having
to handle the cast and verify that the data is read or written as a type
that is coherent with the setting's var_type.  This is achieved by
introducing the struct setting which exposes a set of templated get /
set member functions.  The template parameter is the type of the
variable that holds the referred variable.

Using those accessors allows runtime checks to be inserted in order to
ensure that the data pointed to has the expected type.  For example,
instantiating the member functions with bool will yield something
similar to:

const bool &get<bool> () const
{
  gdb_assert (m_var_type == var_boolean);
  gdb_assert (m_var != nullptr);
  return *static_cast<bool *> (m_var);
}
void set<bool> (const bool &var)
{
  gdb_assert (m_var_type == var_boolean);
  gdb_assert (m_var != nullptr);
  *static_cast<bool *> (m_var) = var;
}

Using the new abstraction, our initial example becomes:

switch (c->var_type)
{
  case var_zuinteger:
    unsigned int v = c->var->get<unsigned int> ();
    ...
    break;
  case var_boolean:
    bool v = c->var->get<bool> ();
    ...
    break;
  ...
}

While the call site is still similar, the introduction of runtime checks
help ensure correct usage of the data.

In order to avoid turning the bulk of add_setshow_cmd_full into a
templated function, and following a suggestion from Pedro Alves, a
setting can be constructed from a pre validated type erased reference to
a variable.  This is what setting::erased_args is used for.

Introducing an opaque abstraction to describe a setting will also make
it possible to use callbacks to retrieve or set the value of the setting
on the fly instead of pointing to a static chunk of memory.  This will
be done added in a later commit.

Given that a cmd_list_element may or may not reference a setting, the
VAR and VAR_TYPES members of the struct are replaced with a
gdb::optional<setting> named VAR.

Few internal function signatures have been modified to take into account
this new abstraction:

-The functions value_from_setting, str_value_from_setting and
 get_setshow_command_value_string used to have a 'cmd_list_element *'
 parameter but only used it for the VAR and VAR_TYPE member. They now
 take a 'const setting &' parameter instead.
- Similarly, the 'void *' and a 'enum var_types' parameters of
  pascm_param_value and gdbpy_parameter_value have been replaced with a
  'const setting &' parameter.

No user visible change is expected after this patch.

Tested on GNU/Linux x86_64, with no regression noticed.

Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34

sim: filter out SIGSTKSZ [PR sim/28302]

We map target signals to host signals so we can propagate signals
between the host & simulated worlds.  That means we need to know
the symbolic names & values of all signals that might be sent.

The tools that generate that list use signal.h and include all
symbols that start with "SIG" so as to automatically include any
new symbols that the C library might add.  Unfortunately, this
also picks up "SIGSTKSZ" which is not actually a signal itself,
but a signal related setting -- it's the size of the stack when
a signal is handled.

By itself this doesn't super matter as we will never see a signal
with that same value (since the range of valid signals tend to be
way less than 1024, and the size of the default signal stack will
never be that small).  But with recent glibc changes that make this
into a dynamic value instead of a compile-time constant, some users
see build failures when building the sim.

As suggested by Adam Sampson, update our scripts to ignore this
symbol to simplify everything and avoid the build failure.

Bug: https://sourceware.org/PR28302

sim: ppc: fallback when ln is not available [PR sim/18864]

Not all systems have easy access to hard links or symlinks, so add
fallback logic to the run->psim build code to handle those.

Bug: https://sourceware.org/PR18864

gdb: Fix comment in riscv_scan_prologue

I found an inaccurate comment in riscv_scan_prologue.  This commit fixes
it.

gdb: Support the c.mv insn in the riscv prologue scanner.

While working on other problems, I encountered situations where GDB
fails to properly unwind the stack because some functions use the C.MV
instruction in the prologue.  The prologue scanner stops when it hits
this instruction assuming its job is done at this point.  Unfortunately
the prologue is not necessarily finished yet, preventing GDB to properly
unwind.

This commit adds support for handling such instruction in
riscv_scan_prologue.

Note that C.MV is part of the compressed instruction set.  The MV
counterpart from the base ISA is a pseudo instruction that expands to
'ADDI RD,RS1,0' which is already supported.

Tested on riscv64-linux-gnu.

All feedback are welcome.

Automatic date update in version.in

[gdb/symtab] Remove COMPUNIT_CALL_SITE_HTAB

Remove macro COMPUNIT_CALL_SITE_HTAB, and provide access to the htab using
member functions:
- compunit_symtab::find_call_site
- compunit_symtab::set_call_site_htab

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>

gdb/python: fix a few flake8 warnings

Fix these rather obvious warnings reported by flake8:

    ./lib/gdb/FrameIterator.py:16:1: F401 'gdb' imported but unused
    ./lib/gdb/FrameIterator.py:17:1: F401 'itertools' imported but unused
    ./lib/gdb/command/prompt.py:55:26: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
    ./lib/gdb/command/explore.py:526:9: F841 local variable 'has_explorable_fields' is assigned to but never used
    ./lib/gdb/command/explore.py:697:56: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
    ./lib/gdb/command/explore.py:736:62: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
    ./lib/gdb/command/explore.py:767:61: E712 comparison to False should be 'if cond is False:' or 'if not cond:'
    ./lib/gdb/command/frame_filters.py:21:1: F401 'copy' imported but unused
    ./lib/gdb/command/frame_filters.py:22:1: F401 'gdb.FrameIterator.FrameIterator' imported but unused
    ./lib/gdb/command/frame_filters.py:23:1: F401 'gdb.FrameDecorator.FrameDecorator' imported but unused
    ./lib/gdb/command/frame_filters.py:25:1: F401 'itertools' imported but unused
    ./lib/gdb/command/frame_filters.py:179:17: E712 comparison to True should be 'if cond is True:' or 'if cond:'

Change-Id: I4f49c0cb430359ee872222600c61d9c5283b09ab

Automatic date update in version.in

Fix build failure for 32-bit targets

When building master GDB, I ran into the following:

binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)':
binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=]
   snprintf (buf, sizeof (buf), "0x%lx ", pc);

Fix this by using %PRIxPTR as opposed to %lx.

Fix mistake in RX assembler documentation (special section names)

[gdb/symtab] Fix htab_find_slot call in read_call_site_scope

In read_call_site_scope we have:
...
  call_site_local.pc = pc;
  slot = htab_find_slot (cu->call_site_htab, &call_site_local, INSERT);
...

The call passes a call_site pointer as element.  OTOH, the hashtab is created
using hash_f == core_addr_hash and eq_f == core_addr_eq, so the element
will be accessed through a CORE_ADDR pointer.

This is not wrong (at least in C), given that pc is the first field in
call_site.

Nevertheless, as in call_site_for_pc, make the htab_find_slot call match the
used hash_f and eq_f by using &pc instead:
...
  slot = htab_find_slot (cu->call_site_htab, &pc, INSERT);
...

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>

PATCH bfd: Fix linker warning for recently introduced arm attributes

2021-09-27  Andrea Corallo  <andrea.corallo@arm.com>

* elf-bfd.h (NUM_KNOWN_OBJ_ATTRIBUTES): Update value to cover
'Tag_BTI_use' and 'Tag_PACRET_use'.

gdb/testsuite/dwarf: use options for rnglists/loclists procs

Change how rnglists and loclists procs to align them with how procs for
aranges (and other things in the DWARF assembler) work.  Instead of
using "args" (variable number of parameters in TCL) and command-line
style option arguments, use one leading "option" parameters, used as a
kind of key/value dictionary of options parsed using `parse_options`.

Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a

gdb/testsuite/dwarf: don't define nested procs for rnglists/loclists

When I wrote support for rnglists and loclists in the testsuite's DWARF
assembler, I made it with nested procs, for example proc "table" inside
proc "rnglists".  The intention was that this proc "table" could only be
used by the user while inside proc "rnglists"'s body.  I had chosen very
simple names, thinking there was no chance of name clashes.  I recently
learned that this is not how TCL works.  This ends up defining a proc
"table" in the current namespace ("Dwarf" in this case).

Things still work if you generate rnglists and loclists in the same
file, as each redefines its own procedures when executing.  But if a
user of the assembler happened to define a convenience "table" or
"start_end" procedure, for example, it would get overriden.

I'd like to change how this works to reduce the chances of a name clash.

 - Move the procs out of each other, so they are not defined in a nested
   fashion.
 - Prefix them with "_rnglists_" or "_loclists_".
 - While calling $body in the various procs, temporarily make the procs
   available under their "short" name.  For example, while in rngllists'
   body, make _rnglists_table available as just "table".  This allows
   existing code to keep working and keeps it not too verbose.
 - Modify with_override to allow the overriden proc to not exist.  In
   that case, the temporary proc is deleted on exit.

Note the non-conforming indentation when calling with_override in
_loclists_list.  This is on purpose: as we implement more loclists (and
rnglists) entry types, the indentation would otherwise get larger and
larger without much value for readability.  So I think it's reasonable
here to put them on the same level.

Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328

gdb: remove TYPE_FIELD_NAME and FIELD_NAME macros

Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.

Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6

gdb: add field::name / field::set_name

Add the `name` and `set_name` methods on `struct field`, in order to
remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros.  In this patch, the
macros are changed to use `field::name`, so all the call sites that are
used to set the field's name are changed to use `field::set_name`.
The next patch will remove the macros completely.

Note that because of the name clash between the existing field named
`name` and the new method, I renamed the field `m_name`.  It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).

Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896

Automatic date update in version.in

[PR gdb/28369] Use get_shell on gdb/ser-pipe.c

PR gdb/28369 reports that gdb/ser-pipe.c has an 'execl' function call
with a hard-coded "/bin/sh" as its argument.  We've had 'get_shell'
for a while now, which is conscious about the SHELL environment and a
better alternative to always calling "/bin/sh".

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28369

[gdb/testsuite] Add untested for missing xml support in gdb.base/valgrind*.exp

Add untested in case missing xml support is detected in test-cases
gdb.base/valgrind*.exp.

Tested on x86_64-linux.

arm: enable Cortex-R52+ CPU

Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
flag for -mcpu option.

bfd/

* cpu-arm.c: New Cortex-R52+ CPU.

gas/

* NEWS: Update docs.
* config/tc-arm.c: New Cortex-R52+ CPU.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/cpu-cortex-r52plus.d: New test.

aarch64: Enable Cortex-X2 CPU

This patch is adding support for Cortex-X2 CPU.

gas:

* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-X2.
* doc/c-aarch64.texi: Update docs.

aarch64: Enable Cortex-A710 CPU

This patch is adding support for Cortex-A710 CPU.

gas/

        * NEWS: Update docs.
        * config/tc-aarch64.c: Add Cortex-A710.
        * doc/c-aarch64.texi: Update docs.

aarch64: Enable Cortex-A510 CPU

This patch is adding support for Cortex-A510 CPU.

gas/

* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A510.
* doc/c-aarch64.texi: Update docs.

aarch64: Update AArch64 features command line options docs 2/2

Patch is only sorting by 'Extension` column 'Architecture Extension'
table.

gas/

* doc/c-aarch64.texi: Update docs.

aarch64: Update AArch64 features command line options docs 1/2

Patch is improving entries in "Architecture extensions" table in GAS
documentation.

gas/

* doc/c-aarch64.texi: Update docs.

aarch64: add armv9-a architecture to -march

Patch is adding new 'armv9-a` command line flag to -march for AArch64.

gas/

* config/tc-aarch64.c: Add 'armv9-a' command line flag.
* docs/c-aarch64.text: Update docs.
* NEWS: Update docs.

include/

* opcode/aarch64.h (AARCH64_FEATURE_V9): New define.
(AARCH64_ARCH_V9): New define.

gdb/testsuite: make runto_main not pass no-message to runto

As follow-up to this discussion:

  https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html

... make runto_main not pass no-message to runto.  This means that if we
fail to run to main, for some reason, we'll emit a FAIL.  This is the
behavior we want the majority of (if not all) the time.

Without this, we rely on tests logging a failure if runto_main fails,
otherwise.  They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested".  The messages also vary widly.
This patch removes all these messages as well.

Also, remove a few "fail" where we call runto (and not runto_main).  by
default (without an explicit no-message argument), runto prints a
failure already.  In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to).  This aligns their
behavior with the rest of the testsuite.

Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023

gdbsupport: make gdb_mkostemp_cloexec return a scoped_fd

This encourages the callers to use automatic file descriptor management.

Change-Id: I137a81df6f3607b457e28c35aafde8ed6f3a3344

gdbsupport: make gdb_open_cloexec return scoped_fd

Make gdb_open_cloexec return a scoped_fd, to encourage using automatic
management of the file descriptor closing.  Except in the most trivial
cases, I changed the callers to just release the fd, which retains their
existing behavior.  That will allow the transition to using scoped_fd
more to go gradually, one caller at a time.

Change-Id: Ife022b403f96e71d5ebb4f1056ef6251b30fe554

gdbsupport: move gdb_file_up to its own file

The following patches wants to change gdb_fopen_cloexec and
gdb_mkostemp_cloexec to return a scoped_fd.  Doing this causes a cyclic
include between scoped_fd.h and filestuff.h, that both want to include
each other.  scoped_fd.h includes filestuff.h because of the
scoped_fd::to_file method's return value.  filestuff.h would then
include scoped_fd.h for gdb_fopen_cloexec's and gdb_mkostemp_cloexec's
return values.

To fix that, move gdb_file_up to its own file, gdb_file.h.

Change-Id: Ic82a48914b2aacee8f14af535b7469245f88b93d

ld: pru: Fix resource_table output section alignment

My commit 261980de18b added alignment for the resource table symbol.
But it is wrong.  The Linux remoteproc driver loads and interprets the
contents of the .resource_table ELF section, not of a table symbol.

Without this patch, if the linker happens to output padding for symbol
alignment, then the resource table contents as viewed by the kernel
loader would "shift" and look corrupted.

ld/ChangeLog:

* scripttempl/pru.sc  (.resource_table): Align the output
section, not the first symbol.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

Fix Windows crash from stop_pc change

The "make thread_suspend_state::stop_pc optional" patch caused a
regression on Windows when using shared libraries.  I tracked this
down to an unguarded use of stop_pc() in the TARGET_WAITKIND_LOADED
case of handle_inferior_event.  This patch fixes the bug by ensuring
that the stop PC is set at this point.

[gdb/testsuite] Use untested in gdb.debuginfod/fetch_src_and_symbols.exp

With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
board unix/-bad, I get:
...
gcc: error: unrecognized command line option '-bad'^M
compiler exited with status 1
gdb compile failed, gcc: error: unrecognized command line option '-bad'
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile
...

Replace the FAIL with the usual:
...
UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile
...

Tested on x86_64-linux.

[gdb/testsuite] Remove redundant FAIL in gdb.base/info-os.exp

When running test-case gdb.base/info-os.exp with target board unix/-bad, I run
into:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/info-os.exp: failed to prepare
FAIL: gdb.base/info-os.exp: cannot compile test program
...

Remove the redundant FAIL.

Tested on x86_64-linux.

[gdb/testsuite] Fix DUPLICATE in gdb.base/info-os.exp

When running test-case gdb.base/info-os.exp, I run into:
...
PASS: gdb.base/info-os.exp: get threads
PASS: gdb.base/info-os.exp: get threads
DUPLICATE: gdb.base/info-os.exp: get threads
...

Fix this not doing pass followed by exp_continue in gdb_test_multiple.

Tested on x86_64-linux.

[gdb/testsuite] Check compilation result in gdb.dwarf2/dw2-opt-structptr.exp

When running test-case gdb.dwarf2/dw2-opt-structptr.exp with target board
unix/-bad, I get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: dw2-opt-structptr.exp
UNTESTED: gdb.dwarf2/dw2-opt-structptr.exp: failed to compile
ERROR: (dw2-opt-structptr) No such file or directory
UNRESOLVED: gdb.dwarf2/dw2-opt-structptr.exp: console: set print object on
...

Merge the two UNTESTEDs.

Fix the UNRESOLVED by checking result of compilation.

Tested on x86_64-linux.

[gdb/testsuite] Check compilation result in gdb.base/structs.exp

When running test-case gdb.base/structs.exp with target board unix/-bad, I
get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/structs.exp: failed to prepare
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/structs.exp.
ERROR: can't read "use_gdb_stub": no such variable
...

Fix this by checking the compilation result.

Fix the resulting DUPLICATEs using with_test_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Prepare nodebug exec in gdb.base/cvexpr.exp

When running test-case gdb.base/cvexpr.exp with target board unix/-bad, I get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/cvexpr.exp.
ERROR: can't read "use_gdb_stub": no such variable
...

This is triggered in a part of the test that claims to require no debug
information, but uses the exec containing either dwarf or ctf.

Fix this by preparing another executable compiled with nodebug, and using
that one instead.

Also use with_test_prefix to mark the nodebug part, such that we have:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/cvexpr.exp: dwarf: failed to prepare
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/cvexpr.exp: nodebug: failed to prepare
...

Tested on x86_64-linux.

[gdb/testsuite] Fix DUPLICATE in gdb.base/cvexpr.exp

Fix:
...
DUPLICATE: gdb.base/cvexpr.exp: ptype int * restrict
...
using with_test_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Check compilation result in gdb.base/call-sc.exp

When running test-case gdb.base/call-sc.exp with target board unix/-bad, I
get:
...
gdb compile failed, gcc: error: unrecognized command line option '-bad'
UNTESTED: gdb.base/call-sc.exp: failed to prepare
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/call-sc.exp.
ERROR: can't read "use_gdb_stub": no such variable
...

Fix this by checking the compilation result.

Fix the resulting DUPLICATE:
...
DUPLICATE: gdb.base/call-sc.exp: failed to prepare
...
using with_test_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Fix untested messages in gdb.mi/*.exp

The effect of:
...
untested "y.exp"
...
in a gdb.x/y.exp is:
...
UNTESTED: gdb.x/y.exp: y.exp
...
which is a bit pointless.

Replace these untested messages in gdb.mi/*.exp with the usual "failed to
compile".

Likewise for an:
...
untested $testname
...
where the variable is undefined.

Tested on x86_64-linux.

make objcopy fail if it is asked to redefine symbols in an object file containing LTO information.

* objcopy.c (filter_symbols): Fail if attempting to dredefine
symbols in an LTO object file.

[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp

On ubuntu 18.04.5, I run into:
...
(gdb) mt print objfiles dwindex^M
^M
Object file build/gdb/testsuite/outputs/gdb.rust/dwindex/dwindex:  \
  Objfile at 0x55dab0b87a50, bfd at 0x55dab0b0cfa0, 1095 minsyms^M
^M
Psymtabs:^M
vendor/compiler_builtins/src/int/specialized_div_rem/mod.rs at 0x55dab0db0720^M
  ...
library/std/src/sys/unix/stdio.rs at 0x55dab0d96320^M
ERROR: internal buffer is full.
UNRESOLVED: gdb.rust/dwindex.exp: check if index present
...

Fix this by using -lbl in proc ensure_gdb_index.

Tested on x86_64-linux.

Add Solaris specific ELF note processing

Add elfcore_grok_solaris_note function that enables to
obtain process status, register values, and program info
from Solaris's core files.

bfd/
* elf.c (elfcore_grok_solaris_note): Solaris specific ELF
note parser. Better GDB's coredump analysis on Solaris...
(elfcore_grok_solaris_note_impl): New function.
(elfcore_grok_solaris_prstatus): New function.
(elfcore_grok_solaris_info): New function.
(elfcore_grok_solaris_lwpstatus): New function.
(elf_parse_notes): Added "CORE" groker element.
include/
* elf/common.h: Add note segment constants for core files on
Solaris systems.

Add support to readelf for reading OpenBSD ELF core notes.

* readelf.c (get_openbsd_elfcore_note_type): New function.
(process_note): Add support for OpenBSD core notes.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/break-interp.exp for ld.so without debug

When running test-case gdb.base/break-interp.exp on openSUSE Leap 42.3, I get:
...
(gdb) info addr dl_main^M
Symbol "dl_main" is at 0x1750 in a file compiled without debugging.^M
(gdb) FAIL: gdb.base/break-interp.exp: info addr dl_main
...
while the regexp expects "Symbol \"dl_main\" is a function at address $hex\\."

Fix this by also accepting this variant.

Tested on x86_64-linux.

Add a testcase for PR binutils/27202

PR binutils/27202
* testsuite/gas/elf/dwarf-5-loc0.d: New file.
* testsuite/gas/elf/dwarf-5-loc0.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-5-loc0.

Fix gdb.multi/multi-term-settings.exp race

The gdb.multi/multi-term-settings.exp testcase sometimes fails like so:

 Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.multi/multi-term-settings.exp ...
 FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)

It's easier to reproduce if you stress the machine at the same time, like e.g.:

  $ stress -c 24

Looking at gdb.log, we see:

 (gdb) attach 60422
 Attaching to program: build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings, process 60422
 [New Thread 60422.60422]
 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
 Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so...
 Reading symbols from /lib64/ld-linux-x86-64.so.2...
 (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
 0x00007f2fc2485334 in __GI___clock_nanosleep (clock_id=<optimized out>, clock_id@entry <mailto:clock_id@entry>=0, flags=flags@entry <mailto:flags@entry>=0, req=req@entry <mailto:req@entry>=0x7ffe23126940, rem=rem@entry <mailto:rem@entry>=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
 78 ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: inf2: attach
 set schedule-multiple on
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: set schedule-multiple on
 info inferiors
   Num  Description       Connection                         Executable
   1    process 60404     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
 * 2    process 60422     1 (extended-remote localhost:2349) build/gdb/testsuite/outputs/gdb.multi/multi-term-settings/multi-term-settings
 (gdb) PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: info inferiors
 pid=60422, count=46
 pid=60422, count=47
 pid=60422, count=48
 pid=60422, count=49
 pid=60422, count=50
 pid=60422, count=51
 pid=60422, count=52
 pid=60422, count=53
 pid=60422, count=54
 pid=60422, count=55
 pid=60422, count=56
 pid=60422, count=57
 pid=60422, count=58
 pid=60422, count=59
 pid=60422, count=60
 pid=60422, count=61
 pid=60422, count=62
 pid=60422, count=63
 pid=60422, count=64
 pid=60422, count=65
 pid=60422, count=66
 pid=60422, count=67
 pid=60422, count=68
 pid=60422, count=69
 pid=60404, count=54
 pid=60404, count=55
 pid=60404, count=56
 pid=60404, count=57
 pid=60404, count=58
 PASS: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: continue
 Quit
 (gdb) FAIL: gdb.multi/multi-term-settings.exp: inf1_how=attach: inf2_how=attach: stop with control-c (SIGINT)

If you look at the testcase's sources, you'll see that the intention
is to resumes the program with "continue", wait to see a few of those
"pid=..., count=..." lines, and then interrupt the program with
Ctrl-C.  But somehow, that resulted in GDB printing "Quit", instead of
the Ctrl-C stopping the program with SIGINT.

Here's what is happening:

 #1 - those "pid=..., count=..." lines we see above weren't actually
      output by the inferior after it has been continued (see #1).
      Note that "inf1_how" and "inf2_how" are "attach".  What happened
      is that those "pid=..., count=..." lines were output by the
      inferiors _before_ they were attached to.  We see them at that
      point instead of earlier, because that's where the testcase
      reads from the inferiors' spawn_ids.

 #2 - The testcase mistakenly thinks those "pid=..., count=..." lines
      happened after the continue was processed by GDB, meaning it has
      waited enough, and so sends the Ctrl-C.  GDB hasn't yet passed
      the terminal to the inferior, so the Ctrl-C results in that
      Quit.

The fix here is twofold:

 #1 - flush inferior output right after attaching

 #2 - consume the "Continuing" printed by "continue", indicating the
      inferior has the terminal.  This is the same as done throughout
      the testsuite to handle this exact problem of sending Ctrl-C too
      soon.

gdb/testsuite/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net <mailto:pedro@palves.net>>

* gdb.multi/multi-term-settings.exp (create_inferior): Flush
inferior output.
(coretest): Use $gdb_test_name.  After issuing "continue", wait
for "Continuing".

Change-Id: Iba7671dfe1eee6b98d29cfdb05a1b9aa2f9defb9

[gdb/testsuite] Disable vgdb tests if xml not supported

I build gdb without xml support using --without-expat, and ran into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=22032^M
relaying data between gdb and process 22032^M
warning: Can not parse XML target description; XML support was disabled at \
  compile time^M
  ...
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #1
p gdb_test_infcall ()^M
Remote 'g' packet reply is too long (expected 560 bytes, got 800 bytes): ...^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
...

After googling the error message with context valgrind gdbserver, I found
indications that the Remote 'g' packet reply error is due to missing xml
support.

And here ( https://www.valgrind.org/docs/manual/manual-core-adv.html ) I
found:
...
GDB version needed for ARM and PPC32/64.

You must use a GDB version which is able to read XML target description sent
by a gdbserver.  This is the standard setup if GDB was configured and built
with the "expat" library.  If your GDB was not configured with XML support, it
will report an error message when using the "target" command.  Debugging will
not work because GDB will then not be able to fetch the registers from the
Valgrind gdbserver.
...

So I guess I'm running into the same problem for x86_64.

Fix this by skipping all gdb.base/valgrind-*.exp tests if xml support is not
available.  Although only the gdb.base/valgrind-infcall*.exp produce fails,
the Remote 'g' packet reply error occurs in all tests, so it seems prudent to
disable them all.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/py-breakpoint.exp with python 2

With a gdb build using python 2.7, I run into:
...
(gdb) python \
  gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
  File "<string>", line 1^M
    gdb.events.breakpoint_modified.connect(lambda bp: print(bp.enabled))^M
                                                          ^^M
SyntaxError: invalid syntax^M
Error while executing Python code.^M
(gdb) FAIL: gdb.python/py-breakpoint.exp: test_bkpt_auto_disable: \
  trap breakpoint_modified event
...

This is caused by the following:
- a lambda function body needs to be an expression
- in python 2, print is a statement, while in python 3 it's a function
- a function call is an expression, and a statement is not.

Fix this by defining a function print_bp_enabled:
...
def print_bp_enabled (bp):
    print (bp.enabled)
end
...
and using that instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix breakpoint detection in gdb.gdb/python-helper.exp

With a gdb configured to be somewhat minimal, while still supporting python:
...
$ gdb --configuration
This GDB was configured as follows:
   configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
             --with-auto-load-dir=$debugdir:$datadir/auto-load
             --with-auto-load-safe-path=$debugdir:$datadir/auto-load
             --without-expat
             --with-gdb-datadir=$install/share/gdb (relocatable)
             --with-jit-reader-dir=$install/lib64/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --with-python=/usr
             --with-python-libdir=/usr/lib
             --with-debuginfod
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/lib/debug
             --with-system-gdbinit=$devel/system-gdbinit
...
and using gcc 4.8 to build gdb (causing std::thread not to be used due to
PR28318) I ran into:
...
(gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb
print 1^M
^M
Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M
1174      scoped_value_mark free_values;^M
(xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout)
...

The problem is that the regexp expects "hit Breakpoint $decimal".  The "hit"
part is missing.

The "hit" is printed by maybe_print_thread_hit_breakpoint, when
show_thread_that_caused_stop returns true:
...
int
show_thread_that_caused_stop (void)
{
  return highest_thread_num > 1;
}
...
Apparently, that's not the case.

Fix this by removing "hit" from the regexp, making the regexp more similar to
what is used in say, continue_to_breakpoint.

Tested on x86_64-linux.

gdb: fix build when libbacktrace and execinfo backtrace are not available

In this commit:

  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
  Date:   Wed Aug 11 13:24:33 2021 +0100

      gdb: use libbacktrace to create a better backtrace for fatal signals

The build of GDB was broken iff, the execinfo backtrace API is not
available, and, libbacktrace is either disabled, or not usable.  In
this case you'll see build errors like this:

      CXX    bt-utils.o
    /home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()':
    /home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope
         gdb_internal_backtrace_1 ();
         ^~~~~~~~~~~~~~~~~~~~~~~~

This commit fixes the issue by guarding the call to
gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE',
which is only defined when one of the backtrace libraries are
available.

gdb/doc: use 'standard error stream' instead of 'stderr' in some places

With this commit:

  commit 91f2597bd24d171c1337a4629f8237aa47c59082
  Date:   Thu Aug 12 18:24:59 2021 +0100

      gdb: print backtrace for internal error/warning

I included some references to 'stderr', which, it was pointed out,
would be better written as 'standard error stream'.  See:

  https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html

This commit replaces the two instances of 'stderr' that I introduced.

gdb: fix manor -> manner typo in some comments

In a recent commit I used 'manor' in some comments rather than
'manner'.  This commit fixes those two mistakes.

I also looked through the gdb/ tree and found one additional instance
of this mistake that this commit also fixes.

PR27202, readelf -wL doesn't work on ".loc 0"

For DWARF revision 4 and earlier, display_debug_lines_decoded
populates the file_table array with entries read from .debug_line
after the directory table.  file_table[0] contains the first entry.
DWARF rev 4 line number programs index this entry as file number one.
DWARF revision 5 changes .debug_line format quite extensively, and in
particular gives file number zero a meaning.

PR 27202
* dwarf.c (display_debug_lines_decoded): Correct indexing used
for DWARF5 files.

gdb: enable target_async around stop_all_threads call in process_initial_stop_replies

The following scenario hangs:

 - maint set target-non-stop on
 - `gdbserver --attach`
 - a multi-threaded program

For example:

Terminal 1:

    $ gnome-calculator&
    [1] 495731
    $ ../gdbserver/gdbserver --once --attach :1234 495731
    Attached; pid = 495731
    Listening on port 1234

Terminal 2:

    $ ./gdb -nx -q --data-directory=data-directory /usr/bin/gnome-calculator -ex "maint set target-non-stop on" -ex "tar rem :1234"
    Reading symbols from /usr/bin/gnome-calculator...
    (No debugging symbols found in /usr/bin/gnome-calculator)
    Remote debugging using :1234
    * hangs *

What happens is:

 - The protocol between gdb and gdbserver is in non-stop mode, but the
   user-visible behavior is all-stop
 - On connect, gdbserver sends one stop reply for one thread that is
   stops, the others stay running
 - In process_initial_stop_replies, gdb calls stop_all_threads to stop
   these other threads, because we are using the all-stop user-visible
   mode
 - stop_all_threads sends a stop request for all the running threads and
   then waits for resulting events
 - At this point, the remote target is in target_async(0) mode, which
   makes stop_all_threads not consider it for events
 - stop_all_threads loops indefinitely (it does not even block
   indefinitely, it is in an infinite busy loop) because there are no
   event sources.  wait_one_event returns a TARGET_WAITKIND_NO_RESUMED
   wait status.

Fix that by making the remote target async around the stop_all_threads
call.

I haven't implemented it because I'm not sure how to do it, but I think
it would be a good idea to have, in stop_all_threads / wait_one /
handle_one, an assert to check that if we are expecting one or more
event, then there are some targets that are in a state where they can
supply some events.  Otherwise, we'll necessarily be stuck in this
infinite loop, and it's probably due to a bug in GDB.  I'm not too sure
where to put this or how to express it though.  Perhaps in
stop_all_threads, here:

  for (int i = 0; i < waits_needed; i++)
    {
      wait_one_event event = wait_one ();
      *here*
      if (handle_one (event))
break;
    }

If at that point, the returned event is TARGET_WAITKIND_NO_RESUMED,
there's a problem.  We expect some event, because we've asked some
threads to stop, but all targets are answering that they won't have any
events for us.  That's a contradiction, and a sign that something has
gone wrong.  It could perhaps event be:

    gdb_assert (event.ws.kind != TARGET_WAITKIND_NO_RESUMED);

in handle_one, as the idea is the same in prepare_for_detach.

A bit more sophisticated would be: we know which targets we are
expecting waits from, since we know which threads we have asked to
stop.  So if any of these targets returns TARGET_WAITKIND_NO_RESUMED,
something is fishy.

Add a test that tests attaching with gdbserver's --attach flag to a
multi-threaded program, and then connecting to it.  Without the fix, the
test reproduces the hang.

Change-Id: If6f6690a4887ca66693ef1af64791dda4c65f24f

Automatic date update in version.in

gdb: fix darwin-nat build (again)

I made a mistake in the previous patch.  Adjust the format string to
match the arguments.

Change-Id: I4d45e0e0adb78eb3b5a06ba1a5287155940056ba

gdb: fix darwin-nat build

There are two errors of this kind:

      CXX    darwin-nat.o
    /Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1175:19: error: format specifies type 'unsigned long' but the argument has type 'ULONGEST' (aka 'unsigned long long') [-Werror,-Wformat]
 ptid.pid (), ptid.tid ());
      ^~~~~~~~~~~

Fix them by using ptid_t's to_string method.

Change-Id: I52087d5f7ee0fc01ac8b3f87d4db0217cb0d7cc7

gdb.base/foll-fork.exp: accept "info breakpoints" output in any order

The test currently requires the "inf 1" breakpoint to be before the "inf
2" breakpoint.  This is not always the case:

    info breakpoints 2
    Num     Type           Disp Enb Address            What
    2       breakpoint     keep y   <MULTIPLE>
    2.1                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 2
    2.2                         y   0x0000555555554730 in callee at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:9 inf 1
    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info breakpoints

Since add_location_to_breakpoint uses only the address as a criterion to
sort locations, the order of locations at the same address is not
stable: it will depend on the insertion order.  Here, the insertion
order comes from the order of SALs when creating the breakpoint, which
can vary from machine to machine.  While it would be more user-friendly
to have a more stable order for printed breakpoint locations, it doesn't
really matter for this test, and it would be hard to define an order
that will be the same everywhere, all the time.

So, loosen the regexp to accept "inf 1" and "inf 2" in any order.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I5ada2e0c6ad0669e0d161bfb6b767229c0970d16

RISC-V: Fix wrong version number when arch contains 'p'.

When specify a default version for p extension in
riscv_supported_std_ext[](elfxx-riscv.c) and assembling with
-march=rv32imacp, the c extension's version in attribute will become
0p0, the expectation is 2p0.

TODO: Remember to add testcase when we have supported standrad p in
the future.

bfd/
PR gas/28372
* elfxx-riscv.c (riscv_parsing_subset_version): Break if p
represent the 'p' extension.

Change-Id: Ia4e0cf26f3d7d07acaee8cefd86707ecac663a59

RISC-V: Allow to add numbers in the prefixed extension names.

We need to allow adding numbers in the prefixed extension names, since
the zve<32,64><d,f,x> extensions are included in the forzen rvv v1.0 spec
recently.  But there are two restrictions as follows,

* The extension name ends with <number>p is invalid, since this may
be confused with extension with <number>.0 version.  We report errors
for this case.

Invalid format: [z|h|s|zvm|x][0-9a-z]+[0-9]+p

* The extension name ends with numbers is valid, but the numbers will
be parsed as major version, so try to avoid naming extensions like this.

bfd/
* elfxx-riscv.c (riscv_recognized_prefixed_ext): Renamed from
riscv_valid_prefixed_ext/
(riscv_parsing_subset_version): The extensions end with <number>p
is forbidden, we already report the detailed errors in the
riscv_parse_prefixed_ext, so clean the code and unused parameters.
(riscv_parse_std_ext): Updated.
(riscv_parse_prefixed_ext): Rewrite the parser to allow numbers
in the prefixed extension names.
gas/
* testsuite/gas/riscv/march-fail-invalid-x-01.d: New testcases.
* testsuite/gas/riscv/march-fail-invalid-x-02.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid-z-01.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid-z-02.d: Likewise.
* testsuite/gas/riscv/march-fail-invalid.l: Likewise.
* testsuite/gas/riscv/march-fail-version-x.d: Removed.
* testsuite/gas/riscv/march-fail-version-z.d: Likewise.
* testsuite/gas/riscv/march-fail-version.l: Likewise.

gdb: print backtrace for internal error/warning

This commit builds on previous work to allow GDB to print a backtrace
of itself when GDB encounters an internal-error or internal-warning.
This fixes PR gdb/26377.

There's not many places where we call internal_warning, and I guess in
most cases the user would probably continue their debug session.  And
so, in order to avoid cluttering up the output, by default, printing
of a backtrace is off for internal-warnings.

In contrast, printing of a backtrace is on by default for
internal-errors, as I figure that in most cases hitting an
internal-error is going to be the end of the debug session.

Whether a backtrace is printed or not can be controlled with the new
settings:

  maintenance set internal-error backtrace on|off
  maintenance show internal-error backtrace

  maintenance set internal-warning backtrace on|off
  maintenance show internal-warning backtrace

Here is an example of what an internal-error now looks like with the
backtrace included:

  (gdb) maintenance internal-error blah
  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  0x5c61ca gdb_internal_backtrace_1
   ../../src.dev-3/gdb/bt-utils.c:123
  0x5c626d _Z22gdb_internal_backtracev
   ../../src.dev-3/gdb/bt-utils.c:165
  0xe33237 internal_vproblem
   ../../src.dev-3/gdb/utils.c:393
  0xe33539 _Z15internal_verrorPKciS0_P13__va_list_tag
   ../../src.dev-3/gdb/utils.c:470
  0x1549652 _Z14internal_errorPKciS0_z
   ../../src.dev-3/gdbsupport/errors.cc:55
  0x9c7982 maintenance_internal_error
   ../../src.dev-3/gdb/maint.c:82
  0x636f57 do_simple_func
   ../../src.dev-3/gdb/cli/cli-decode.c:97
   .... snip, lots more backtrace lines ....
  ---------------------
  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n) y

  This is a bug, please report it.  For instructions, see:
  <https://www.gnu.org/software/gdb/bugs/>.

  ../../src.dev-3/gdb/maint.c:82: internal-error: blah
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Create a core file of GDB? (y or n) n

My hope is that this backtrace might make it slightly easier to
diagnose GDB issues if all that is provided is the console output, I
find that we frequently get reports of an assert being hit that is
located in pretty generic code (frame.c, value.c, etc) and it is not
always obvious how we might have arrived at the assert.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377

gdb: use libbacktrace to create a better backtrace for fatal signals

GDB recently gained the ability to print a backtrace when a fatal
signal is encountered.  This backtrace is produced using the backtrace
and backtrace_symbols_fd API available in glibc.

However, in order for this API to actually map addresses to symbol
names it is required that the application (GDB) be compiled with
-rdynamic, which GDB is not by default.

As a result, the backtrace produced often looks like this:

  Fatal signal: Bus error
  ----- Backtrace -----
  ./gdb/gdb[0x80ec00]
  ./gdb/gdb[0x80ed56]
  /lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0]
  /lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f]
  ./gdb/gdb[0x15495ba]
  ./gdb/gdb[0x15489b8]
  ./gdb/gdb[0x9b794d]
  ./gdb/gdb[0x9b7a6d]
  ./gdb/gdb[0x9b943b]
  ./gdb/gdb[0x9b94a1]
  ./gdb/gdb[0x4175dd]
  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3]
  ./gdb/gdb[0x4174de]
  ---------------------

This is OK if you have access to the exact same build of GDB, you can
manually map the addresses back to symbols, however, it is next to
useless if all you have is a backtrace copied into a bug report.

GCC uses libbacktrace for printing a backtrace when it encounters an
error.  In recent commits I added this library into the binutils-gdb
repository, and in this commit I allow this library to be used by
GDB.  Now (when GDB is compiled with debug information) the backtrace
looks like this:

  ----- Backtrace -----
  0x80ee08 gdb_internal_backtrace
   ../../src/gdb/event-top.c:989
  0x80ef0b handle_fatal_signal
   ../../src/gdb/event-top.c:1036
  0x7f24539dd6af ???
  0x7f2453a97a5f ???
  0x154976f gdb_wait_for_event
   ../../src/gdbsupport/event-loop.cc:613
  0x1548b6d _Z16gdb_do_one_eventv
   ../../src/gdbsupport/event-loop.cc:237
  0x9b7b02 start_event_loop
   ../../src/gdb/main.c:421
  0x9b7c22 captured_command_loop
   ../../src/gdb/main.c:481
  0x9b95f0 captured_main
   ../../src/gdb/main.c:1353
  0x9b9656 _Z8gdb_mainP18captured_main_args
   ../../src/gdb/main.c:1368
  0x4175ec main
   ../../src/gdb/gdb.c:32
  ---------------------

Which seems much more useful.

Use of libbacktrace is optional.  If GDB is configured with
--disable-libbacktrace then the libbacktrace directory will not be
built, and GDB will not try to use this library.  In this case GDB
would try to use the old backtrace and backtrace_symbols_fd API.

All of the functions related to writing the backtrace of GDB itself
have been moved into the new files gdb/by-utils.{c,h}.

src-release.sh: add libbacktrace to GDB_SUPPORT_DIRS

After the previous commit that imported libbacktrace from gcc, this
commit updates src-release.sh so that the libbacktrace directory is
included in the gdb release tar file.

ChangeLog:

* src-release.sh (GDB_SUPPPORT_DIRS): Add libbacktrace.

Copy in libbacktrace from gcc

This copies in libbacktrace from the gcc repository as it was in the
commit 62e420293a293608f383d9b9c7f2debd666e9fc9.  GDB is going to
start using this library soon.

A dependency between GDB and libbacktrace has already been added to
the top level Makefile, so, after this commit, when building GDB,
libbacktrace will be built first.  However, libbacktrace is not yet
linked into GDB, or used by GDB in any way.

It is possible to stop libbacktrace being built by configuring the
tree with --disable-libbacktrace.

This commit does NOT update src-release.sh, that will be done in the
next commit, this commit ONLY imports libbacktrace from gcc.  This
means that if you try to make a release of GDB from exactly this
commit then the release tar file will not include libbacktrace.
However, as libbacktrace is an optional dependency this is fine.

gdb: Add a dependency between gdb and libbacktrace

GDB is going to start using libbacktrace, so add a build dependency.

ChangeLog:

* Makefile.def: Add all-gdb dependency on all-libbacktrace.
* Makefile.in: Regenerate.

top-level configure: setup target_configdirs based on repository

The top-level configure script is shared between the gcc repository
and the binutils-gdb repository.

The target_configdirs variable in the configure.ac script, defines
sub-directories that contain components that should be built for the
target using the target tools.

Some components, e.g. zlib, are built as both host and target
libraries.

This causes problems for binutils-gdb.  If we run 'make all' in the
binutils-gdb repository we end up trying to build a target version of
the zlib library, which requires the target compiler be available.
Often the target compiler isn't immediately available, and so the
build fails.

The problem with zlib impacted a previous attempt to synchronise the
top-level configure scripts from gcc to binutils-gdb, see this thread:

  https://sourceware.org/pipermail/binutils/2019-May/107094.html

And I'm in the process of importing libbacktrace in to binutils-gdb,
which is also a host and target library, and triggers the same issues.

I believe that for binutils-gdb, at least at the moment, there are no
target libraries that we need to build.

In the configure script we build three lists of things we want to
build, $configdirs, $build_configdirs, and $target_configdirs, we also
build two lists of things we don't want to build, $skipdirs and
$noconfigdirs.  We then remove anything that is in the lists of things
not to build, from the list of things that should be built.

My proposal is to add everything in target_configdirs into skipdirs,
if the source tree doesn't contain a gcc/ sub-directory.  The result
is that for binutils-gdb no target tools or libraries will be built,
while for the gcc repository, nothing should change.

If a user builds a unified source tree, then the target tools and
libraries should still be built as the gcc/ directory will be present.

I've tested a build of gcc on x86-64, and the same set of target
libraries still seem to get built.  On binutils-gdb this change
resolves the issues with 'make all'.

ChangeLog:

* configure: Regenerate.
* configure.ac (skipdirs): Add the contents of target_configdirs if
we are not building gcc.

PR28391, strip/objcopy --preserve-dates *.a: cannot set time

After commit 985e0264516 copy_archive function began to pass invalid
values to the utimensat(2) function when it tries to preserve
timestamps in ar archives.  This happens because the bfd_stat_arch_elt
implementation for ar archives fills only the st_mtim.tv_sec part of
the st_mtim timespec structure, but leaves the st_mtim.tv_nsec part
and the whole st_atim timespec untouched leaving them uninitialized

PR 28391
* ar.c (extract_file): Clear buf for preserve_dates.
* objcopy.c (copy_archive): Likewise.

sim: drop weak func attrs on module inits

When I first wrote this, I was thinking we'd scan all source files
that existed and generate a complete init list.  That means for any
particular build, we'd probably have a few functions that didn't
exist, so weak attributes was necessary.  What I ended up scanning
though was only the source files that went into a particular build.

There was another concern too: a source file might be included, but
the build settings would cause all of its contents to be skipped
(via CPP defines).  So scanning via naive grep would pick up names
not actually available.  A check of the source tree shows that we
never do this, and it's pretty easy to institute a policy that we
don't start (by at the very least including a stub init func).

The use of weak symbols ends up causing a problem in practice: for
a few modules (like profiling), nothing else pulls it in, so the
linker omits it entirely, which leads to the profiling module never
being available.  So drop the weak markings since we know all these
funcs will be available.