Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix gdb.Value.dynamic_type attribute

gdb currently crashes if you try to get the dynamic_type from a
gdb.Value of a POD struct:

(gdb) py print(gdb.parse_and_eval('pod').dynamic_type)
Fatal signal: Segmentation fault

It happens because value_rtti_type() returns NULL for them, and this is
not handled correctly.

Fixed by using val->type() as a fallback in this case.

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

gdb: Add i386-gnu-tdep to the list of objects for x86_64-*-gnu*

When starting GDB on Hurd amd64, one will currently see the following
warning:

  # gdb -q
  gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration
  of GDB.  Attempting to continue with the default i386 settings.
  (gdb)

This happens because, in gdb/configure.tgt, the "x86_64-*-gnu*" target
is not pulling in the i386-gnu-tdep.o object, which means that only
64-bit debugging is currently supported.

The fix here is to add i386-gnu-tdep.o to the gdb_target_obs for Hurd
amd64.

Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Suggested-by: Andrew Burgess <aburgess@redhat.com>
Reported-by: Mark Wielaard <mark@klomp.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33377
Approved-by: Kevin Buettner <kevinb@redhat.com>
(cherry picked from commit 3d22a6cee4b27866c544d67a82e2272ae4201f9e)

Automatic date update in version.in

gdb: Add svr4-tls-tdep.o to list of objects of i*86 targets

GDB currently fails to build from source on i386 if compiled with
--enable-64-bit-bfd.  This is happening because svr4-tls-tdep.o is
missing from the gdb_target_obs variable, while amd64-linux-tdep.o is
obviously there.

Fix the problem by adding svr4-tls-tdep.o to the object list, but only
when --enable-64-bit-bfd is provided.

Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33399
(cherry picked from commit b318480f27322c15c6b10c1bab4418e81d44b77e)

gdb/testsuite: small fix for amd64-extended-prologue-analysis.exp

I noticed I was sometimes getting this failure:

  FAIL: gdb.arch/amd64-extended-prologue-analysis.exp: offset \
      initialization: ASM source: gdb_breakpoint: set breakpoint \
      at *0x0000000000401151

The problem was introduced in commit:

  commit f9aa48dc545ef511e19f4dfab88a196b820fd2da
  Date:   Thu Aug 28 11:50:13 2025 +0000

      gdb, amd64: extend the amd64 prologue analyzer to skip register pushes

A gdb_test_multiple exits early when processing the results of a
'disassemble' command, without waiting for the prompt to be seen.
This can leave unhandled output in expect's input buffer, which will
then throw off the next test.

Update the gdb_test_multiple to wait for the prompt before declaring
the test passed.

After this I'm no longer seeing the above failure.

There should be no change in what is tested after this commit.

Automatic date update in version.in

Automatic date update in version.in

Bump GDB's version number to 17.0.90.DATE-git.

This commit changes gdb/version.in to 17.0.90.DATE-git.

Set GDB version number to 17.0.90.

This commit changes gdb/version.in to 17.0.90.

gdb/NEWS: Change "since GDB 16" into "in GDB 17"

Now that the major release version number is confirmed, we can adjust
the title of the corresponding section in the gdb/NEWS file.

Set development mode to "off" by default.

This is done by setting the "development" variable to "false"
in bfd/development.sh.

Bump version to 17.0.90.DATE-git.

Now that the GDB 17 branch has been created,
this commit bumps the version number in gdb/version.in to
17.0.90.DATE-git

For the record, the GDB 17 branch was created
from commit 46ada32fc979550ad4f46792b74c182bb7232aeb.

Update x86: Add GLIBC_ABI_GNU2_TLS version dependency

commit 0d1e88f8bfb0e62f37bf8a89172cd91373ace5e6
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 4 08:39:03 2025 +0800

    x86: Add GLIBC_ABI_GNU2_TLS version dependency

added solaris2-x86-64.em to accommodate moving x86-64 specific extra
emulation bits to elf-x86-64.em.  Update emulparams/elf_x86_64_sol2.sh
to use it.

* emulparams/elf_x86_64_sol2.sh (EXTRA_EM_FILE): Set to
"solaris2-x86-64".

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Re: tekhex test for commit bf0f85df1254

* testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): Correct
isremote to is_remote.

Automatic date update in version.in

bfd: configure.ac: Fix mention of flag to enable 64-bit BFD in comment

It was changed back in 1994.  Fixing because it misled me into using the
wrong flag in a build.

Allow conversion of 128-bit integers to Python

Currently, trying to convert a 128-bit integer from a gdb.Value to a
Python integer will fail.  This is surprising because Python uses
bigints internally.

The bug here is that valpy_long uses value_as_long, which fails for
anything wider than LONGEST.  This patch fixes the problem by using
the recommended Python API.

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

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 3

Fix fallout in gdb.base from erroring out on clean_restart
<absolute filename>.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 2

Manually fix the test-cases found by:
...
$ find gdb/testsuite/gdb.base -name *.exp* \
  | xargs grep -l 'clean_restart[^;]*binfile'
$ find gdb/testsuite/gdb.base -name *.exp* \
  | xargs grep -l 'prepare_for_testing.*bin'
...
except for gdb.base/foll-vfork.exp and gdb.base/solib-overlap.exp.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 1

Run:
...
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart $binfile$/\1clean_restart\n\1gdb_load $binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart ${binfile}$/\1clean_restart\n\1gdb_load $binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart $::binfile$/\1clean_restart\n\1gdb_load $::binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart ${::binfile}$/\1clean_restart\n\1gdb_load $::binfile/'
...

Revert the change in test-case gdb.base/foll-vfork.exp, which does
'set binfile $testfile'.

Tested on x86_64-linux.

The only modified test-case I was not able to test is
gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this).  The change
in the test-case is trivial though.

readelf: Handle 0 sh_entsize of GOT sections

Gold, lld and mold set sh_entsize to 0 on .got and .got.plt sections.
If sh_entsize of GOT sections is 0, assume 8 for ELFCLASS64 and 4 for
ELFCLASS32, except for x32 which uses 8.

PR binutils/33368
* readelf.c (process_got_section_contents): Handle 0 sh_entsize
of GOT sections.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Revert "MicroBlaze: Add microblaze_get_next_pcs"

This reverts commit c6df5d79aac5c4a77c06314fd26c837470360f70.

Causes buildbot failure. Bug 33381

gdb: ensure bp_location::section is set correct to avoid an assert

While reviewing and testing another patch I set a breakpoint on an
gnu ifunc function, then restarted the inferior, and this assert
triggered:

  ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed.

The backtrace at the time of the assert is:

  #6  0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747
  #7  0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=<optimized out>) at ../../src/gdb/objfiles.c:478
  #8  0x0000000000c38da6 in std::default_delete<objfile>::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81
  #9  0x0000000000c3782a in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292
  #10 0x0000000000caf1bd in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111
  #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192
  #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408
  #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729
  #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359
  #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466
  #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390
  #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514
  #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95
  #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827

The function breakpoint_free_objfile is being called when an objfile
representing a shared library is being unloaded ahead of the inferior
being restarted, the function is trying to remove references to
anything that could itself reference the objfile that is being
deleted.

The assert is making the claim that, for a bp_location, which has a
single address, the objfile of the symtab associated with the location
will be the same as the objfile associated with the section of the
location.

This seems reasonable to me now, as it did when I added the assert in
commit:

  commit 5066f3680667ec0f2d1745847a2372d85973a1e7
  Date:   Mon Nov 11 21:45:17 2024 +0000

      gdb: do better in breakpoint_free_objfile

The bp_location::section is maintained, according to the comments in
breakpoint.h, to aid overlay debugging (is that even used any more),
and looking at the code, this does appear to be the case.

The problem in the above case arises when we are dealing with an ifunc
function.  What happens is that we end up with a section from one
objfile, but a symtab from a different objfile.

This problem originates from minsym_found (in linespec.c).  The user
asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function.
What this means is that gnu_ifunc is actually a resolver function that
returns the address of the actual function to use.

In this particular test case, the resolver function is in a shared
library, and the actual function to use is in the main executable.

So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with
that name, and spots that this has type mst_text_gnu_ifunc.  GDB then
uses this to figure out the actual address of the function that will
be run.

GDB then creates the symtab_and_line using the _real_ address and the
symtab in which that address lies, in our case this will all be
related to the main executable objfile.

But, finally, in minsym_found, GDB fills in the symtab_and_line's
section field, and this is done using the section containing the
original minimal_symbol, which is from the shared library objfile.

The minimal symbol and section are then use to initialise the
bp_location object, and this is how we end up in, what I think, is an
unexpected state.

So what to do about this?

The symtab_and_line::msymbol field is _only_ set within minsym_found,
and is then _only_ used to initialise the bp_location::msymbol field.

The bp_location::msymbol field is _only_ used in the function
set_breakpoint_location_function, and we only really care about the
msymbol type, we check to see if it's an ifunc symbol or not.  This
allows us to set the name of the function correctly.

The bp_location::section is used, as far as I can tell, extensively
for overlay handling.  It would seem to me, that this section should
be the section containing the actual breakpoint address.  If the
question we're asking is, is this breakpoint mapped in or not?  Then
surely we need to ask about the section holding the breakpoint's
address, and not the section holding some other code (e.g. the
resolver function).  In fact, in a memory constrained environment,
you'd expect the resolver functions to get mapped out pretty early on,
but while the actual functions might still be mapped in.

Finally, symtab_and_line::section.  This is mostly set using calls to
find_pc_overlay.  The minsym_found function is one of the few places
where we do things differently.  In the places where the section is
used, it is (almost?) always used in conjunction with the
symtab_and_line::pc to lookup information, e.g. calls to
block_for_pc_sect, or find_pc_sect_containing_function.  In all these
cases, it appears to me that the assumption is that the section will
be the section that contains the address.

So, where does this leave us?

I think what we need to do is update minsym_found to just use
find_pc_overlay, which is how the symtab_and_line::section is set in
most other cases.  What this actually means in practise is that the
section field will be set to NULL (see find_pc_overlay in symfile.c).
But given that this is how the section is computed in most other
cases, I don't see why it should be especially problematic for this
case.  In reality, I think this just means that the section is
calculated via a call to find_pc_section when it's needed, as an
example, see lookup_minimal_symbol_by_pc_section (minsyms.c).

I do wonder if we should be doing better when creating the
symtab_and_line, and insist that the section be calculated correctly
at that point, but I really don't want to open that can of worms right
now, so I think just changing minsym_found to "do it just like
everyone else" should be good enough.

I've extended the existing ifunc test to expose this issue, the
updated test fails without this patch, and passes with.

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

gdb: pass core file to gdbarch_core_read_x86_xsave_layout

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method
'gdbarch_core_read_x86_xsave_layout' to take the core file BFD as a
reference parameter.  For now this just moves the
'current_program_space->core_bfd ()' calls up the program stack into
core_target::fetch_x86_xsave_layout.  In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

gdb: pass core file to gdbarch_core_thread_name method

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method 'gdbarch_core_thread_name'
to take the core file BFD as a reference parameter.  For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::thread_name.  In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

gdb: pass core file through gdbarch API when loading shared libraries

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates two gdbarch methods:

  gdbarch_core_xfer_shared_libraries
  gdbarch_core_xfer_shared_libraries_aix

to take the core file BFD as a reference parameter.  For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::xfer_partial.  In the future I plan to move
the core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

[gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-native

When running test-case gdb.base/fileio.exp with host/target board
local-remote-host-native I run into:
...
gdb compile failed, fileio.c: In function 'test_open':
<command-line>:0:8: error: expected expression before '.' token
fileio.c:89:15: note: in expansion of macro 'OUTDIR'
   ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR);
               ^~~~~~
...

Fix this by using:
- quote_for_host to pass -DOUTDIR to the compilation, and
- STRINGIFY to stringify OUTDIR in fileio.c.

Tested on x86_64-linux, with target board unix and host/target board
local-remote-host-native.

MicroBlaze: Add microblaze_get_next_pcs

This patch enables software single stepping for gdbserver target

* gdb/microblaze-tdep.c: Add microblaze_get_next_pcs

Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com>
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Fix clean_restart <absolute filename> in allow_aarch64_sme_tests

Fix fallout on aarch64-linux with test-case
gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on
clean_restart <absolute filename>.

[gdb/testsuite] Fix silent timeout in allow_aarch64_gcs_tests

I noticed on M1 aarch64-linux that test-case
gdb.testsuite/gdb-caching-proc-consistency.exp took a long time.

I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests.

This gdb_expect only handles the case that gcs support is detected:
...
    gdb_expect {
        -re ".*$inferior_exited_re normally.*${gdb_prompt} $" {
            verbose -log "\n$me: gcs support detected"
            set allow_gcs_tests 1
        }
    }
...
but in my case, I get:
...
(gdb) run ^M
Starting program: allow_aarch64_gcs_tests.x ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Inferior 1 (process 3336556) exited with code 01]^M
(gdb)
...
so the gdb_expect times out quietly, taking 10 seconds.

In the test-case, it does so 11 times.

Fix this by adding a gdb_expect clause handling the "with code 01" case.

Tested on aarch64-linux.

PR testsuite/33378
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33378

x86: check reloc types for relaxable branches

Bypassing _reloc() isn't a good idea, as there are various errors
checked for there. For example 16-bit JMP or Jcc may not use the @plt
form (resulting in a 32-bit relocation to be emitted for a 16-bit
field), which so far we only reject for 16-bit CALL. In exchange this
allows simplifying the setting up of the "reloc_type" local variable.

x86: make reloc() usable during late phases of assembly

Introduce a clone with extra parameters, to allow subsequent use from
md_estimate_size_before_relax() (or elsewhere, should that turn out
necessary). There flag_code cannot be used and location information
needs to be provided for diagnostics.

gdb: run black on gdbarch_components.py

Change-Id: Ifcf80faa240c7c235bfea4ddc79f0d6c39858c5e

Automatic date update in version.in

GDB: aarch64-linux: Define HWCAP_GCS as unsigned long long value

On platforms where long is 32 bits, this change fixes a build failure:

/home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c: In function ‘const target_desc* aarch64_linux_core_read_description(gdbarch*, target_ops*, bfd*)’:
/home/linux/arm/gdb/src/gdb/arch/aarch64-gcs-linux.h:27:24: error: left shift count >= width of type [-Werror=shift-count-overflow]
   27 | #define HWCAP_GCS (1UL << 32)
      |                    ~~~~^~~~~
/home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c:1714:47: note: in expansion of macro ‘HWCAP_GCS’
 1714 |   features.gcs = features.gcs_linux = hwcap & HWCAP_GCS;
      |                                               ^~~~~~~~~

Suggested-by: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33372

gdb/testsuite: revert recent changes to gdb.dap/scopes.exp

After the previous commit, the changes to gdb.dap/scopes.exp from the
commit:

  commit 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4
  Date:   Fri Mar 29 16:38:50 2019 +0100

      gdb, gdbserver: Add support of Intel shadow stack pointer register.

Are no longer needed, the test will now happily handle the shadow
stack pointer being unavailable.

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

Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>

gdb/dap: check values are available before converting to int

In VariableReference.to_object, we try to convert a gdb.Value to an
int without checking if the value is actually available.  This came to
light in PR gdb/33345, after the x86 CET shadow stack patches were
merged.

If the x86 CET shadow stack register is available on the machine,
but the shadow stack feature is not enabled at run time, then the
register will show as "<unavailable>".

As the register is of type 'void *', then in the DAP code we try to
add a 'memoryReference' attribute with the value of the register
formatted as hex.  This will fail if the register is unavailable.

To test this change you'll need:

  (a) a machine which support the shadow stack feature, and

  (b) to revert the changes from commit 63b862be762e1e6e7 in the file
      gdb.dap/scopes.exp.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>

gdb/python: add gdb.Value.is_unavailable attribute

Add a new gdb.Value.is_unavailable attribute.  This is similar to the
existing Value.is_optimized_out attribute, but returns True if any
part of the value is <unavailable>.

The existing Value.is_optimized_out attribute returns true if any part
of the value is optimized out, so I thought that Value.is_unavailable
should work the same way.

There's also a test.

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

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>

gdb, amd64: return after amd64_analyze_register_saves if current_pc reached

Make sure the function bails out early if CURRENT_PC is reached, to
avoid the call to amd64_analyze_stack_alloc.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb, amd64: extend the amd64 prologue analyzer to skip stack alloc

Following the previous patch (gdb, amd64: extend the amd64 prologue
analyzer to skip register pushes), this patch extends the analyzer
further to be able to skip stack space allocation as the next prologue
part, for functions with a frame pointer.  Implementation was based
on the i386 counterpart, which already had that functionality.

As of now, the stack allocation is not skipped.  Examples below use C
source listed below, compiled with gcc 11.4.0.
```
int foo (int n)
{
    int ns[] = { 1, 4, 9, 16, 25 };
    return ns[n];
}

int
main (int argc, char **argv)
{
    return foo (argc);
}
```

Compiling with "gcc -O0 -fno-omit-frame-pointer" we get:
```
(gdb) b foo
Breakpoint 1 at 0x1151
(gdb) r
...
Breakpoint 1, 0x0000555555555151 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
   0x0000555555555149 <+0>:     endbr64
   0x000055555555514d <+4>:     push   %rbp
   0x000055555555514e <+5>:     mov    %rsp,%rbp
=> 0x0000555555555151 <+8>:     sub    $0x30,%rsp
   0x0000555555555155 <+12>:    mov    %edi,-0x24(%rbp)
...
```

With this patch, it gets skipped the same way register pushes are:
```
(gdb) b foo
Breakpoint 1 at 0x1155
(gdb) r
...
Breakpoint 1, 0x0000555555555155 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
   0x0000555555555149 <+0>:     endbr64
   0x000055555555514d <+4>:     push   %rbp
   0x000055555555514e <+5>:     mov    %rsp,%rbp
   0x0000555555555151 <+8>:     sub    $0x30,%rsp
=> 0x0000555555555155 <+12>:    mov    %edi,-0x24(%rbp)
...
```

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb, amd64: return after amd64_analyze_frame_setup if current_pc reached

Make sure the function bails out early if CURRENT_PC is reached, to
avoid the call to amd64_analyze_register_saves.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb, amd64: extend the amd64 prologue analyzer to skip register pushes

A typical function's prologue can consist of setting up a frame pointer,
pushing registers onto the stack and allocating space on the stack.
Current amd64 prologue analyzer would stop after the frame setup.
This patch allows GDB to skip past register pushes, while also improving
unwinding pushed registers, for functions with a frame pointer, without
debug info and .cfi directives found in .eh_frame section that are used
for unwinding.  Skipping register pushes was also present for i386
targets before - the proposed changes are based on i386 implementation.

It also improves the unwinding even if .cfi directives are present,
because GDB can only unwind a register if it has reached a corresponding
.cfi directive, which won't be there before the pushes.

Additionally, at least gcc 11.4 and later by default doesn't emit
necessary debug info, which GDB would try to use to find prologue's end.
In that case, extended prologue analyzer would take effect.

Using C source listed below as an example, compiled with gcc 11.4.0:
```
int __attribute__ ((noinline))
bar (int a)
{
    return a + a;
}

int __attribute__ ((noinline))
foo (int a, int b, int c, int d, int e)
{
    int x = bar (a) + bar (b) + bar (c) + bar (d) + bar (e);
    return x;
}

int
main (int argc, char **argv)
{
    return foo (1, 2, 3, 4, 5);
}
```

Compiling with "gcc -O1 -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables", we get:
```
(gdb) b foo
Breakpoint 1 at 0x1139
(gdb) r
...
Breakpoint 1, 0x0000555555555139 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
   0x0000555555555131 <+0>:     endbr64
   0x0000555555555135 <+4>:     push   %rbp
   0x0000555555555136 <+5>:     mov    %rsp,%rbp
=> 0x0000555555555139 <+8>:     push   %r15
   0x000055555555513b <+10>:    push   %r14
   0x000055555555513d <+12>:    push   %r13
   0x000055555555513f <+14>:    push   %r12
   0x0000555555555141 <+16>:    push   %rbx
   0x0000555555555142 <+17>:    sub    $0x8,%rsp
   0x0000555555555146 <+21>:    mov    %esi,%r15d
...
(gdb) ni
0x000055555555513b in foo ()
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1  0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 1234
```

With the proposed changes, breakpoint gets past those register pushes:
```
(gdb) b foo
Breakpoint 1 at 0x1142
(gdb) r
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
   0x0000555555555131 <+0>:     endbr64
   0x0000555555555135 <+4>:     push   %rbp
   0x0000555555555136 <+5>:     mov    %rsp,%rbp
   0x0000555555555139 <+8>:     push   %r15
   0x000055555555513b <+10>:    push   %r14
   0x000055555555513d <+12>:    push   %r13
   0x000055555555513f <+14>:    push   %r12
   0x0000555555555141 <+16>:    push   %rbx
=> 0x0000555555555142 <+17>:    sub    $0x8,%rsp
   0x0000555555555146 <+21>:    mov    %esi,%r15d
...
```

Also, unwinding pushed registers now works:
```
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
   0x0000555555555131 <+0>:     endbr64
   0x0000555555555135 <+4>:     push   %rbp
   0x0000555555555136 <+5>:     mov    %rsp,%rbp
   0x0000555555555139 <+8>:     push   %r15
   0x0000555555555139 <+8>:     push   %r15
   0x000055555555513b <+10>:    push   %r14
   0x000055555555513d <+12>:    push   %r13
   0x000055555555513f <+14>:    push   %r12
   0x0000555555555141 <+16>:    push   %rbx
=> 0x0000555555555142 <+17>:    sub    $0x8,%rsp
   0x0000555555555146 <+21>:    mov    %esi,%r15d
...
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1  0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 140737354125376
```

Additionally a new test was added to verify this behavior.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Don't require "Bss=" in qOffsets response

The "Bss=" part of the qOffsets response is documented as being
optional, but gdb in fact requires it.  This patch fixes the bug.

I couldn't find a straightforward way to test this.  gdbserver does
send 'Bss=' -- but this code is only enabled for a fairly specific
setup:

    #if (defined(__UCLIBC__) \
 && defined(HAS_NOMMU) \
 && defined(PT_TEXT_ADDR) \
 && defined(PT_DATA_ADDR) \
 && defined(PT_TEXT_END_ADDR))
    #define SUPPORTS_READ_OFFSETS
    #endif

I also considered changing gdbserver to not send Bss=, but decided
against this, reasoning that we may as well not break compatibility
with older versions of gdb.

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

gdb/testsuite: fix possible TCL errors in gdb.threads/threadcrash.exp

The test gdb.threads/threadcrash.exp, among other things, creates a list
of the threads seen in the order that the "thread apply all backtrace"
would generate them, tests that this list is the same size as GDB's
count of threads, and then loops over the list to check that each
thread has the expected backtrace.

A problem occurs because the loop iterates on GDB's internal count of
threads, rather than the size of the list, but then attempts to acces
the n-th element of the list. If the list size is smaller than GDB's
internal thread count, it'll access past the end of the list and
generate TCL errors.

This commit fixes this by using the list's length instead.

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

gdb: remove most global core file accesses from fbsd-tdep.c

This commit removes many places in fbsd-tdep.c where we access the
current core file via current_program_space, and replaces these
accesses with a function argument that is passed in.

There are still two uses of 'current_program_space->core_bfd ()' in
the file, these will be addressed in future work (not in this series
though).

There should be no user visible changes after this commit.

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

gdb: pass core file to gdbarch_core_xfer_siginfo

Another patch that aims to remove 'current_program_space->core_bfd ()'
from GDB.  This time I'm passing the core file BFD as an argument to
the gdbarch method gdbarch_core_xfer_siginfo.

In corelow.c the core file is being passed, this does introduce a new
instance of 'current_program_space->core_bfd ()', but this is OK.  My
long term plan is to move the core bfd into core_target, in which case
the call to gdbarch_core_xfer_siginfo will have access to the core bfd
as a member variable.

For now though, this patch moves the accesses via global state up the
call stack, and consolidates the two calls from fbsd-tdep.c and
linux-tdep.c into the one call in corelow.c.

There should be no user visible changes after this commit.

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

gdb: remove most global core file accesses from record-full.c

This commit continues my ongoing work to reduce the number of global
accesses to the current core file BFD in GDB.  The global accesses I'm
working on removing look like 'current_program_space->core_bfd ()'.

This commit targets record-full.c.  All global accesses are removed
except for two in record_full_open, which is used to implements the
two commands 'target record-full' and 'record full restore'.

All other global accesses to the core file are removed by passing the
core file through as an argument from this one top level function.

As I followed the code through I noticed that record_full_restore,
which currently includes this check:

  if (current_program_space->core_bfd () == nullptr)
    return;

could never actually be called without a core file being set.  As the
argument is now 'struct bfd &', then there is no longer an option for
the incoming argument to be NULL, and the above check is removed.

There should be no user visible changes after this commit.

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

gdb: remove some dead code from core_target_open

In core_target_open we call target_preopen which pops all targets
above the file_stratum, this will include the core_target, if the core
target is currently loaded.

Currently, the core file BFD is stored in the program_space of an
inferior.  The only way to set the core file BFD is by creating a
core_target (in core_target_open).  And when a core_target is closed
the core file BFD within the program_space is reset to nullptr (see
core_target::close and core_target::clear_core, both in corelow.c).

What this means is that, if there is no core_target loaded then there
will be no core file BFD in the program_space.  And in
core_target_open, after the call to target_preopen, there will be no
core_target loaded, and thus, no core file BFD in the program_space.

There is currently code in core_target_open which checks to see if
there is a core file BFD set in the current program space.  For the
reasons given above, I believe this is dead code and can be removed.

I've added some asserts to validate my assumptions.

There should be no user visible changes after this commit.

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

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/*.exp

Fix clean_restart <absolute filename> in gdb.arch/*.exp.

The fixed test-cases are supported on archs sh, ia64, mips, pa and sparc.

I haven't tested these.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/powerpc*.exp

Fix clean_restart <absolute filename> in gdb.arch/powerpc*.exp.

Likewise in gdb.arch/ppc*.exp, gdb.arch/altivec*.exp, gdb.arch/e500*.exp and
gdb.arch/vsx*.exp.

Tested on ppc64le-linux.

The following test-cases only run on 32-bit ppc:
- gdb.arch/e500-abi.exp
- gdb.arch/e500-prologue.exp
- gdb.arch/e500-regs.exp
- gdb.arch/powerpc-aix-prologue.exp
- gdb.arch/powerpc-prologue.exp
- gdb.arch/powerpc-prologue-frame.exp
- gdb.arch/powerpc-trap.exp
so these haven't been tested.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/thumb*.exp

Fix clean_restart <absolute filename> in gdb.arch/thumb*.exp.

Likewise in test-case gdb.arch/pr25124.exp.

Tested on arm-linux, target boards unix/-marm and unix/-mthumb.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/arm*.exp

Fix clean_restart <absolute filename> in gdb.arch/arm*.exp.

Tested on:
- arm-linux, target boards unix/-marm and unix/-mthumb
- aarch64-linux

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp

Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp.

Tested on aarch64-linux, M1 system.

There's a large number (44) of unsupported, for the following reasons:
- allow_aarch64_gcs_tests
- allow_aarch64_mops_tests
- allow_aarch64_sve_tests / target does not support SVE
- memory tagging unsupported

Consequently, we mostly use the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/i386*.exp

Fix clean_restart <absolute filename> in gdb.arch/i386*.exp.

Tested on x86_64-linux, with target board unix/-m32 and gcc 15.

The only unsupported test-case is gdb.arch/i386-avx512.exp, which isn't
changed by this commit.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/amd64*.exp

Fix clean_restart <absolute filename> in gdb.arch/amd64*.exp.

Tested on x86_64-linux, with kernel version 6.16.3.

The only unsupported test-case is gdb.arch/amd64-lam.exp, which isn't changed
by this commit.

RISC-V: Don't generate R_RISCV_RELATIVE if symbol referenced section is SH_ABS

It's werid if it's absolute symbol but have a relative reloc for got entry
under pie.  So don't generate relative reloc if symbol referenced section is
SH_ABS.  However, x86 allows the absolute symbol defined in linker script has
a relative reloc, not sure if risc-v needs this or not.

RISC-V: Don't overwrite got entry to zero for IRELATIVE/RELATIVE relocation

Even the final result is correct since we encode the relocation into r_addend,
so glibc won't need to get the content of got entry when resolving relative
relocation, it still werid that finish_dynamic_symbol cleans what we filled in
the relocate_section.

RISC-V: Fixed missed GOT relocation against a symbol that has a defined value

SImilar to aarch64, commit eac4eb8ecb26

There are two problems when GOT relocation against a symbol that has a defined
value,
1. Pesudo la with pic and pseudo lga lost the relocations.
2. %got_pcrel_hi generates R_RISCV_GOT_HI20 with addend, which is wrong since
   commit 50331d64f108.

The solution is to use deferred_expression for GOT relocation.  Maybe other
relocations also have same problem and need the deferred_expression, but we can
add in the future patches.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.ada

Fix clean_restart <absolute filename> in the test-cases in gdb.ada.

Tested on x86_64-linux with gcc 14.

Automatic date update in version.in

PR 33360, Correct strings -Ue output

Signed-off-by: Andrew C Aitchison <andrew@aitchison.me.uk>

mips: remove unnecessary obstack_finish

It isn't necessary to call obstack_finish before obstack_free of an
unwanted string.

* config/tc-mips.c (mips_parse_arguments): Replace obstack_finsih
with obstack_base.

gdb/testsuite] Fix clean_restart <absolute filename> in gdb.compile

Fix clean_restart <absolute filename> in the test-cases in gdb.compile.

Tested on x86_64-linux, fedora rawhide.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.cp

Fix clean_restart <absolute filename> in the test-cases in gdb.cp.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.debuginfod

Fix clean_restart <absolute filename> in the test-cases in gdb.debuginfod.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.disasm

Fix clean_restart <absolute filename> in the test-cases in gdb.disasm.

The changed test-cases:
- gdb.disasm/am33.exp
- gdb.disasm/hppa.exp
- gdb.disasm/mn10300.exp
- gdb.disasm/sh3.exp
are unsupported for me, but the changes are trivial.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.dwarf2

Fix clean_restart <absolute filename> in the test-cases in gdb.dwarf2.

Tested on x86_64-linux using gcc-14.

Tested these test-cases on x86_64-linux with target board unix/-m32:
- gdb.dwarf2/valop.exp
- gdb.dwarf2/callframecfa.exp
- gdb.dwarf2/implptr.exp
- gdb.dwarf2/watch-notconst.exp
- gdb.dwarf2/pieces.exp
- gdb.dwarf2/pieces-optimized-out.exp

Tested these test-cases on x86_64-linux with target board fission-dwp:
- gdb.dwarf2/dwp-symlink.exp
- gdb.dwarf2/dwp-sepdebug.exp

Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a
too strict home directory check, see PR testsuite/33364.

readelf: Don't change the symbol table

1. Update dump_relr_relocations not to change the symbol table.
2. Update count_relr_relocations and dump_relr_relocations not to
retrieve the same data twice.

binutils/

PR binutils/33328
* readelf.c (count_relr_relocations): Add an argument to return
the retrieved data and remove the FIXME in comments.
(dump_relr_relocations): Add an argument for the retrieved data.
Retrieve the data if needed.  Don't change the symbol table and
remove the FIXME in comments.
(display_relocations): Get the data from count_relr_relocations
and pass it to dump_relr_relocations call.
(process_relocs): Pass NULL to dump_relr_relocations.

ld/

PR binutils/33328
* testsuite/ld-i386/dt-relr-2.d: New file.
* testsuite/ld-i386/dt-relr-2.s: Likewise.
* testsuite/ld-x86-64/dt-relr-2-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.s: Likewise.
* testsuite/ld-i386/i386.exp: Run dt-relr-2.
* testsuite/ld-x86-64/x86-64.exp: Run dt-relr-2 and dt-relr-2-x32.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.fortran

Fix clean_restart <absolute filename> in the test-cases in gdb.fortran.

Tested on x86_64-linux, with gcc 14.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.gdb

Fix clean_restart <absolute filename> in the test-cases in gdb.gdb.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.guile

Fix clean_restart <absolute filename> in the test-cases in gdb.guile.

Tested on x86_64-linux.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.linespec

Fix clean_restart <absolute filename> in the test-cases in gdb.linespec.

Tested on x86_64-linux.

[gdb/testsuite] Fix mi_clean_restart <absolute filename> in gdb.mi

Fix mi_clean_restart <absolute filename> in the test-cases in gdb.mi.

Tested on x86_64-linux.

Also tested test-case gdb.mi/mi-dprintf.exp with target boards
native-gdbserver and native-extended-gdbserver.

Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't
test the trivial change in that test-case.

[gdb/testsuite] Fix mi_clean_restart <absolute filename> in gdb.trace

Fix mi_clean_restart <absolute filename> in the test-cases in gdb.trace.

Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.

gdb: LoongArch: Restrict breakpoint outside of atomic sequence

We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there,
it has been handled in the commit 208b57e53ed9 ("gdb: LoongArch:
Deal with atomic sequence").

Especially, maybe there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
current pc + 4 which is inside the atomic sequence, it should not
put a breakpoint in its destination address in this case, this has
been handled in the commit a4242dc3f5fa ("gdb: LoongArch: Improve
the handling of atomic sequence").

Additionally, if there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
not current pc + 4 but still inside the atomic sequence, it should
not put a breakpoint in its destination address in this case.

So in order to avoid putting a breakpoint in the middle of a ll/sc
atomic sequence in any case, just look for the start and end of the
sequence, and restrict the breakpoint outside of the atomic sequence.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add and use cond_branch_destination_address()

In the current loongarch_deal_with_atomic_sequence(), it is just a loop
through a ll/sc atomic instruction sequence, the instructions before the
condition branch are not actually executed, thus the condition register
value is not proper to determine the destination address.

Add a new function cond_branch_destination_address() to calculate the
destination address of a condition branch instruction under an assumed
true condition, then only put a breakpoint at this address when it is
outside of the ll/sc atomic instruction sequence.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.multi

Fix clean_restart <absolute filename> in the test-cases in gdb.multi.

Tested on x86_64-linux.

x86: Check plt_got_offset for lazy IBT PLT

Lazy IBT PLT entries look like

static const bfd_byte elf_i386_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] =
{
  0xf3, 0x0f, 0x1e, 0xfb,       /* endbr32                    */
  0x68, 0, 0, 0, 0,             /* pushl immediate            */
  0xe9, 0, 0, 0, 0,             /* jmp relative               */
  0x66, 0x90                    /* xchg %ax,%ax               */
};

static const bfd_byte elf_x86_64_lazy_ibt_plt_entry[LAZY_PLT_ENTRY_SIZE] =
{
  0xf3, 0x0f, 0x1e, 0xfa,       /* endbr64                    */
  0x68, 0, 0, 0, 0,             /* pushq immediate            */
  0xe9, 0, 0, 0, 0,             /* jmpq relative              */
  0x66, 0x90                    /* xchg %ax,%ax               */
};

They only have

unsigned int plt_reloc_offset;  /* ... offset into relocation table. */

and don't have

unsigned int plt_got_offset;    /* ... address of this symbol in .got. */

We should use plt_reloc_offset, not plt_got_offset, to check IBT PLT.

PR binutils/33358
* elf32-i386.c (elf_i386_get_synthetic_symtab): Check
plt_reloc_offset for lazy IBT PLT.
* elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

readelf: Run --got-contents only on ET_DYN/ET_EXEC files

Update "readelf --got-contents" to skip on non-ET_DYN/ET_EXEC files.

* readelf.c (process_got_section_contents): Skip if not
ET_DYN/ET_EXEC files.
* testsuite/binutils-all/readelf-got.d: Removed.
* testsuite/binutils-all/readelf.exp: Don't run readelf-got.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.objc

Fix clean_restart <absolute filename> in the test-cases in gdb.objc.

Tested on x86_64-linux, using 'lappend options "nowarnings"' in
gdb_compile_shlib_pthreads.  See also PR testsuite/24807.

readelf: Call qsort only if all_relocations_count > 1

Don't call qsort if all_relocations_count < 1.

PR binutils/33351
* readelf.c (process_got_section_contents): Call qsort only if
all_relocations_count > 1.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

[gdb/testsuite] Fix clean_restart in gdb.opencl/callfuncs.exp

In test-case gdb.opencl/callfuncs.exp I noticed:
...
clean_restart [standard_testfile $testfile]
...

This doesn't have the desired effect of starting gdb with $testfile because
standard_testfile doesn't return anything.

Fix this by using "clean_restart $testfile".

While we're at it:
- move standard_testfile to the start of the file
- drop the redundant 'set testfile "callfuncs"'
- use standard_testfile .cl to properly define $srcfile
- use $srcfile instead of $testfile.cl

Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363.

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

gdb/testsuite: Fix gdb.base/gcore-memory-usage with address sanitizer

The test gdb.base/gcore-memory-usage is meant to show that the memory
requirements of GDB's gcore command don't grow with the memory usage
of the inferior.  It was using hardcoded values for memory, but the
values were too small when building GDB with address sanitizer.  This
commit fixes one of the failures by increasing the limit on the first
gcore call.

But, rather than just increasing the hardcoded limit for the second
call, we instead save the amount of memory used in the first call and
ensure that the second call doesn't use more memory than the first.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148
Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.opt

Fix clean_restart <absolute filename> in the test-cases in gdb.opt.

Tested on x86_64-linux using gcc 14.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.perf

Fix clean_restart <absolute filename> in the test-cases in gdb.perf.

Tested on x86_64-linux using check-perf.

[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.python

Fix clean_restart <absolute filename> in the test-cases in gdb.python.

Tested on x86_64-linux.

Disable eh_frame optimisation if code detected in .eh_frame

Fuzzers stress the assembler in ways no sane programmer would ever do.
One x86 oss-fuzz testcase (cleaned up a litte) was:
 .sect .debug_frame
 call x
 .long x,0
 .space 1
 .long 0,0
The call insn leaves the frag data corresponding to a CIE
uninitialised until later in assembly, leading to reports of
uninitialised data access in ehopt.c:check_eh_frame.

Hack around this problem by noticing an insn has been assembled in
dwarf2_emit_insn.  The existing frag has_code can't be used as that
leads to alignment complaints, so add a new segment_info flag.

* subsegs.h (struct segment_info_struct): Move bss and hadone
later.  Rename hadone to stab_seen.  Add insn_seen bitfield.
* dwarf2dbg.c (dwarf2_emit_insn): Set insn_seen.
* ehopt.c (check_eh_frame): Disable optimisation if insn_seen.
* stabs.c (s_stab_generic): Adjust for hadone rename.

frag_alloc use of obstack_alloc

Avoid the alignment hackery necessary when obstack_alloc is used.
obstack_alloc expands to obstack_blank plus obstack_finish, and the
latter call is where alignment of the tail of the obstack happens.

The docs say obstack_alloc "is invoked almost like malloc", which
implies a fixed size allocation and you don't need other obstack calls
in its use.  So I think trying to use obstack_alloc in frag_alloc was
always a poor choice.

* frags.c (frag_alloc): Replace obstack_alloc with obstack_blank.

Explain frag alignment hacks

"the weird alignment hackery" comment doesn't help anyone understand
the code.  Explain what is going on.  Replace the zero length
obstack_alloc with obstack_finish, which by inspection of obstack.h is
all the zero length alloc does.

* frags.c (frag_alloc): Comment.  Replace zero length
obstack_alloc with obstack_finish.
(frag_new): Remove unnecessary obstack_finish.
* write.c (compress_frag, compress_debug): Likewise.

make frag fr_type a bitfield

For better packing of struct frag.

* frags.h (struct frag <fr_type>): Use ENUM_BITFIELD.

tidy tilegx and tilepro MAX_MEM_FOR_RS_ALIGN_CODE

These weren't wrong, but should use the BUNDLE_SIZE macros, in case
they ever change.

* config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEGX_BUNDLE_SIZE_IN_BYTES.
* config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEPRO_BUNDLE_SIZE_IN_BYTES.

visium MAX_MEM_FOR_RS_ALIGN_CODE

Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for
the "fix" amount emitted by visium_handle_align.  This didn't show up
as a problem due to frag alignment hiding the error, until I started
messing with struct frag.

* config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Correct.

csky disassembler leak

* csky-dis.c (parse_csky_dis_options): Free copy of options.