gdb: add program_space parameters to some functions in symtab.c

Add some program_space parameters to functions related to getting and
setting the main name, making the references to current_program_space
bubble up a bit.  find_main_name calls ada_main_name, which implicitly
relies on the current program space, so I didn't add a parameter to that
function.

Change-Id: I9996955e8ae56832bbd461964d978e700e6feaf4
Approved-By: Tom Tromey <tom@tromey.com>

gdb: add program_space parameter to ada_clear_symbol_cache

Make the references to current_program_space bubble up one level.

Change-Id: I82acab5628c30f6535d52aa32ce2c1d0375cbeed
Approved-By: Tom Tromey <tom@tromey.com>

gdb: fix auxv cache clearing from new_objfile observer

It was pointed out on the mailing list that a recently added
test (gdb.python/py-progspace-events.exp) was failing when run with
the native-extended-gdbserver board.  This test was added with this
commit:

  commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
  Date:   Tue Sep 19 11:45:36 2023 +0100

      gdb: add Python events for program space addition and removal

It turns out though that the test is failing due to a existing bug
in GDB, the new test just exposes the problem.  Additionally, the
failure really doesn't even rely on the new functionality added in the
above commit.  I reduced the test to a simple set of steps that
reproduced the failure and tested against GDB 13, and the test passes;
so the bug was introduced since then.  In fact, the bug was introduced
with this commit:

  commit a2827364e2bf19910fa5a54364a594a5ba3033b8
  Date:   Fri Sep 8 15:48:16 2023 +0100

      gdb: remove final user of the executable_changed observer

This commit changed how the per-inferior auxv data cache is managed,
specifically, when the cache is cleared, and it is this that leads to
the failure.

This bug is interesting because it exposes a number of issues with
GDB, I'll explain all of the problems I see, though ultimately, I only
propose fixing one problem in this commit, which is enough to resolve
the crash we are currently seeing.

The crash that we are seeing manifests like this:

  ...
  [Inferior 2 (process 3970384) exited normally]
  +inferior 1
  [Switching to inferior 1 [process 3970383] (/tmp/build/gdb/testsuite/outputs/gdb.python/py-progspace-events/py-progspace-events)]
  [Switching to thread 1.1 (Thread 3970383.3970383)]
  #0  breakpt () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.python/py-progspace-events.c:28
  28 { /* Nothing.  */ }
  (gdb) step
  +step
  terminate called after throwing an instance of 'gdb_exception_error'

  Fatal signal: Aborted
  ... etc ...

What's happening is that GDB attempts to refill the auxv cache as a
result of the gdbarch_has_shared_address_space call in
program_space::~program_space, the backtrace looks like this:

  #0  0x00007fb4f419a9a5 in raise () from /lib64/libpthread.so.0
  #1  0x00000000008b635d in handle_fatal_signal (sig=6) at ../../src/gdb/event-top.c:912
  #2  <signal handler called>
  #3  0x00007fb4f38e3625 in raise () from /lib64/libc.so.6
  #4  0x00007fb4f38cc8d9 in abort () from /lib64/libc.so.6
  #5  0x00007fb4f3c70756 in __gnu_cxx::__verbose_terminate_handler() [clone .cold] () from /lib64/libstdc++.so.6
  #6  0x00007fb4f3c7c6dc in __cxxabiv1::__terminate(void (*)()) () from /lib64/libstdc++.so.6
  #7  0x00007fb4f3c7b6e9 in __cxa_call_terminate () from /lib64/libstdc++.so.6
  #8  0x00007fb4f3c7c094 in __gxx_personality_v0 () from /lib64/libstdc++.so.6
  #9  0x00007fb4f3a80c63 in _Unwind_RaiseException_Phase2 () from /lib64/libgcc_s.so.1
  #10 0x00007fb4f3a8154e in _Unwind_Resume () from /lib64/libgcc_s.so.1
  #11 0x0000000000e8832d in target_read_alloc_1<unsigned char> (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2266
  #12 0x0000000000e73dea in target_read_alloc (ops=0x408a3a0, object=TARGET_OBJECT_AUXV, annex=0x0) at ../../src/gdb/target.c:2315
  #13 0x000000000058248c in target_read_auxv_raw (ops=0x408a3a0) at ../../src/gdb/auxv.c:379
  #14 0x000000000058243d in target_read_auxv () at ../../src/gdb/auxv.c:368
  #15 0x000000000058255c in target_auxv_search (match=0x0, valp=0x7ffdee17c598) at ../../src/gdb/auxv.c:415
  #16 0x0000000000a464bb in linux_is_uclinux () at ../../src/gdb/linux-tdep.c:433
  #17 0x0000000000a464f6 in linux_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/linux-tdep.c:440
  #18 0x0000000000510eae in gdbarch_has_shared_address_space (gdbarch=0x409a2d0) at ../../src/gdb/gdbarch.c:4889
  #19 0x0000000000bc7558 in program_space::~program_space (this=0x4544aa0, __in_chrg=<optimized out>) at ../../src/gdb/progspace.c:124
  #20 0x00000000009b245d in delete_inferior (inf=0x47b3de0) at ../../src/gdb/inferior.c:290
  #21 0x00000000009b2c10 in prune_inferiors () at ../../src/gdb/inferior.c:480
  #22 0x00000000009c5e3e in fetch_inferior_event () at ../../src/gdb/infrun.c:4558
  #23 0x000000000099b4dc in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
  #24 0x0000000000cbc64f in remote_async_serial_handler (scb=0x4090a30, context=0x408a6b0) at ../../src/gdb/remote.c:14859
  #25 0x0000000000d83d3a in run_async_handler_and_reschedule (scb=0x4090a30) at ../../src/gdb/ser-base.c:138
  #26 0x0000000000d83e1f in fd_event (error=0, context=0x4090a30) at ../../src/gdb/ser-base.c:189

So this is problem #1, if we throw an exception while deleting a
program_space then this is not caught, and is going to crash GDB.

Problem #2 becomes evident when we ask why GDB is throwing an error in
this case; the error is thrown because the remote target, operating in
non-async mode, can't read the auxv data while an inferior is running
and GDB is waiting for a stop reply.  The problem here then, is why
does GDB get into a position where it tries to interact with the
remote target in this way, at this time?  The problem is caused by the
prune_inferiors call which can be seen in the above backtrace.

In prune_inferiors we check if the inferior is deletable, and if it
is, we delete it.  The problem is, I think, we should also check if
the target is currently in a state that would allow us to delete the
inferior.  We don't currently have such a check available, we'd need
to add one, but for the remote target, this would return false if the
remote is in async mode and the remote is currently waiting for a stop
reply.  With this change in place GDB would defer deleting the
inferior until the remote target has stopped, at which point GDB would
be able to refill the auxv cache successfully.

And then, problem #3 becomes evident when we ask why GDB is needing to
refill the auxv cache now when it didn't need to for GDB 13.  This is
where the second commit mentioned above (a2827364e2bf) comes in.
Prior to this commit, the auxv cache was cleared by the
executable_changed observer, while after that commit the auxv cache
was cleared by the new_objfile observer -- but only when the
new_objfile observer is used in the special mode that actually means
that all objfiles have been unloaded (I know, the overloading of the
new_objfile observer is horrible, and unnecessary, but it's not really
important for this bug).

The difference arises because the new_objfile observer is triggered
from clear_symtab_users, which in turn is called from
program_space::~program_space.  The new_objfile observer for auxv does
this:

  static void
  auxv_new_objfile_observer (struct objfile *objfile)
  {
    if (objfile == nullptr)
      invalidate_auxv_cache_inf (current_inferior ());
  }

That is, when all the objfiles are unloaded, we clear the auxv cache
for the current inferior.

The problem is, then when we look at the prune_inferiors ->
delete_inferior -> ~program_space path, we see that the current
inferior is not going to be an inferior that exists within the
program_space being deleted; delete_inferior removes the deleted
inferior from the global inferior list, and then only deletes the
program_space if program_space::empty() returns true, which is only
the case if the current inferior isn't within the program_space to
delete, and no other inferior exists within that program_space
either.

What this means is that when the new_objfile observer is called we
can't rely on the current inferior having any relationship with the
program space in which the objfiles were removed.  This was an error
in the commit a2827364e2bf, the only thing we can rely on is the
current program space.  As a result of this mistake, after commit
a2827364e2bf, GDB was sometimes clearing the auxv cache for a random
inferior.  In the native target case this was harmless as we can
always refill the cache when needed, but in the remote target case, if
we need to refill the cache when the remote target is executing, then
we get the crash we observed.

And additionally, if we think about this a little more, we see that
commit a2827364e2bf made another mistake.  When all the objfiles are
removed, they are removed from a program_space, a program_space might
contain multiple inferiors, so surely, we should clear the auxv cache
for all of the matching inferiors?

Given these two insights, that the current_inferior is not relevant,
only the current_program_space, and that we should be clearing the
cache for all inferiors in the current_program_space, we can update
auxv_new_objfile_observer to:

  if (objfile == nullptr)
    {
      for (inferior *inf : all_inferiors ())
{
  if (inf->pspace == current_program_space)
    invalidate_auxv_cache_inf (inf);
}
    }

With this change we now correctly clear the auxv cache for the correct
inferiors, and GDB no longer needs to refill the cache at an
inconvenient time, this avoids the crash we were seeing.

And finally, we reach problem #4.  Inspired by the observation that
using the current_inferior from within the ~program_space function was
not correct, I added some debug to see if current_inferior() was
called anywhere else (below ~program_space), and the answer is yes,
it's called a often.  Mostly the culprit is GDB doing:

  current_inferior ()->top_target ()-> ....

But I think all of these calls are most likely doing the wrong thing,
and only work because the top target in all these cases is shared
between all inferiors, e.g. it's the native target, or the remote
target for all inferiors.  But if we had a truly multi-connection
setup, then we might start to see odd behaviour.

Problem #1 I'm just ignoring for now, I guess at some point we might
run into this again, and then we'd need to solve this.  But in this
case I wasn't sure what a "good" solution would look like.  We need
the auxv data in order to implement the linux_is_uclinux() function.
If we can't get the auxv data then what should we do, assume yes, or
assume no?  The right answer would probably be to propagate the error
back up the stack, but then we reach ~program_space, and throwing
exceptions from a destructor is problematic, so we'd need to catch and
deal at this point.  The linux_is_uclinux() call is made from within
gdbarch_has_shared_address_space(), which is used like:

  if (!gdbarch_has_shared_address_space (target_gdbarch ()))
    delete this->aspace;

So, we would have to choose; delete the address space or not.  If we
delete it on error, then we might delete an address space that is
shared within another program space.  If we don't delete the address
space, then we might leak it.  Neither choice is great.

A better solution might be to have the address spaces be reference
counted, then we could remove the gdbarch_has_shared_address_space
call completely, and just rely on the reference count to auto-delete
the address space when appropriate.

The solution for problem #2 I already hinted at above, we should have
a new target_can_delete_inferiors() call, which should be called from
prune_inferiors, this would prevent GDB from trying to delete
inferiors when a (remote) target is in a state where we know it can't
delete the inferior.  Deleting an inferior often (always?) requires
sending packets to the remote, and if the remote is waiting for a stop
reply then this will never work, so the pruning should be deferred in
this case.

The solution for problem #3 is included in this commit.

And, for problem #4, I'm not sure what the right solution is.  Maybe
delete_inferior should ensure the inferior to be deleted is in place
when ~program_space is called?  But that seems a little weird, as the
current inferior would, in theory, still be using the current
program_space...

Anyway, after this commit, the gdb.python/py-progspace-events.exp test
now passes when run with the native-extended-remote board.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30935
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I41f0e6e2d7ecc1e5e55ec170f37acd4052f46eaf

gprofng: 30894 bison should be no hard dependency

When running from a distribution tarball, bison should not be necessary.
The generated files (QLParser.tab.cc, QLParser.tab.hh) should be distributed.
configure.ac should not abort if bison is missing.
configure.ac should remove temporary files (dummy.c, Simple.class).
bison must be run once to create QLParser.tab.cc and QLParser.tab.hh.

gprofng/ChangeLog
2023-10-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30894
* configure.ac: Don't abort if bison is missing. Remove temporary files.
* src/Makefile.am: Distribute QLParser.tab.cc and QLParser.tab.hh.
* Run bison once to create QLParser.tab.cc and QLParser.tab.hh.
* configure: Rebuild.
* src/Makefile.in: Rebuild.

Fix: nm: SEGV at bfd/elf.c:2267 in _bfd_elf_get_dynamic_symbols

  PR 30904
  * elf.c (_bfd_elf_get_dynamic_symbols): Fix typo when checking to see if the gnuchains array has been successfully created.

Fix: ld: Test case pr28158 fails on x86_64-linux-musl when index is > 19

  PR 30905
  * testsuite/ld-elf/pr28158.rd: Adjust regexp to allow for section indicies larger than 9.

Fix: addr2line testsuite fails when targeting PowerPC 64 big-endian with ELFv2 ABI

  PR 30916
  * testsuite/binutils-all/addr2line.exp: Do not use PowerPC specific options when working with a MUSL target.

Fix: ld testsuite: glibc-specific DT_RELR tests should not be run on musl systems

  PR 30917
  * testsuite/ld-elf/dt-relr.exp: Skip for MUSL targets.

Fix: ld testsuite: non-PIC shared tests fail on powerpc-linux-musl

  PR 30918
  * testsuite/ld-shared/shared.exp: Add XFAILs for tests that fail with the MUSL library.

Fix: ld testsuite: Thumb PLT and GOT tests should be skipped on musl armhf targets

  PR 30923
  * testsuite/ld-arm/thumb-plt-got.d: Skip test for configurations using the MUSL library.
  * testsuite/ld-arm/thumb-plt.d: Likewise.

Fix: ld testsuite: pr22001-1 test segfaults on musl/x86

  PR 30925
  PR 22001
  * testsuite/ld-i386/i386.exp: Skip the pr22001 test with TEXTREL relocations enabled on configurations using the MUSL library.

gdb: fix reread_symbols when an objfile has target: prefix

When using a remote target, it is possible to tell GDB that the
executable to be debugged is located on the remote machine, like this:

  (gdb) target extended-remote :54321
  ... snip ...
  (gdb) file target:/tmp/hello.x
  Reading /tmp/hello.x from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
  Reading /tmp/hello.x from remote target...
  Reading symbols from target:/tmp/hello.x...
  (gdb)

So far so good.  However, when we try to start the inferior we run
into a small problem:

  (gdb) set remote exec-file /tmp/hello.x
  (gdb) start
  `target:/tmp/hello.x' has disappeared; keeping its symbols.
  Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
  Starting program: target:/tmp/hello.x
  ... snip ...

  Temporary breakpoint 1, main () at /tmp/hello.c:18
  18   printf ("Hello World\n");
  (gdb)

Notice this line:

  `target:/tmp/hello.x' has disappeared; keeping its symbols.

That's wrong, the executable hasn't been removed, GDB just doesn't
know how to check if the remote file has changed, and so falls back to
assuming that the file has been removed.

In this commit I update reread_symbols to use bfd_stat instead of
a direct stat call, this adds support for target: files, and fixes the
problem.

This change was proposed before in this commit:

  https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/

However, that patch never got merged, and seemed to get stuck
discussing issues around gnulib stat vs system stat as used by BFD.

I didn't 100% understand the issues discussed in that thread, however,
I think the problem with the previous thread related to the changes in
gdb_bfd.c, rather than to the change in symfile.c.  As such, I think
this change might be acceptable, my reasoning is:

  - the objfile::mtime field is set by a call to bfd_get_mtime (see
    objfiles.c), which calls bfd_stat under the hood.  This will end
    up using the system stat,

  - In symfile.c we currently call stat directly, which will call the
    gnulib stat, which, if I understand the above thread correctly,
    might give a different result to the system stat in some cases,

  - By switching to using bfd_stat in symfile.c we should now be
    consistently calling the system stat.

There is another issue that came up during testing that this commit
fixes.  Consider this GDB session:

  $ gdb -q
  (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
  Remote debugging using | ./gdbserver/gdbserver --multi --once -
  Remote debugging using stdio
  (gdb) file /tmp/hello.x
  Reading symbols from /tmp/hello.x...
  (gdb) set remote exec-file /tmp/hello.x
  (gdb) start
  ... snip ...
  (gdb) load
  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
  Loading section .interp, size 0x1c lma 0x4002a8
  ... snip ...
  Start address 0x0000000000401050, load size 2004
  Transfer rate: 326 KB/sec, 87 bytes/write.

Notice this line:

  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

We actually see the same output, for the same reasons, when using a
native target, like this:

  $ gdb -q
  (gdb) file /tmp/hello.x
  Reading symbols from /tmp/hello.x...
  (gdb) start
  ... snip ...
  (gdb) load
  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
  You can't do that when your target is `native'
  (gdb)

In both cases this line appears because load_command (symfile.c) calls
reread_symbols, and reread_symbols loops over every currently loaded
objfile and tries to check if the file has changed on disk by calling
stat.

However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory
BFD, the filename for this BFD is literally the string
'system-supplied DSO at 0x7ffff7fcf000'.

Before this commit GDB would try to use the system 'stat' call to stat
the file `system-supplied DSO at 0x7ffff7fcf000', which obviously
fails; there's no file with that name (usually).  As a consequence of
the stat failing GDB prints the ' .... has disappeared ...' line.

Initially, all this commit did was switch from using 'stat' to using
'bfd_stat'.  Calling bfd_stat on an in-memory BFD works just fine,
however, BFD just fills the 'struct stat' buffer with zeros (except
for the file size), see memory_bstat in bfd/bfdio.c.

However, there is a bit of a weirdness about in-memory BFDs.  When
they are initially created the libbfd caches an mtime within the bfd
object, this is done in bfd_from_remote_memory (elfcode.h), the cached
mtime is the time at which the in-memory BFD is created.

What this means is that when GDB creates the in-memory BFD, and we
call bfd_get_mtime(), the value returned, which GDB caches within
objfile::mtime is the creation time of the in-memory BFD.  But, when
this patch changes to use bfd_stat() we now get back 0, and so we
believe that the in-memory BFD has changed.  This is a change in
behaviour.

To avoid this change in behaviour, in this commit, I propose that we
always skip in-memory BFDs in reread_symbols.  This preserves the
behaviour from before this commit -- mostly.

As I'm not specifically checking for, and then skipping, in-memory
BFDs, we no longer see this line:

  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

Which I think is an improvement.

Co-Authored-By: Tom Tromey <tromey@adacore.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove print_sys_errmsg

This started with me running into this comment in symfile.c:

  /* FIXME, should use print_sys_errmsg but it's not filtered.  */
  gdb_printf (_("`%ps' has disappeared; keeping its symbols.\n"),
              styled_string (file_name_style.style (), filename));

In this particular case I think I disagree with the comment; I think
the output should be a warning rather than just a message printed to
gdb_stdout, I think when the executable, or some other objfile that is
currently being debugged, disappears from disk, this is likely an
unexpected situation, and worth warning the user about.

So, in theory, I could just call print_sys_errmsg and remove the
comment, but that would mean loosing the filename styling in the
output... so in the end I remove the comment and updated the code to
call warning.

But that got me looking at print_sys_errmsg and how it's used.

Currently the function takes a string and an errno, and prints, to
stderr, the string followed by the result of calling strerror on the
errno.

In some places the string passed to print_sys_errmsg is just a
filename, and this is used when something goes wrong.  In these cases,
I think calling warning rather than gdb_printf to gdb_stderr, would be
better, and in fact, in a couple of places we manually print a
"warning" prefix, and then call print_sys_errmsg.  And so, for these
users I have added a new function warning_filename_and_errno, which
takes a filename, which is printed with styling, and an errno, which
is passed through strerror and the resulting string printed.  This new
function calls warning to print its output.  I then updated some of
the print_sys_errmsg users to use this new function.

Some other users of print_sys_errmsg are also emitting what is clearly
a warning, however, the string being passed in is more than just a
filename, so the new warning_filename_and_errno function can't be
used, it would style the whole string.  For these users I have
switched to calling warning directly, this allows me to style the
warning message correctly.

Finally, in inflow.c there is one last call to print_sys_errmsg, in
this case I just inlined the definition of print_sys_errmsg.  This is
a really weird case, as after printing this message GDB just does a
hard exit.  This is pretty old code, dating back to the initial GDB
import, I guess it should be updated to call error() maybe, but I'm
reluctant to make this change as part of this commit, just in case
there's some reason why we can't throw an error at this point.

With that done there are now no users of print_sys_errmsg, and so the
old function can be removed.

While I was doing all of the above I added some additional filename
styling in soure.c, this is in an else block where the if contained
the print_sys_errmsg call, so these felt related.

And finally, while I was updating the uses of print_sys_errmsg in
procfs.c, I noticed that we used a static errmsg buffer to format some
error strings.  As the above changes got rid of one of the users of
errmsg I also removed the other two users, and the static buffer.

There were a couple of tests that depended on the existing output
message format that needed updating.  In one case we gained an extra
'warning: ' prefix, and in the other 'Warning: ' becomes 'warning: ',
I think in both cases the new output is an improvement.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove use of a static buffer for building error strings

I noticed in procfs.c that we use a static buffer for building error
strings when we could easily use std::string and string_printf to
achieve the same result, this commit does that.

I ran into this while performing a further refactor/cleanup that will
be presented in a later patch in this series, and thought this was
worth splitting out into its own patch.

As far as I can tell, only Solaris uses procfs.c, so I did a test
build on a Solaris machine, and I don't believe that I've broken
anything.

There should be no user visible changes after this commit.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: use archive name in warning when appropriate

While working on some other patch I noticed that in reread_symbols
there is a diagnostic message that can be printed, and in some cases
we might use the wrong filename in the message.

The code in question is checking to see if an objfile has changed on
disk, we do this by stat-ing the on disk file and checking the mtime.
If this file has been removed from disk then we print a message that
the file has been removed, however, if the objfile is within an
archive then we stat the archive itself, but then warn that the
component within the archive has disappeared.  I think it makes more
sense to say that the archive has disappeared.

The last related commit is this one:

  commit 02aeec7bde8ec8a04d14a5637e75f1c6ab899e23
  Date:   Tue Apr 27 21:01:30 2010 +0000

      Check library name rather than member name when rereading symbols.

Though this just makes the code to stat the archive unconditional, the
code in question existed before this commit.

However, the above commit doesn't include any tests, and seems to
indicate that the problem being addressed was seen on Darwin.  I'm not
sure how to setup a test where GDB is using an objfile from within an
archive, and so there's no tests for this commit...

... but if someone can let me know how I can setup a suitable test,
please let me know and I'll try to get something working.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: some additional filename styling

Fix up another couple of places where we can apply filename styling.

Approved-By: Tom Tromey <tom@tromey.com>

Fix: ld testsuite: 'Version' pattern grabs 'Version5 EABI', breaking test on arm-linux-musleabihf

  PR 30924
  * testsuite/ld-elfvers/vers.exp (objdump_emptyverstuff): Handle EABI version information in objdump's output.

aarch64: Enable Cortex-X4 CPU

microblaze: Add address extension instructions

  * microblaze-opcm.h (struct op_code_struct): Tidy and remove redundant entries.
  * microblaze-opc.h (MAX_OPCODES): Increase to 300. (op_code_struct): Add address extension instructions.

Automatic date update in version.in

gdb/testsuite: XFAIL some gdb.base/fileio.exp

Some gdb.base/fileio.exp tests expect the inferior to not have write
access to some files. If the test is being run as root, this is never
possible. This commit adds a way to identify if the user is root and
xfails the tests that expect no write access.

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

ld: microblaze: ignore rwx segments

The linker will generate warnings if it is creating an executable
stack or a segment with all three read, write and execute permissions.
These settings are not appropriate for all targets including
MicroBlaze.

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

opcodes: microblaze: Add hibernate and suspend instructions

sme2: Document SME2 registers and features

Document changes introduced by gdb's SME2 support.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme2: Extend SME tests to include SME2

Reusing the SME tests, this patch introduces additional tests to exercise
reading/writing ZT0, availability of the register set, signal context reading
for ZT0 and also core file generation.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme2: Core file support for ZT register set

This patch adds support for ZT register dumps/reads for core files.  The
ZT register is available when the SME2 feature is advertised as available
by the Linux Kernel.

Unlike the enablement for SME1 and the ZA register, support for SME2 is rather
simple given the fixed size of the ZT0 register.

Validated on the Fast Models.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme2: signal frame support

Teach gdb about the ZT state on signal frames and how to restore
the contents of the registers.

There is a new ZT_MAGIC context that the Linux Kernel uses to communicate
the ZT register state to gdb.

As mentioned before, the ZT state should only be available when the ZA state
is available.

Validated under Fast Models.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme2: Enable SME2 support in gdbserver

This patch teaches gdbserver about the SME2 and the ZT0 register.

Since most of the code used by gdbserver for SME2 is shared with gdb, this
is a rather small patch that reuses most of the code put in place for native
AArch64 Linux.

Validated under Fast Models.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme2: Enable SME2 for AArch64 gdb on Linux

SME2 defines a new 512-bit register named ZT0, and it is only available
if SME is also supported.  The ZT0 state is valid only if the SVCR ZA bit
is enabled.  Otherwise its contents are empty (0).

The target description is dynamic and gets generated at runtime based on the
availability of the feature.

Validated under Fast Models.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Document SME registers and features

Provide documentation for the SME feature and other information that
should be useful for users that need to debug a SME-capable target.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Add SVE/SME testcases

Add 5 SVE/SME tests to exercise all the new features like reading/writing
registers, pseudo-registers, signal frames and core files.

- Sanity check for SME: Gives a brief smoke test to make sure the most basic
of features are working correctly.

- ZA unavailability tests: Validates the behavior/content of the ZA register
is correct when no payload is available.  It also exercises changing the
vector lengths.

- ZA availability tests: These tests exercise reading/writing to all the
possible ZA pseudo-registers, and validates the state is correct.

- Core file tests: Validates that core file reading and writing works
correctly and that all state dumped/loaded is sane.  This is exercised for
both Linux Kernel core files and gcore core files.

- Signal frame tests: Validates the correct restoration of SME/SVE/FPSIMD
values across signal frames.

Since some of these tests are very lengthy and take a little while to run
(under QEMU at the moment), I decided to parallelize them into smaller
chunks so we can throw some more CPU power at them so they run faster.

I'd still like to add a few more tests to give the testsuite more coverage
in the areas of SME/SVE.  Hopefully in the near future that will happen.

Just a reminder that these SME tests are currently unsupported when gdb is
connected to a remote target.  That's because the RSP doesn't support
communicating changes in vector lenghts mid-execution, so gdb will always
get wrong state from the remote target.

Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Core file support for Linux

This patch enables dumping SME state via gdb's gcore command and also
enables gdb to read SME state from a core file generated by the Linux
Kernel.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

corefile/bug: Add hook to control the use of target description notes from corefiles

Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread
can potentially have distinct target descriptions/gdbarches.

When loading a gcore-generated core file, at the moment GDB gives priority
to the target description dumped to NT_GDB_TDESC.  Though technically correct
for most targets, it doesn't work correctly for AArch64 with SVE or SME
support.

The correct approach for AArch64/Linux is to either have per-thread target
description notes in the corefiles or to rely on the
gdbarch_core_read_description hook, so it can figure out the proper target
description for a given thread based on the various available register notes.

The former, although more correct, doesn't address the case of existing gdb's
that only output a single target description note.

This patch goes for the latter, and adds a new gdbarch hook to conditionalize
the use of the corefile target description note. The hook is called
use_target_description_from_corefile_notes.

The hook defaults to returning true, meaning targets will use the corefile
target description note.  AArch64 Linux overrides the hook to return false
when it detects any of the SVE or SME register notes in the corefile.

Otherwise it should be fine for AArch64 Linux to use the corefile target
description note.

When we support per-thread target description notes, then we can augment
the AArch64 Linux hook to rely on those notes.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

corefile/bug: Use thread-specific gdbarch when dumping register state to core files

When we have a core file generated by gdb (via the gcore command), gdb dumps
the target description to a note.  During loading of that core file, gdb will
first try to load that saved target description.

This works fine for almost all architectures. But AArch64 has a few
dynamically-generated target descriptions/gdbarch depending on the vector
length that was in use at the time the core file was generated.

The target description gdb dumps to the core file note is the one generated
at the time of attachment/startup.  If, for example, the SVE vector length
changed during execution, this would not reflect on the core file, as gdb
would still dump the initial target description.

Another issue is that the gdbarch potentially doesn't match the thread's
real gdbarch, and so things like the register cache may have different formats
and sizes.

To address this, fetch the thread's architecture before dumping its register
state.  That way we will always use the correct target description/gdbarch.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Get rid of linux-core-thread-data

This struct type seems to have been used in the past as a callback
parameter.  Now it seems that case is no longer true, so we can simplify
things by passing the individual parameters linux_core_thread_data
encapsulates directly to the functions.

This is just a cleanup before the next change.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

sme: Support TPIDR2 signal frame context

The Linux Kernel defines a separate context for the TPIDR2 register in a
signal frame.  Handle this additional context in gdb so this register
gets restored properly when unwinding through signal frames.

The TPIDR2 register is closely related to SME, and is available when SME
support is reported.

This is tested by testcases that are available in a later patch in the series.

Regressions-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Fixup sigframe gdbarch when vg/svg changes

With SME, where you have two different vector lengths (vl and svl), it may be
the case that the current frame has a set of vector lengths (A) but the signal
context has a distinct set of vector lengths (B).

In this case, we may run into a situation where GDB attempts to use a gdbarch
created for set A, but it is really dealing with a frame that was using set
B.

This is problematic, specially with SME, because now we have a different
number of pseudo-registers and types that gets cached on creation of each
gdbarch variation.

For AArch64 we really need to be able to use the correct gdbarch for each
frame, and I noticed the signal frame (tramp-frame) doesn't have a settable
prev_arch field.  So it ends up using the default frame_unwind_arch function
and eventually calling get_frame_arch (next_frame).  That means the previous
frame will always have the same gdbarch as the current frame.

This patch first refactors the AArch64/Linux signal context code, simplifying
it and making it reusable for our purposes of calculating the previous frame's
gdbarch.

I introduced a struct that holds information that we have found in the signal
context, and with which we can make various decisions.

Finally, a small change to tramp-frame.c and tramp-frame.h to expose a
prev_arch hook that the architecture can set.

With this new field, AArch64/Linux can implement a hook that looks at the
signal context and infers the gdbarch for the previous frame.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Signal frame support

Teach gdb about the ZA/SSVE state on signal frames and how to restore
the contents of the registers.

There is a new ZA_MAGIC context that the Linux Kernel uses to communicate
the ZA register state to gdb.

The SVE_MAGIC context has also been adjusted to contain a flag indicating
whether it is a SVE or SSVE state.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sve: Fix signal frame z/v register restore

While doing some SME work, I ran into the situation where the Z register
contents restored from a signal frame are incorrect if the signal frame
only contains fpsimd state and no sve state.

This happens because we only restore the v register values in that case,
and don't do anything for the z registers.

Fix this by initializing the z registers to 0 and then copying over the
overlapping part of the v registers to the z registers.

While at it, refactor the code a bit to simplify it and make it smaller.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sme: Add support for SME

Enable SME support in gdbserver by adjusting the usual fields.  There is
not much to this patch because the code is either in gdb or it is shared
between gdbserver and gdb.  One exception is the bump to gdbserver's
PBUFSIZ from 18432 to 131104.

Since the ZA register can be quite big (256 * 256 bytes), the g/G remote
packet will also become quite big

From gdbserver/tdesc.cc:init_target_desc, I estimated the new size should
be at least (2 * 256 * 256 + 32), which yields 131104.

It is also unlikely we will find a process starting up with SVL set to 256.

Ideally we'd adjust the packet size dynamically based on what we need, but
for now this should do.

Please note we have the same limitation for SME that we have for SVE, and
that is the fact gdbserver cannot communicate vector length changes to gdb
via the remote protocol.

Thiago is working on this improvement, which hopefully will be able to be
adapted to SME in an easy way.

Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

refactor: Adjust expedited registers dynamically

Instead of using static arrays, build the list of expedited registers
dynamically using a std::vector.

This refactor shouldn't cause any user-visible changes.

Regression-tested for aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Convert tdesc's expedite_regs to a string vector

Right now the list of expedited registers is stored as an array of char *,
with a nullptr element at the end to signal its last element.

Convert expedite_regs to a std::vector of std::string so it is easier to
manage the elements and the storage is handled automatically.

Eventually we might want to convert all the target functions so they pass a
std::vector of std::string as well. Or maybe expose an interface that target can
use to add expedited registers on-by-one depending on the target description
discovery needs, as opposed to just a static list of char *.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

sme: Enable SME registers and pseudo-registers

The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with
variable sizes.  It also exposes a new mode called streaming mode.

Similarly to SVE, the ZA register size is dictated by a vector length, but the
SME vector length is called streaming vetor length. The total size for
ZA in a given moment is svl x svl.

In streaming mode, the SVE registers have their sizes based on svl rather than
the regular vector length (vl).

The feature detection is controlled by the HWCAP2_SME bit, but actual support
should be validated by attempting a ptrace call for one of the new register
sets: NT_ARM_ZA and NT_ARM_SSVE.

Due to its large size, the ZA register is exposed as a vector of bytes, but we
introduce a number of pseudo-registers that gives various different views
into the ZA contents. These can be arranged in a couple categories: tiles and
tile slices.

Tiles are matrices the same size or smaller than ZA.  Tile slices are vectors
which map to ZA's rows/columns in different ways.

A new dynamic target description is provided containing the ZA register, the SVG
register and the SVCR register.  The size of ZA, like the SVE vector registers,
is based on the vector length register SVG (VG for SVE).

This patch enables SME register support for gdb.

[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture

Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

sve: Fix return command when using V registers in a SVE-enabled target

In a target without SVE support, the V registers have a size of 16 bytes,
otherwise they may have a size bigger than 16 bytes (depending on the current
vector length for the Z registers, as they overlap the V registers).

In aarch64-tdep.c:aarch64_store_return_value, the code is laid
out in a way that allocates the buffer with the size of the register, but
only updates the amount of bytes for the particular type we're returning.

This may cause a situation where we have a register size of 32 bytes but
are returning a floating point value of 8 bytes.  The temporary buffer
will therefore have 32 bytes, but we'll only update 8 bytes of it.

When we write the entire register back, it will have potentially 24 bytes
of garbage in it.

Fix this by first reading the original contents of the register and then
overriding only the bytes that we need for the return value.

Tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

refactor: Simplify SVE interface to read/write registers

This is a patch in preparation to upcoming patches enabling SME support.  It
attempts to simplify the gdb/gdbserver shared interface used to read/write
SVE registers.

Where the current code makes use of unique_ptr, allocating a new buffer by
hand and passing a buffer around, this patch makes that code use
gdb::byte_vector and passes a reference to this byte vector to the functions,
allowing the functions to have ready access to the size of the buffer.

It also shares a bit more code between gdb and gdbserver, in particular around
handling of ptrace get/set requests for SVE.

I think gdbserver could be refactored to handle register reads/writes more
like gdb's native layer as opposed to letting the generic linux-low layer do
the ptrace calls.  This is not very flexible and assumes one size for the
responses.  If you have something like NT_ARM_SVE, where you can have either
FPSIMD or SVE contents, it doesn't work that well.

I didn't want to change that interface right now as it is a bit too much work
and touches all the targets, some of which I can't easily test.

Hence the reason why the buffer the generic linux-now passes down to
linux-aarch64-low is unused or ignored.

No user-visible changes should happen as part of this refactor other than a
slightly reworded warning message.

While doing the refactor, I also noticed what seems to be a mistake in checking
if the register cache contains active (non-zero) SVE data.

For instance, the original code did something like this in
aarch64_sve_regs_copy_from_reg_buf:

has_sve_state |= reg_buf->raw_compare (AARCH64_SVE_Z0_REGNUM + i
       reg, sizeof (__int128_t));

"reg" is a zeroed-out buffer that we compare the Z register contents
past the first 128 bits.  The problem here is that raw_compare returns
1 if the contents compare the same, which means has_sve_state will be
true.  But if we compared the Z register contents to 0, it means we
*do not* have SVE state, and therefore has_sve_state should be false.

The consequence of this mistake is that we convert the initial
FPSIMD-formatted data we get from ptrace for the NT_ARM_SVE register
set to a SVE-formatted one.

In the end, this doesn't cause user-visible differences because the
values of both the Z and V registers will still be the same.  But the
logic is not correct.

I used the opportunity to fix this, and it gets tested later on by
the additional SME tests.

I do plan on submitting some SVE-specific tests to make sure we have
a bit more coverage in GDB's testsuite.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

refactor: Rename SVE-specific files

In preparation to the SME support patches, rename the SVE-specific files to
something a bit more meaningful that can be shared with the SME code.

In this case, I've renamed the "sve" in the names to "scalable".

No functional changes.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Fix register fetch/store order for native AArch64 Linux

I noticed we don't handle register reads/writes in the best way for native
AArch64 Linux.  Some other registers are fetched/stored even if upper level
code told us to fetch a particular register number.

Fix this by being more strict about which registers we touch when
reading/writing them in the native AArch64 Linux layer.

There should be no user-visible changes due to this patch.

Regression-tested on aarch64-linux Ubuntu 22.04/20.04.

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

aarch64: Refactor system register data

This patch  moves instances of system register definitions, represented
by the SYSREG macro, out of their original place in `aarch64-opc.c'
and into a dedicated .def file, `aarch64-sys-regs.def'.

System register entries in this new file are ordered alphabetically by
name.  This choice is made to enable the use of fast search algorithms
such as binary search when validating register names.

The SYSREG macro, defined as SYSREG (name, encoding, flags, features)
is kept as is and used in the def file, but all other SR_* macros
which previously served as indirections to SYSREG are removed.

opcodes/ChangeLog:
* aarch64-opc.c (SR_CORE): Macro definition and uses deleted.
(SR_FEAT): Likewise.
(SR_FEAT2): Likewise.
(SR_V8_1_A): Likewise.
(SR_V8_4_A): Likewise.
(SR_V8A): Likewise.
(SR_V8R): Likewise.
(SR_V8_1A): Likewise.
(SR_V8_2A): Likewise.
(SR_V8_3A): Likewise.
(SR_V8_4A): Likewise.
(SR_V8_6A): Likewise.
(SR_V8_7A): Likewise.
(SR_V8_8A): Likewise.
(SR_GIC): Likewise.
(SR_AMU): Likewise.
(SR_LOR): Likewise.
(SR_PAN): Likewise.
(SR_RAS): Likewise.
(SR_RNG): Likewise.
(SR_SME): Likewise.
(SR_SSBS): Likewise.
(SR_SVE): Likewise.
(SR_ID_PFR2): Likewise.
(SR_PROFILE): Likewise.
(SR_MEMTAG): Likewise.
(SR_SCXTNUM): Likewise.
(SR_EXPAND_ELx): Likewise.
(SR_EXPAND_EL12): Likewise.
* opcodes/aarch64-sys-regs.def: New.

aarch64: system register aliasing detection

This patch adds a mechanism for system register name alias detection
to register-matching mechanisms.

A new `F_REG_ALIAS' flag is added to the set of register flags and
used to label which entries in aarch64_sys_regs[] correspond to
aliases (and thus which CPENC values are non-unique in this array).

Where this is used is, for example, in `aarch64_print_operand' where,
in the case of system register decoding, the aarch64_sys_regs[] array
is iterated through until a match in CPENC value is made and the first
match accepted.  If insufficient care is given in the ordering of
system registers in this array, the alias is encountered before the
"real" register and used incorrectly as the register name in the
disassembled output.

With this flag and the new `aarch64_sys_reg_alias_p' test, search
candidates corresponding to aliases can be conveniently skipped over.

One concrete example of where this is useful is with the
`trcextinselr0' system register.  It was initially placed in the
system register list before `trcextinselr', in contrast to a more
natural alphabetical order.

include/ChangeLog:
* opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype.

opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_reg_alias_p): New.
(aarch64_print_operand): add aarch64_sys_reg_alias_p check.
(aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr"
entry.
* aarch64-opc.h (F_REG_ALIAS): New.

Automatic date update in version.in

gdb/corefile: write NT_GDB_TDESC based on signalled thread

When creating a core file from within GDB we include a NT_GDB_TDESC
that includes the target description of the architecture in use.

For architectures with dynamic architectures (e.g. AArch64 with
sve/sme) the original architecture, calculated from the original
target description, might not match the per-thread architecture.

In the general case, where each thread has a different architecture,
then we really need a separate NT_GDB_TDESC for each thread, however,
there's currently no way to read in multiple NT_GDB_TDESC.

This commit is a step towards per-thread NT_GDB_TDESC.  In this commit
I have updated the function that writes the NT_GDB_TDESC to accept a
gdbarch (rather than calling target_gdbarch() to find a gdbarch), and
I now pass in the gdbarch of the signalled thread.

In many cases (though NOT all) targets with dynamic architectures
really only use a single architecture, even when there are multiple
threads, so in the common case, this should ensure that GDB emits an
architecture that is more likely to be correct.

Additional work will be needed in order to support corefiles with
truly per-thread architectures, but that will need to be done in the
future.

MIPS: Fix `readelf -S bintest' test for n64 targets

Add a 64-bit traditional MIPS dump variant for the `readelf -S bintest'
test from binutils-all/readelf.exp, using a filename suffix according to
the rules set there, removing:

FAIL: readelf -S bintest

regressions with `mips64-linux-gnuabi64', `mips64el-linux-gnuabi64',
`mips64-openbsd', and `mips64el-openbsd' targets, which default to the
n64 ABI and consequently produce a section layout that is different from
what the generic dump pattern covers.

Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
binutils/
* testsuite/binutils-all/readelf.s-64-tmips: New test variant.

Fix: readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx

  PR 29267
  * dwarf.c (fetch_indexed_value): Delete. (fetch_indexed_offset): Correct base address calculation. (read_and_display_attr_value): Replace uses of fetch_indexed_value with fetch_indexed_offset.

Automatic date update in version.in

gdb/python: reformat file with black

Reformat a Python file with black after this commit:

  commit 59912fb2d22f8a4bb0862487f12a5cc65b6a013f
  Date:   Tue Sep 19 11:45:36 2023 +0100

      gdb: add Python events for program space addition and removal

There should be no functional change with this commit.

Add regression test for instructionReference change

Yesterday I pushed a patch to fix a small oversight in the DAP code
that caused an instructionReference to be an array instead of a
string.

This patch adds a test case for that regression.  This required
exposing the TON form of the response -- something I mentioned might
be necessary when this code was changed to return just the Tcl form.

I tested this by backing out yesterday's bug fix and verifying that a
failure is seen.

Clean up intermediate values in val_print_packed_array_elements

Following on Tom de Vries' work in the other array-printers, this
patch changes val_print_packed_array_elements to also avoid allocating
too many values when printing an Ada packed array.

gdb/testsuite: accept variable number of spaces in gdb.base/jit-reader-simple.exp regex

I see this failure:

    FAIL: gdb.base/jit-reader-simple.exp: standalone: change addr: initial run: maint info breakpoints shows jit breakpoint

The jit breakpoint expected by the test is there, it's just that the
number of spaces doesn't match what the test expects, after "jit
events":

    -2      jit events       keep y   0x0000555555555119 <__jit_debug_register_code> inf 1

Fix that by relaxing the regex a bit.

Change-Id: Ia3b04e6d5978399d940fd1a590f95f15275ca7ac

gdb: Add command 'maint set/show debuginfod download-sections'

This setting controls whether GDB may attempt to download ELF/DWARF
sections from debuginfod servers.

This setting is enabled by default if gdb is built with debuginfod
section download support (requires libdebuginfod 0.188).

Also update debuginfod command help text and gdb.texinfo with
information on section downloading and the new command.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/debuginfod: Add debuginfod_section_query

Add new function debuginfod_section_query.  This function queries
debuginfod servers for an individual ELF/DWARF section associated with
a given build-id.

Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/testsuite] Handle older gcc in gdb.ada/import.exp

When running test-case gdb.ada/import.exp with gcc 7, most test fail:
...
FAIL: gdb.ada/import.exp: print imported_var_ada
FAIL: gdb.ada/import.exp: print local_imported_var
FAIL: gdb.ada/import.exp: print pkg.imported_var_ada
FAIL: gdb.ada/import.exp: print pkg.exported_var_ada
FAIL: gdb.ada/import.exp: print exported_var_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at local_imported_func
...

When running with gcc 8 or 9, only 2 tests fail:
...
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at pkg.imported_func_ada
FAIL: gdb.ada/import.exp: gdb_breakpoint: set breakpoint at imported_func_ada
...

The test-case passes fully with gcc 10, 11, 12 and 13.

Debug info for pragma import seems to not have been supported before gcc 8, so
require that version.

The two FAILs with gcc 8 and 9 seem to be due to problems in debug info.  Add
an xfail for these.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Add KFAIL for PR ada/30908

With gcc 13.2.1, I run into a cluster of fails:
...
FAIL: gdb.ada/str_binop_equal.exp: print my_str = "ABCD"
FAIL: gdb.ada/widewide.exp: print my_wws = " helo"
FAIL: gdb.ada/widewide.exp: print my_ws = "wide"
...

The problem is that the debug info contains information about function
ada.strings.maps."=", and gdb uses it to implement the comparison.
The function is supposed to compare two char sets, not strings, so gdb
shouldn't use it.  This is PR ada/30908.

I don't see the same problem with gcc 7.5.0, because the exec doesn't contain
the debug info for the function, because the corresponding object is not
linked in.  Adter adding "with Ada.Strings.Maps; use Ada.Strings.Maps;" to
gdb.ada/widewide/foo.adb I run into the same problem with gcc 7.5.0.

Add KFAILs for the PR.

Tested on x86_64-linux:
- openSUSE Leap 15.4 (using gcc 7.5.0), and
- openSUSE Tumbleweed (using gcc 13.2.1).

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908

gdb: add Python events for program space addition and removal

Initially I just wanted a Python event for when GDB removes a program
space, I'm writing a Python extension that caches information for each
program space, and need to know when I should discard entries for a
particular program space.

But, it seemed easy enough to also add an event for when GDB adds a
new program space, so I went ahead and added both new events.

Of course, we don't currently have an observable for program space
addition or removal, so I first needed to add these.  After that it's
pretty simple to add two new Python events and have these trigger.

The two new event registries are:

  events.new_progspace
  events.free_progspace

These emit NewProgspaceEvent and FreeProgspaceEvent objects
respectively, each of these new event types has a 'progspace'
attribute that contains the relevant gdb.Progspace object.

There's a couple of things to be mindful of.

First, it is not possible to catch the NewProgspaceEvent for the very
first program space, the one that is created when GDB first starts, as
this program space is created before any Python scripts are sourced.

In order to allow this event to be caught we would need to defer
creating the first program space, and as a consequence the first
inferior, until some later time.  But, existing scripts could easily
depend on there being an initial inferior, so I really don't think we
should change that -- and so, we end up with the consequence that we
can't catch the event for the first program space.

The second, I think minor, issue, is that GDB doesn't clean up its
program spaces upon exit -- or at least, they are not cleaned up
before Python is shut down.  As a result, any program spaces in use at
the time GDB exits don't generate a FreeProgspaceEvent.  I'm not
particularly worried about this for my use case, I'm using the event
to ensure that a cache doesn't hold stale entries within a single GDB
session.  It's also easy enough to add a Python at-exit callback which
can do any final cleanup if needed.

Finally, when testing, I did hit a slightly weird issue with some of
the remote boards (e.g. remote-stdio-gdbserver).  As a consequence of
this issue I see some output like this in the gdb.log:

  (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
  step
  FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10>
  warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
  Use the "interrupt" command to stop the target
  and then try again.
  warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running.
  Use the "interrupt" command to stop the target
  and then try again.
  warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running.
  Use the "interrupt" command to stop the target
  and then try again.
  do_parent_stuff () at py-progspace-events.c:41
  41        ++global_var;
  (gdb) PASS: gdb.python/py-progspace-events.exp: step

The 'FreeProgspaceEvent ...' line is expected, that's my test Python
extension logging the event.  What isn't expected are all the blocks
like:

  warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running.
  Use the "interrupt" command to stop the target
  and then try again.

It turns out that this has nothing to do with my changes, this is just
a consequence of reading files over the remote protocol.  The test
forks a child process which GDB stays attached too.  When the child
exits, GDB cleans up by calling prune_inferiors, which in turn can
result in GDB trying to close some files that are open because of the
inferior being deleted.

If the prune_inferiors call occurs when the remote target is
running (and in non-async mode) then GDB will try to send a fileio
packet while the remote target is waiting for a stop reply, and the
remote target will throw an error, see remote_target::putpkt_binary in
remote.c for details.

I'm going to look at fixing this, but, as I said, this is nothing to
do with this change, I just mention it because I ended up needing to
account for these warning messages in one of my tests, and it all
looks a bit weird.

Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

gdb: remove solib::pspace field

This backlink is not necessary, we always know the program space from
the context.  Pass it down the solib_unloaded observer.

Change-Id: I45a503472dc791f517558b8141901472634e0556
Approved-By: Tom Tromey <tom@tromey.com>

Fix memory leak in RiscV assembler.

  PR 30861
  * config/tc-riscv.c (riscv_insert_uleb128_fixes): Release duplicated memory.

Use bfd_get_current_time in places where it is suitable

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Support the NO_COLOR environment variable

I ran across this site:

    https://no-color.org/

... which lobbies for tools to recognize the NO_COLOR environment
variable and disable any terminal styling when it is seen.

This patch implements this for gdb.

Regression tested on x86-64 Fedora 38.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

tc-microblaze.c - int compare for X_add_number.

The range check should be checking for the range
ffffffff80000000..7fffffff, not ffffffff70000000.

This patch has been tested for years of AMD Xilinx Yocto
releases as part of the following patch set:

https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

bfd: microblaze: Fix bug in TLSTPREL Relocation

Fixed the problem related to the fixup/relocations TLSTPREL.
When the fixup is applied the addend is not added at the correct offset
of the instruction. The offset is hard coded considering its big endian
and it fails for Little endian. This patch allows support for both
big & little-endian compilers.

This patch has been tested for years of AMD Xilinx Yocto
releases as part of the following patch set:

https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>

x86-64: Add -z mark-plt and -z nomark-plt

The PLT entry in executables and shared libraries contains an indirect
branch, like

  jmp *foo@GOTPCREL(%rip)
push $index_foo
jmp .PLT0

or

endbr64
  jmp *foo@GOTPCREL(%rip)
  NOP padding

which is used to branch to the function, foo, defined in another object.
Each R_X86_64_JUMP_SLOT relocation has a corresponding PLT entry.

The dynamic tags have been added to the x86-64 psABI to mark such PLT
entries:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/6d824a52a42d173eb838b879616c1be5870b593e

Add an x86-64 linker option, -z mark-plt, to mark PLT entries with

 #define DT_X86_64_PLT     (DT_LOPROC + 0)
 #define DT_X86_64_PLTSZ   (DT_LOPROC + 1)
 #define DT_X86_64_PLTENT  (DT_LOPROC + 3)

1. DT_X86_64_PLT: The address of the procedure linkage table.
2. DT_X86_64_PLTSZ: The total size, in bytes, of the procedure linkage
table.
3. DT_X86_64_PLTENT: The size, in bytes, of a procedure linkage table
entry.

and set the r_addend field of the R_X86_64_JUMP_SLOT relocation to the
memory offset of the indirect branch instruction.  The dynamic linker
can use these tags to update the PLT section to direct branch.

bfd/

* elf-linker-x86.h (elf_linker_x86_params): Add mark_plt.
* elf64-x86-64.c (elf_x86_64_finish_dynamic_symbol): Set the
r_addend of R_X86_64_JUMP_SLOT to the indirect branch offset
in PLT entry for -z mark-plt.
* elfxx-x86.c (_bfd_x86_elf_size_dynamic_sections): Add
DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT for
-z mark-plt.
(_bfd_x86_elf_finish_dynamic_sections): Set DT_X86_64_PLT,
DT_X86_64_PLTSZ and DT_X86_64_PLTENT.
(_bfd_x86_elf_get_synthetic_symtab): Ignore addend for
JUMP_SLOT relocation.
(_bfd_x86_elf_link_setup_gnu_properties): Set
plt_indirect_branch_offset.
* elfxx-x86.h (elf_x86_plt_layout): Add plt_indirect_branch_offset.

binutils/

* readelf.c (get_x86_64_dynamic_type): New function.
(get_dynamic_type): Call get_x86_64_dynamic_type.

include/

* elf/x86-64.h (DT_X86_64_PLT): New.
(DT_X86_64_PLTSZ): Likewise.
(DT_X86_64_PLTENT): Likewise.

ld/

* ld.texi: Document -z mark-plt and -z nomark-plt.
* emulparams/elf32_x86_64.sh: Source x86-64-plt.sh.
* emulparams/elf_x86_64.sh: Likewise.
* emulparams/x86-64-plt.sh: New file.
* testsuite/ld-x86-64/mark-plt-1.s: Likewise.
* testsuite/ld-x86-64/mark-plt-1a-x32.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1a.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1b-x32.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1b.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1c-x32.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1c.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise.
* testsuite/ld-x86-64/mark-plt-1d.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt tests.

Fix: Segmentation fault caused by npd in objdump

  PR 30906
  * elf.c (_bfd_elf_slurp_version_tables): Test that the verref section header has been initialised before using it.

Update README file's installation instructions

gdb: add Sam James to MAINTAINERS

Acked-by: Tom de Vries <tdevries@suse.de>

gdb/testsuite: Add relative versus absolute LD_LIBRARY_PATH test

At one time, circa 2006, there was a bug, which was presumably fixed
without adding a test case:

    If you provided some relative path to the shared library, such as
    with

export LD_LIBRARY_PATH=.

    then gdb would fail to match the shared library name during the
    TLS lookup.

I think there may have been a bit more to it than is provided by that
explanation, since the test also takes care to split the debug info
into a separate file.

In any case, this commit is based on one of Red Hat's really old
local patches.  I've attempted to update it and remove a fair amount
of cruft, hopefully without losing any critical elements from the
test.

Testing on Fedora 38 (correctly) shows 1 unsupported test for
native-gdbserver and 5 PASSes for the native target as well as
native-extended-gdbserver.

In his review of v1 of this patch, Lancelot SIX observed that
'thread_local' could be used in place of '__thread' in the C source
files.  But it only became available via the standard in C11, so I
used additional_flags=-std=c11 for compiling both the shared object
and the main program.

Also, while testing with CC_FOR_TARGET=clang, I found that
'additional_flags=-Wl,-soname=${binsharedbase}' caused clang
to complain that this linker flag was unused when compiling
the source file, so I moved this linker option to 'ldflags='.

My testing for this v2 patch shows the same results as with v1,
but I've done additional testing with CC_FOR_TARGET=clang as
well.  The results are the same as when gcc is used.

Co-Authored-by: Jan Kratochvil <jan@jankratochvil.net>
Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove nbsd_{ilp32,lp64}_solib_svr4_fetch_link_map_offsets

They are unused.

Change-Id: I9b78837d41126ce1957aa1e8b08c82a422f06cbf
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

gdb: remove unused imports in solib*.[ch]

I'm starting to work on these files, I thought it would be a good time
to remove unused imports.  These were identified by
include-what-you-use.  Tested by rebuilding.

Change-Id: I3eaf3fa0ea3506c7ecfbc8ecff5031433b1dadb8
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

Automatic date update in version.in

Added support in gas for mlittle-endian and mbig-endian flags as options.

Updated show usage for MicroBlaze specific assembler options
to include new entries.

This patch has been tested for years of AMD Xilinx Yocto
releases as part of the following patch set:

https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
---
V1->V2:
 - removed new options which were unnecessary
 - added documentation for MicroBlaze specific options

Signed-off-by: Michael J. Eager <eager@eagercon.com>

[gdb/tui] Fix segfault in tui_find_disassembly_address

PR29040 describes a FAIL for test-case gdb.threads/next-fork-other-thread.exp
and target board unix/-m32.

The FAIL happens due to the test executable running into an assert, which is
caused by a forked child segfaulting, like so:
...
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x00000000 in ?? ()
...

I tried to reproduce the segfault with exec next-fork-other-thread-fork, using
TUI layout asm.

I set a breakpoint at fork and ran to the breakpoint, and somewhere during the
following session I ran into a gdb segfault here in
tui_find_disassembly_address:
...
  /* Disassemble forward.  */
  next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
  last_addr = asm_lines.back ().addr;
...
due to asm_lines being empty after the call to tui_disassemble, while
asm_lines.back () assumes that it's not empty.

I have not been able to reproduce that segfault in that original setting, I'm
not sure of the exact scenario (though looking back it probably involved
"set detach-on-fork off").

What likely happened is that I managed to reproduce PR29040, and TUI (attempted
to) display the disassembly for address 0, which led to the gdb segfault.

When gdb_print_insn encounters an insn it cannot print because it can't read
the memory, it throws a MEMORY_ERROR that is caught by tui_disassemble.

The specific bit that causes the gdb segfault is that if gdb_print_insn throws
a MEMORY_ERROR for the first insn in tui_disassemble, it returns an empty
asm_lines.

FWIW, I did manage to reproduce the gdb segfault as follows:
...
$ gdb -q \
    -iex "set pagination off" \
    /usr/bin/rustc \
    -ex "set breakpoint pending on" \
    -ex "b dl_main" \
    -ex run \
    -ex "up 4" \
    -ex "layout asm" \
    -ex "print \$pc"
  ...
<TUI>
  ...
$1 = (void (*)()) 0x1
(gdb)
...
Now press <up>, and the segfault triggers.

Fix the segfault by handling asm_lines.empty () results of tui_disassemble in
tui_find_disassembly_address.

I've written a unit test that exercises this scenario.

Tested on x86_64-linux.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR tui/30823
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30823

Remove old gdb_bfd_openr_iovec

This removes the old gdb_bfd_openr_iovec entirely.  I think any new
code should use the type-safe approach.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert solib-rocm to new type-safe gdb_bfd_openr_iovec

This converts the solib-rocm BFD iovec implementations to the new
type-safe gdb_bfd_openr_iovec.  They were already essentially using
this approach, just without the type-safe wrapper.

Thanks to Lancelot Six for testing and fixing this patch.

Co-Authored-By: Lancelot Six <lancelot.six@amd.com>
Acked-by: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert minidebug to new type-safe gdb_bfd_openr_iovec

This converts the minidebug BFD iovec implementation to the new
type-safe gdb_bfd_openr_iovec.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert target fileio to new type-safe gdb_bfd_openr_iovec

This converts the target fileio BFD iovec implementation to use the
new type-safe gdb_bfd_openr_iovec.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert mem_bfd_iovec to new type-safe gdb_bfd_openr_iovec

This converts the mem_bfd_iovec / target_buffer code to use the new
type-safe gdb_bfd_openr_iovec.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Small constructor change to target_buffer

This changes the target_buffer constructor to initialize m_filename
rather than assign to it.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Introduce type-safe variant of gdb_bfd_openr_iovec

This patch adds a new, type-safe variant of gdb_bfd_openr_iovec.  In
this approach, the underlying user data is simply an object, the
callbacks are methods, and the "open" function is a function view.
Nothing uses this new code yet.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: use reopen_exec_file from reread_symbols

This commit fixes an issue that was discovered while writing the tests
for the previous commit.

I noticed that, when GDB restarts an inferior, the executable_changed
event would trigger twice.  The first notification would originate
from:

  #0  exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
  #1  0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122
  #2  0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682
  #3  0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192
  #4  0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125
  #5  0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609
  #6  0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761
  #7  0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593
  #8  0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924
  #9  0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328
  #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381
  #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
  #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

While the second originates from:

  #0  exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
  #1  0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517
  #2  0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398
  #3  0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
  #4  0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

In the first case the call to exec_file_attach first passes through
reopen_exec_file.  The reopen_exec_file performs a modification time
check on the executable file, and only calls exec_file_attach if the
executable has changed on disk since it was last loaded.

However, in the second case things work a little differently.  In this
case GDB is really trying to reread the debug symbol.  As such, we
iterate over the objfiles list, and for each of those we check the
modification time, if the file on disk has changed then we reload the
debug symbols from that file.

However, there is an additional check, if the objfile has the same
name as the executable then we will call exec_file_attach, but we do
so without checking the cached modification time that indicates when
the executable was last reloaded, as a result, we reload the
executable twice.

In this commit I propose that reread_symbols be changed to
unconditionally call reopen_exec_file before performing the objfile
iteration.  This will ensure that, if the executable has changed, then
the executable will be reloaded, however, if the executable has
already been recently reloaded, we will not reload it for a second
time.

After handling the executable, GDB can then iterate over the objfiles
list and reload them in the normal way.

With this done I now see the executable reloaded only once when GDB
restarts an inferior, which means I can remove the kfail that I added
to the gdb.python/py-exec-file.exp test in the previous commit.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: make the executable_changed event available from Python

This commit makes the executable_changed observable available through
the Python API as an event.  There's nothing particularly interesting
going on here, it just follows the same pattern as many of the other
Python events we support.

The new event registry is called events.executable_changed, and this
emits an ExecutableChangedEvent object which has two attributes, a
gdb.Progspace called 'progspace', this is the program space in which
the executable changed, and a Boolean called 'reload', which is True
if the same executable changed on disk and has been reloaded, or is
False when a new executable has been loaded.

One interesting thing did come up during testing though, you'll notice
the test contains a setup_kfail call.  During testing I observed that
the executable_changed event would trigger twice when GDB restarted an
inferior.  However, the ExecutableChangedEvent object is identical for
both calls, so the wrong information is never sent out, we just see
one too many events.

I tracked this down to how the reload_symbols function (symfile.c)
takes care to also reload the executable, however, I've split fixing
this into a separate commit, so see the next commit for details.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: pass more arguments to the executable_changed observer

This commit continues the work of the previous few commits.

My goal is to expose the executable_changed observer through the
Python API as an event.

At this point adding executable_changed as an event to the Python API
is trivial, but before I do that I would like to add some additional
arguments to the observable, which currently has no arguments at all.

The new arguments I wish to add are:

 1. The program_space in which the executable was changed, and

 2. A boolean flag that will indicate if the executable changed to a
 whole new path, or if GDB just spotted that the executable changed on
 disk (e.g. the user recompiled the executable).

In this commit I change the signature of the observable and then pass
the arguments through at the one place where this observable is
notified.

As there are (currently) no users of this observable nothing else
needs updating.  In the next commit I'll add a listener for this
observable in the Python code, and expose this as an event in the
Python API.

Additionally, with this change, it should be possible to update the
insight debugger to make use of this observable rather than using the
deprecated_exec_file_display_hook (as it currently does), which will
then allow this hook to be removed from GDB.

There should be no user visible changes after this commit.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove unnecessary notification of executable_changed observer

This commit continues the work of the previous two commits.

My goal, in the next couple of commits, is to expose the
executable_changed observable in the Python API as an event.  However,
before I do that I want to remove the use of the executable_changed
observable from the reread_symbols function in symfile.c as this use
isn't directly associated with a change of the executable file, and so
seems wrong.

In the previous two commits I have removed all users of the
executable_changed observer as I believe those users can, and should,
actually be listening for the new_objfile observable instead, so now
there are no users of the executable_changed observable.

As such, I think removing the use of executable_changed from the
function reread_symbols is perfectly safe, and correct.  At this point
the executable has not been changed, so we shouldn't be sending an
executable_changed notification, and, as there is nobody listening to
this observable, we can't break anything by removing this call.

There should be no user visible changes after this commit.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove final user of the executable_changed observer

This commit continues with the task started in the previous commit,
and is similar in many ways.

The goal of the next couple of commits is to expose the
executable_changed observable in the Python API as an event.  Before I
do this I would like to remove the additional call to the
executable_changed observable which can be found in the reread_symbols
function in the symfile.c file, as I don't believe that this use
actually corresponds to a change in the current executable.

The previous commit removed one user of the executable_changed
observable and replaced it with a new_obfile observer instead, and
this commit does the same thing.

In auxv.c we use the executable_changed observable to call
invalidate_auxv_cache, which then calls:

  invalidate_auxv_cache_inf (current_inferior ());

The auxv cache is already (additionally) cleared when an inferior
exits and when an inferior appears.

As with the previous commit, I think we can safely replace the use of
the executable_changed observable with a use of the new_obfile
observable.  All the tests still pass, and with some locally placed
printf calls, I think that the cache is still being cleared in all the
cases that should matter.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove one user of the executable changed observer

My goal for the next few commits is to expose the executable_changed
observable from the Python API.

However, there is call to the executable_changed observable in the
reread_symbols function (in symfile.c), and this doesn't actually
correspond to the executable changing.  My idea then, is to remove
this use of the executable_changed observable, but, before I can do
that, I need to check that nothing is going to break, and that
requires my to think about the current users of this observable.

One current user of executable_changed is in symtab.c.  We add an
executable_changed observer that calls:

  set_main_name (nullptr, language_unknown);

to discard all information about the main function when the executable
changes.

However, changing the executable doesn't actually change the debug
information.  The debug information changes when the symbol-file
changes, so I think this observer is in slightly the wrong place.

The new_objfile observable is (unfortunately) overloaded, it is called
when a new objfile is loaded, and also (when its argument is nullptr),
when all debug information should be discarded.

It turns out that there is already a new_objfile observer in
symtab.c.  I propose that, when the argument is nullptr (indicating
all debug info should be discarded), that we should call set_main_name
to discard the information about the main function.  We can then
remove the executable_changed observer from symtab.c.

All tests still pass, and, in my local world, I added some debug
printf calls, and I think we are still discarded the main information
everywhere we need to.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: new Progspace.executable_filename attribute

Add a new Progspace.executable_filename attribute that contains the
path to the executable for this program space, or None if no
executable is set.

The path within this attribute will be set by the "exec-file" and/or
"file" commands.

Accessing this attribute for an invalid program space will raise an
exception.

This new attribute is similar too, but not the same as the existing
gdb.Progspace.filename attribute.  If I could change the past, I'd
change the 'filename' attribute to 'symbol_filename', which is what it
actually represents.  The old attribute will be set by the
'symbol-file' command, while the new attribute is set by the
'exec-file' command.  Obviously the 'file' command sets both of these
attributes.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: new Progspace.symbol_file attribute

Add a new Progspace.symbol_file attribute.  This attribute holds the
gdb.Objfile object that corresponds to Progspace.filename, or None if
there is no main symbol file currently set.

Currently, to get this gdb.Objfile, a user would need to use
Progspace.objfiles, and then search for the objfile with a name that
matches Progspace.filename -- which should work just fine, but having
direct access seems a little nicer.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/doc: extend the description for Progspace.filename

Extend the description for Progspace.filename in the documentation to
mention what the returned string is actually the filename
for (e.g. that it is the filename passed to the 'symbol-file' or
'file' command).

Also document that this attribute will be None if no symbol file is
currently loaded.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/x86: use size of XSAVE area of enabled features

Since commit b42405a1594 ("gdb: Update x86 Linux architectures to
support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD
Ryzen 3700X machine:

    FAIL: gdb.base/gcore.exp: corefile restored all registers

The test gets the register state (saves the output of "info
all-registers"), saves a core with the "gcore" command, loads the core,
and checks the register state against the one previously saved.  The
problem is that when reading registers from the core file, the last half
of ymm registers is unavailable:

    (gdb) print $ymm0.v32_int8
    $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, <unavailable> <repeats 16 times>}

One strange thing with this machine is that the bitset of state
components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU",
but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX".  So, PKRU appears
to be supported by the processor, but disabled by the kernel.  I didn't
find why yet.

From CPUID leaf EAX=0Dh, ECX=00h, GDB can get:

 - from EBX: max size of the XSAVE area required by features currently
   enabled in XCR0.  On my machine, it's 0x340 (832).
 - from ECX: max size of the XSAVE area required by all features
   supported by XCR0.  On my machine, it's 0x380 (896).

At runtime, GDB uses ECX (max size required by all supported features)
to fill the x86_xsave_layout::sizeof_xsave.  So, when writing the core
file note for the XSAVE state, it writes a note of size 896, even though
it doesn't write the PKRU state.  When loading back the core, GDB tries
to figure out the layout of the XSAVE area based on what features are
enabled in XCR0 and the size of the note (the size of the XSAVE area).
Since my combination of XCR0 and size of XSAVE area doesn't match any
combination known by GDB, GDB falls back to a gdbarch supporting only
x87 and SSE.

This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave
field (and consequently the size of the XSAVE state note in core files)
using EBX, the size of the XSAVE area required by currently enabled
features in XCR0.  This makes i387_guess_xsave_layout recognize my case
with this condition:

  else if (HAS_AVX (xcr0) && xsave_size == 832)
    {
      /* Intel and AMD CPUs supporting AVX.  */
      layout.avx_offset = 576;
    }

In other words, just as if my machine didn't support PKRU at all.

Another reason why I think this change makes sense is that XSAVE state
notes in kernel-generated cores on this machine have size 832.  So this
change makes GDB-generated cores more similar to kernel-generated ones,
reducing the diversity of XSAVE state notes that GDB needs to be able to
figure out.

Note that if PKRU was enabled on my machine, then the effective XSAVE
area size would be 896 bytes.  We would need to add a case in
i387_guess_xsave_layout for that combination, since there is no
currently.  But I don't have a way to test that right now, since I don't
know why PKRU is disabled.

Relevant review note from John Baldwin:

  One further note is that the Linux x86 arches use x86_xsave_length()
  to infer ("guess") the size of the XSAVE register set that the Linux
  kernel writes out in core dumps.  On FreeBSD x86 arches, GDB is able
  to query this size directly from the kernel via ptrace.  My use of ECX
  for this guess earlier was just not the best guess.  In the case that
  the kernel enables all of the available features, then ECX and EBX
  have the same values, so this only matters for a system where the
  kernel has enabled a subset of available XSAVE extensions.

Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

Add support to readelf for the PT_OPENBSD_NOBTCFI segment type.