Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/tui: use wrefresh if output is not surpressed

Recent work in the TUI has improved GDB's use of the curses
wnoutrefresh and doupdate mechanism, which improves performance by
batching together updates and then doing a single set of writes to the
screen when doupdate is finally called.

The tui_batch_rendering type is a RAII class which, in its destructor,
calls doupdate to send the batched updates to the screen.

However, if there is no tui_batch_rendering active on the call stack
then any wnoutrefresh calls will remain batched but undisplayed until
the next time doupdate happens to be called.

This problem can be seen in PR gdb/32623.  When an inferior is started
the 'Starting program' message is not immediately displayed to the
user.

The 'Starting program' message originates from run_command_1 in
infcmd.c, the message is sent to the current_uiout, which will be the
TUI ui_out.  After the message is sent, ui_out::flush() is called,
here's the backtrace when that happens:

  #0  tui_file::flush (this=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
  #1  0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at ../../src/gdb/utils.c:1531
  #2  0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at ../../src/gdb/utils.c:1539
  #3  0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at ../../src/gdb/cli-out.c:250
  #4  0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at ../../src/gdb/ui-out.h:263
  #5  0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
  #6  0x00000000009f599a in run_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:511

And if we check out tui_file::flush (tui-file.c) we can see that this
just calls tui_win_info::refresh_window(), which in turn, just uses
wnoutrefresh to batch any pending output.

The problem is that, in the above backtrace, there is no
tui_batch_rendering active, and so there will be no doupdate call to
flush the output to the screen.

We could add a tui_batch_rendering into tui_file::flush.  And
tui_file::write.  And tui_file::puts .....

... but that all seems a bit unnecessary.  Instead, I propose that
tui_win_info::refresh_window() should be changed.  If suppress_output
is true (i.e. a tui_batch_rendering is active) then we should continue
to call wnoutrefresh().  But if suppress_output is false, meaning that
no tui_batch_rendering is in place, then we should call wrefresh(),
which immediately writes the output to the screen.

Testing but PR gdb/32623 was a little involved.  We need to 'run' the
inferior and check for the 'Starting program' message.  But DejaGNUU
can only check for the message once it knows the message should have
appeared.  But, as the bug is that output is not displayed, we don't
have any output hints that the inferior is started yet...

In the end, I have the inferior create a file in the test's output
directory.  Now DejaGNU can send the 'run' command, and wait for the
file to appear.  Once that happens, we know that the 'Starting
program' message should have appeared.

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

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

Automatic date update in version.in

[gdb/corefiles] Fix segfault in core_target_open

On x86_64-freebsd, with test-case gdb.arch/i386-biarch-core.exp I run into a
segfault here in corelow.c:core_target_open:
...
    {
      gdb::unique_xmalloc_ptr<char> failing_command = make_unique_xstrdup
        (bfd_core_file_failing_command (current_program_space->core_bfd ()));
      if (failing_command != nullptr)
        gdb_printf (_("Core was generated by `%s'.\n"),
                    failing_command.get ());
    }
...
where bfd_core_file_failing_command returns nullptr, so the segfault happens
somewhere during "strdup (nullptr)".

There doesn't seem to be a need to make a copy of the string, so fix this by
dropping the make_unique_xstrdup.

Tested on x86_64-linux.
Tested the test-case on x86_64-freebsd.

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

(cherry picked from commit 9dd3d66b79a2907726f407039234ad8677e9df16)

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

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

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

This commit also makes the following changes in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_minor to 3.

Set GDB version number to 16.2.

This commit changes gdb/version.in to 16.2.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: include cli/cli-style.h in darwin-nat.c

PR 32610 says:

  File gdb/darwin-nat.c is missing an #include statement of
  "cli/cli-style.h". It is needed because there is a reference to class
  object command_style in the .c file.

I'm not able to build-test this change (I only have access to arm64
macos machines, which GDB doesn't support yet), but I don't think I'm
doing things worse by adding this.

Change-Id: I2a169664ff91b92caf27cb084334f2eb4df46aa5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32610

[gdb/tui] Fix assert in tui_source_window_base::refresh_window

Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this:
...
$ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \
    -ex "b f2"\
    -ex run
...
(from a directory not containing a file called main.c to make sure that the
missing source stays missing) and then issue finish:
...
(gdb) finish
Run till exit from #0  f2 (x=4)
    at f2.c:5
0x0000000000400570 in main ()
    at main.c:7
Value returned is $1 = 13
(gdb)
...
and use control-<minus> to decrease the font size (IOW increase the $LINES and
$COLUMNS) on the terminal, we get:
...
gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \
  Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
...

The tui_source_window_base class has variable m_pad which keeps track of a
curses pad that is used to display the source code or disassembly efficiently.

The assert in tui_source_window_base::refresh_window triggers while preparing
to display part of the pad.

The problem is that the window is in a state in which the pad is not used,
because m_content.empty () == true.  Instead, it simply shows
"[ No Source Available ]".

Fix this by bailing out of tui_source_window_base::refresh_window before
accessing the m_pad variable, if m_content.empty () == true.

Tested on x86_64-linux.

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

(cherry picked from commit 1c525b0e037b895f6d21deaf32dd922dfdd9c822)

Automatic date update in version.in

gdb/remote: add 'binary-upload' feature to guard 'x' packet use

This mailing list discussion:

  https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com

highlighted the following issue with GDB's 'x' packet implementation.

Unfortunately, LLDB also has an 'x' packet, but their implementation
is different to GDB's and so targets that have implemented LLDB's 'x'
packet are incompatible with GDB.

The above thread is specifically about the 'rr' tool, but there could
be other remote targets out there that have this problem.

The difference between LLDB and GDB is that GDB expects a 'b' prefix
on the reply data, while LLDB does not.  The 'b' is important as it
allows GDB to distinguish between an empty reply (which will be a 'b'
prefix with no trailing data) and an unsupported packet (which will be
a completely empty packet).  It is not clear to me how LLDB
distinguishes these two cases.

See for discussion of the 'x' packet:

  https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r

with the part specific to the 'b' marker in:

  https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/

I propose that we add a new feature 'binary-upload' which can be
reported by a stub in its qSupported reply.  By default this feature
is "off", meaning GDB will not use the 'x' packet unless a stub
advertises this feature.

I have updated gdbserver to send 'binary-upload+', and when I examine
the gdbserver log I can see this feature being sent back, and then GDB
will use the 'x' packet.

When connecting to an older gdbserver, the feature is not sent, and
GDB does not try to use the 'x' packet at all.

I also built the latest version of `rr` and tested using current HEAD
of master, where I see problems like this:

  (rr) x/10i main
     0x401106 <main>:   Cannot access memory at address 0x401106

Then tested using this patched version of GDB, and now I see:

  (rr) x/10i main
     0x401106 <main>:   push   %rbp
     0x401107 <main+1>: mov    %rsp,%rbp
     0x40110a <main+4>: mov    0x2f17(%rip),%rax        # 0x404028 <global_ptr>
     ... etc ...

and looking in the remote log I see GDB is now using the 'm' packet
instead of the 'x' packet.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

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

bfd/doc: use abs_srcdir when creating symlinks

After commit:

  commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
  Date:   Fri Dec 3 00:23:20 2021 -0500

      bfd: merge doc subdir up a level

And the follow-up commit:

  commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33
  Date:   Wed Oct 2 22:58:08 2024 +0300

      bfd: fix unnecessary bfd.info regen

There is still a problem building the bfd docs from a release tar
file.

As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.

However, this is still not working as expected if $(srcdir) is
relative.  The problem is this line in REGEN_TEXI:

    test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \

This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree.  However,
the symlink is created in the bfd/doc/ build directory.  The relative
path will then fail to take you to the bfd/ directory in the src
tree.

Fix this by using $(abs_srcdir) when creating the symlink.

Approved-By: Nick Clifton <nickc@redhat.com>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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

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

This commit also makes the following changes in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_minor to 2.

Set GDB version number to 16.1.

This commit changes gdb/version.in to 16.1.

Automatic date update in version.in

gdb: quote inferior arguments, if needed,  when opening a core file

This commit fixes an issue with the commit:

  commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
  Date:   Thu Apr 25 09:36:43 2024 +0100

      gdb: add gdbarch method to get execution context from core file

The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be.  For
example:

  (gdb) core-file /tmp/corefile-exec-context.2.core
  [New LWP 4069711]
  Reading symbols from /tmp/corefile-exec-context...
  Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
  Program terminated with signal SIGABRT, Aborted.
  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
  50   return ret;
  (gdb) show args
  Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
  (gdb)

Notice the 'Core was generated by ...' line.  In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.

But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.

This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.

This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string.  In this way the quoting is
handled just as it is for 'show args'.  The initial output is now:

  (gdb) core-file /tmp/corefile-exec-context.2.core
  [New LWP 4069711]
  Reading symbols from /tmp/corefile-exec-context...
  Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
  Program terminated with signal SIGABRT, Aborted.
  #0  0x00007f4f007af625 in raise () from /lib64/libc.so.6
  (gdb)

Much better.  The existing test is extended to cover this case.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdbserver: Fix build on MIPS

Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke
the build on MIPS because it's passing a non-existent "pid" argument
to "proc->for_each_thread".  This commit fixes the problem by removing
the argument from the call.

Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Automatic date update in version.in

Automatic date update in version.in

Fix help formatting for string and filename options

I happened to notice that "help add-inferior" said:

  -execFILENAME
    FILENAME is the file name of the executable to use as the
    main program.

This is missing a space after "-exec".  This patch fixes the bug.

If ok'd on time I plan to check this in to the gdb-16 branch as well.

Approved-by: Kevin Buettner <kevinb@redhat.com>
(cherry picked from commit 6511d20c9d47093acb3b099ff19854e01bbe9af4)

Automatic date update in version.in

gdb/jit: fix jit-reader linetable integrity

The custom linetable functionality in GDB's JIT Interface has been broken
since commit 1acc9dca423f78e44553928f0de839b618c13766.

In that commit, linetables were made independent from the objfile, which
requires objfile->section_offsets to be initialized. However, section_offsets
were never initialized in objfiles generated by GDB's JIT Interface
with custom jit-readers, leading to GDB crashes when stepping into JITed code
blocks with the following command already executed:

  jit-reader-load libmygdbjitreader.so

This patch fixes the issue by initializing the minimum section_offsets required
for linetable parsing procedures.

A minimal test is included.  The test sets up some very simple line
table information, which is enough to trigger the bug.  However, the
line table information is crafted such that none of the line table
entries will end up being displayed in GDB's output when the test is
run, as such, none of the expected output actually changes.

It might be nice in the future to extend some of the jit tests to
actually test hitting line table entries added via the jit reader.

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

Automatic date update in version.in

Handle case where DAP line can be None

A comment in bugzilla pointed out a bug in my earlier patch to handle
the DAP "linesStartAt1" setting.  In particular, in the backtrace
code, "line" can be None, which would lead to an exception from
export_line.

This patch fixes the problem.

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

(cherry picked from commit 28e585134434ee2c65df5001e4494c1b4adcd204)

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 crash in DWARF indexer

Iain pointed out a crash in the DWARF indexer when run on a certain D
program.  The DWARF in this case has a nameless enum class; this
causes an assertion failure.

This patch arranges to simply ignore such types.  The fact that an
enum class is nameless in this case appears to be a compiler bug.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518
Approved-By: Tom de Vries <tdevries@suse.de>
(cherry picked from commit 66903f1d66a2648e82250a427a791286e4ed4735)

Automatic date update in version.in

Fix procfs.c compilation

procfs.c compilation is currently broken on Solaris:

/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
 2067 |               wait_retval = gdb::wait (&wstat);
      |                                  ^~~~
In file included from ../gnulib/import/sys/wait.h:28,
                 from /usr/include/stdlib.h:16,
                 from /usr/gcc/14/include/c++/14.2.0/cstdlib:79,
                 from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99,
                 from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26,
                 from <command-line>:
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
   85 | extern pid_t wait(int *);
      |              ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
 2154 |                         int temp = gdb::wait (&wstat);
      |                                         ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
   85 | extern pid_t wait(int *);
      |              ^~~~
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’:
/vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’?
 2566 |       gdb::wait (NULL);
      |            ^~~~
/usr/include/sys/wait.h:85:14: note: ‘wait’ declared here
   85 | extern pid_t wait(int *);
      |              ^~~~

The use of gdb::wait was introduced in

commit 4e4dfc4728622d83c5d600949024449e21de868a
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Nov 22 17:44:29 2024 +0100

    [gdb] Add gdb::wait

but obviously never tested.

Fixed by including gdbsupport/eintr.h to provide the declaration.

Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.

(cherry picked from commit d7bd319e93a3ab73d7e88ef44550f0be98c6c4b7)

Handle linesStartAt1 in DAP

The DAP initialize request has a "linesStartAt1" option, where the
client can indicate that it prefers whether line numbers be 0-based or
1-based.

This patch implements this.  I audited all the line-related code in
the DAP implementation.

Note that while a similar option exists for column numbers, gdb
doesn't handle these yet, so nothing is done here.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468
(cherry picked from commit 8ac42dbf5001416e6b741c5361be14186afde5b0)

[gdb/build] Use const_cast in fd_copy

Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did:
...
 fd_copy (fd_set *dst, const fd_set *src, int n)
 {
   FD_ZERO (dst);
   for (int i = 0; i < n; ++i)
-    if (FD_ISSET (i, src))
+    if (FD_ISSET (i, (fd_set *)src))
...
but according to [1] only const_cast may be used to cast away constness.

Fix this by using const_cast.

Tested by rebuilding on x86_64-linux.

[1] https://en.cppreference.com/w/cpp/language/const_cast

(cherry picked from commit a189db13c4889548be4439314a956f2ab910166b)

Automatic date update in version.in

Automatic date update in version.in

[gdb/readline] Fix link error on MinGW due to missing 'alarm'

  The previous solution used symbols that exist only in MinGW64.
  Add a stub implementation of 'alarm' for mingw.org's MinGW.

(cherry picked from commit d46fdacc0921666ce5e815529151aae07c6f8dd2)

[gdb/selftest] Fix 'help_doc_invariants' self-test

  Running selftest help_doc_invariants.
  help doc broken invariant: command 'signal-event' help doc has over-long line
  Self test failed: self-test failed at unittests/command-def-selftests.c:121

  The reason is that doc string of 'signal-event' doesn't have
  newlines at end of its line.  Fix by adding newlines.

(cherry picked from commit c1023d95672cfd293fd84556baf899713955ee50)

[gdb] Fix compilation error in event-top.c

       CXX    event-top.o
     In file included from d:\usr\include\winsock2.h:69,
      from ./../gdbsupport/gdb_select.h:30,
      from event-top.c:43:
     event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)':
     event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive]
      1279 |     if (FD_ISSET (i, src))
   |                      ^
   |                      |
   |                      const fd_set*
     d:\usr\include\winsock.h:164:50: note:   initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)'
       164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set )
   |                                          ~~~~~~~~^~~~~

  Use an explicit type cast to prevent this.

      * gdb/event-top.c (fd_copy): Type-cast in call to FD_ISSET.

(cherry picked from commit 6ab5d62ebc5df29d3fe1fd81b311c3d3fc12f565)

Automatic date update in version.in

Automatic date update in version.in

PR 32507, PRIx64 in error messages on 32-bit mingw

People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety.  (We
handled %ll OK, editing it to %I64 on such hosts.)

PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.

(cherry picked from commit b38cf91f230bc3892ab9c3deb4f1b6639c657c47)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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

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

Set GDB version number to 16.0.90.

This commit changes gdb/version.in to 16.0.90.

gdb/NEWS: modify "Changes since GDB 15" to "Changes in GDB 16"

Set development mode to "off" by default.

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

Bump version to 16.0.90.DATE-git.

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

For the record, the GDB 16 branch was created
from commit ee29a3c4ac7adc928ae6ed1fed3b59c940a519a4.

Automatic date update in version.in

Automatic date update in version.in

bfd/ELF: refine segment index in filepos assignment diag

Reporting an internal loop index isn't helpful for the user to determine
which segment the problem is with. Report the PHDR index instead.

ld/testsuite: replace aarch64 uses of load_lib

Using $srcdir/$subdir directly doesn't work, at least not with expect
5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
aspect which is crucial here). Make use of load_file instead.

LoongArch: Reword message for unresolvable relocs

For PDE, "recompiling with -fPIE" just makes no sense.

For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.

If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols.  A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access.  And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE

In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility.  This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":

    $ cat t.c
    int x (void) __attribute__ ((weak));

    int
    main (void)
    {
      __builtin_printf("%p\n", x);
    }
    $ gcc t.c -static-pie -mdirect-extern-access
    $ ./a.out
    0x7ffff1d64000

Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.

But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols.  Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk.  (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)

While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.

Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/
Signed-off-by: Xi Ruoyao <xry111@xry111.site>

LoongArch: Fix resolution of undefined weak hidden/protected symbols

An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0.  So
in PIE or DSO the runtime address would be incorrect.

Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

Automatic date update in version.in

Automatic date update in version.in

macro.c:871 heap-buffer-overflow

PR 32391 commit 9f2e3c21f6 fallout again.  Also fix another 'macro'
may be used uninitialized.

buffer overflow in gas/app.c

This testcase:
 .irp x x x "
 .end #
 .endr
manages to access lex[EOF].

xxx: Warning: end of file in string; '"' inserted
xxx:1: Warning: missing closing `"'
gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
Following that there is a buffer overflow.

Stop this happening, and in other similar places, by checking for EOF.