binutils-gdb.git
21 months agogprofng: PR29521 [docs] man pages are not in the release tarball
Vladimir Mezentsev [Fri, 20 Jan 2023 23:39:55 +0000 (15:39 -0800)]
gprofng: PR29521 [docs] man pages are not in the release tarball

gprofng/ChangeLog
2023-01-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29521
* configure.ac: Check if $MAKEINFO and $HELP2MAN are missing.
* Makefile.am: Build doc if $MAKEINFO exists.
* doc/gprofng.texi: Update documentation for gprofng.
* doc/Makefile.am: Build gprofng.1.
* src/Makefile.am: Move the build of gprofng.1 to doc/Makefile.am.
* configure: Rebuild.
* Makefile.in: Rebuild.
* doc/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

21 months agolibsframe/doc: fix some warnings
Indu Bhagat [Tue, 24 Jan 2023 18:07:13 +0000 (10:07 -0800)]
libsframe/doc: fix some warnings

'make pdf' in libsframe shows some warnings, some of which (especially
the Overfull warnings) are causing undesirable effects on the rendered
output.  Few examples of the warnings:

  Underfull \hbox (badness 10000) in paragraph at lines 406--407
   @texttt pauth_

  Underfull \hbox (badness 10000) in paragraph at lines 407--410
   @textrm Specify which key is used for signing the return

  ...

  Overfull \hbox (2.0987pt too wide) in paragraph at lines 412--413
   @texttt fdetype[]|

  ...

  Overfull \hbox (28.87212pt too wide) in paragraph at lines 446--447
   @textrm SFRAME[]FDE[]TYPE[]PCMASK|

  ...

This patch adjusts column widths of the affected cells to fix a subset
of these warnings.  For the rest of the warnings, use explicit newline
command to fix them.

libsframe/
* doc/sframe-spec.texi: Fix various underfull and overfull
warnings.

21 months agoFix seg-fault when generating an empty DLL with LTO enabled.
Nick Clifton [Tue, 24 Jan 2023 09:47:43 +0000 (09:47 +0000)]
Fix seg-fault when generating an empty DLL with LTO enabled.

ld   PR 29998
     * pe-dll.c (generate_reloc): Handle sections
     with no assigned output section.
     Terminate early of there are no relocs to put
     in the .reloc section.
     (pe_exe_fill_sections): Do not emit an empty
     .reloc section.

bfd  * cofflink.c (_bfd_coff_generic_relocate_section):
     Add an assertion that the output section is set
     for defined, global symbols.

21 months agogdb: some int to bool conversion
Enze Li [Sun, 22 Jan 2023 05:38:41 +0000 (13:38 +0800)]
gdb: some int to bool conversion

When building GDB with clang 16, I got this,

  CXX    maint.o
maint.c:1045:23: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_space_enabled = 1;
                      ^ ~
maint.c:1057:22: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_time_enabled = 1;
                     ^ ~
maint.c:1073:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
      m_symtab_enabled = 1;
                       ^ ~
3 errors generated.

Work around this by using bool bitfields instead.

Tested by rebuilding on x86_64-linux with clang 16 and gcc 12.

Approved-By: Tom Tromey <tom@tromey.com>
21 months agold: Avoid magic numbers for subsystems in pe.em and pep.em
Mark Harmstone [Tue, 24 Jan 2023 00:52:30 +0000 (00:52 +0000)]
ld: Avoid magic numbers for subsystems in pe.em and pep.em

21 months agoAutomatic date update in version.in
GDB Administrator [Tue, 24 Jan 2023 00:00:11 +0000 (00:00 +0000)]
Automatic date update in version.in

21 months agold: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI
Mark Harmstone [Sun, 22 Jan 2023 23:45:03 +0000 (23:45 +0000)]
ld: Set default subsystem for arm-pe to IMAGE_SUBSYSTEM_WINDOWS_GUI

This fixes the test failures introduced by 87a5cf5c, by changing the
default subsystem for arm-pe from 9 (IMAGE_SUBSYSTEM_WINDOWS_CE_GUI) to
2 (IMAGE_SUBSYSTEM_WINDOWS_GUI), which matches what happens with other
PE targets.

As far as I can tell there's no working modern Windows CE toolchain
knocking about anyway, so this change shouldn't inconvenience anyone.

22 months agoAdd support for secidx relocations to aarch64-w64-mingw32
Mark Harmstone [Mon, 23 Jan 2023 00:26:07 +0000 (00:26 +0000)]
Add support for secidx relocations to aarch64-w64-mingw32

This patch adds support for the .secidx directive and its corresponding
relocation to aarch64-w64-mingw32. As with x86, this is a two-byte LE
integer which gets filled in with the 1-based index of the output
section that a symbol ends up in.

This is needed for PDBs, which represent addresses as a .secrel32,
.secidx pair.

The test is substantially the same as for amd64, but with changes made
for padding and alignment.

22 months ago[gdb/tdep, aarch64] Fix frame address of last insn
Tom de Vries [Mon, 23 Jan 2023 15:49:36 +0000 (16:49 +0100)]
[gdb/tdep, aarch64] Fix frame address of last insn

Consider the test-case test.c, compiled without debug info:
...
void
foo (const char *s)
{
}

int
main (void)
{
  foo ("foo");
  return 0;
}
...

Disassembly of foo:
...
0000000000400564 <foo>:
  400564:       d10043ff        sub     sp, sp, #0x10
  400568:       f90007e0        str     x0, [sp, #8]
  40056c:       d503201f        nop
  400570:       910043ff        add     sp, sp, #0x10
  400574:       d65f03c0        ret
...

Now, let's do "info frame" at each insn in foo, as well as printing $sp
and $x29 (and strip the output of info frame to the first line, for brevity):
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b *foo
Breakpoint 1 at 0x400564
(gdb) r
Starting program: a.out

Breakpoint 1, 0x0000000000400564 in foo ()
(gdb) display /x $sp
1: /x $sp = 0xfffffffff3a0
(gdb) display /x $x29
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400568 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x000000000040056c in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400570 in foo ()
1: /x $sp = 0xfffffffff390
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3a0:
(gdb) si
0x0000000000400574 in foo ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
(gdb) info frame
Stack level 0, frame at 0xfffffffff3b0:
 pc = 0x400574 in foo; saved pc = 0x40058c
(gdb) si
0x000000000040058c in main ()
1: /x $sp = 0xfffffffff3a0
2: /x $x29 = 0xfffffffff3a0
...

The "frame at" bit lists 0xfffffffff3a0 except at the last insn, where it
lists 0xfffffffff3b0.

The frame address is calculated here in aarch64_make_prologue_cache_1:
...
  unwound_fp = get_frame_register_unsigned (this_frame, cache->framereg);
  if (unwound_fp == 0)
    return;

  cache->prev_sp = unwound_fp + cache->framesize;
...

For insns after the prologue, we have cache->framereg == sp and
cache->framesize == 16, so unwound_fp + cache->framesize gives the wrong
answer once sp has been restored to entry value by the before-last insn.

Fix this by detecting the situation that the sp has been restored.

This fixes PRs tdep/30010 and tdep/30011.

This also fixes the aarch64 FAILs in gdb.reverse/solib-precsave.exp and
gdb.reverse/solib-reverse.exp I reported in PR gdb/PR29721.

Tested on aarch64-linux.
PR tdep/30010
PR tdep/30011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30010
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30011

22 months ago[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp
Tom de Vries [Mon, 23 Jan 2023 10:54:43 +0000 (11:54 +0100)]
[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp

One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
compiled with nodebug, to prevent the dwarf unwinders from taking effect.

For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
default, generating an .eh_frame section contribution which might enable the
dwarf unwinders and bypass the architecture-specific unwinders.

Currently, that happens to be not the case due to the current implementation
of epilogue_unwind_valid, which assumes that in absence of debug info proving
that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.

That may change though, see PR30028, in which case
gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").

Fix this by making sure that we don't use .eh_frame info regardless of
epilogue_unwind_valid, simply by not generating it using
-fno-asynchronous-unwind-tables.

Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
gcc 7.5.0 and clang 13.0.1.

22 months agoUpdated Swedish translation for the binutils sub-directory
Nick Clifton [Mon, 23 Jan 2023 10:53:12 +0000 (10:53 +0000)]
Updated Swedish translation for the binutils sub-directory

22 months ago[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp
Tom de Vries [Mon, 23 Jan 2023 09:32:45 +0000 (10:32 +0100)]
[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp

In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
disassembled insn in function foo.

This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
fix for gdb.base/unwind-on-each-insn.exp").

The use of the last disassembled insn in the test-case is to stop stepping in
foo once reaching it.

However, the intent is to stop stepping just before returning to main.

There is no guarantee that the last disassembled insn:
- is actually executed
- is executed just before returning to main
- is executed only once.

Fix this by simplying the test-case to continue stepping till stepping out of
foo.

Tested on x86_64-linux.

22 months ago[gdb/testsuite] Fix untested in gdb.base/frame-view.exp
Tom de Vries [Mon, 23 Jan 2023 07:59:20 +0000 (08:59 +0100)]
[gdb/testsuite] Fix untested in gdb.base/frame-view.exp

When running test-case gdb.base/frame-view.exp, I see:
...
gdb compile failed, ld: frame-view0.o: in function `main':
frame-view.c:73: undefined reference to `pthread_create'
ld: frame-view.c:76: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/frame-view.exp: failed to prepare
...

Fix this by adding pthreads to the compilation flags.

Tested on x86_64-linux.

22 months agoFix objdump --reloc for specific symbol
Vladislav Khmelevsky [Sun, 22 Jan 2023 18:07:36 +0000 (22:07 +0400)]
Fix objdump --reloc for specific symbol

If objdump is used with both --disassemble=symbol and --reloc options
skip relocations that have addresses before the symbol, so that they
are not displayed.

22 months agoAutomatic date update in version.in
GDB Administrator [Mon, 23 Jan 2023 00:00:08 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agoRemove path name from test
Tom Tromey [Sat, 21 Jan 2023 21:59:16 +0000 (14:59 -0700)]
Remove path name from test

The test suite reports several path names in tests.  I couldn't find
most of these, and I suspect they are false reports, but I did manage
to locate one.  This one is probably harmless, as I think the path
does not vary; but it's also easy to fix and suppress one warning.

22 months agoMinor cleanup in gdb.btrace/enable.exp
Tom Tromey [Sun, 22 Jan 2023 17:53:06 +0000 (10:53 -0700)]
Minor cleanup in gdb.btrace/enable.exp

I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
left over from an earlier change.  This patch moves the "!" inside the
braces, where it belongs.

22 months agoMinor fixup in allow_aarch64_sve_tests
Tom Tromey [Sun, 22 Jan 2023 16:43:01 +0000 (09:43 -0700)]
Minor fixup in allow_aarch64_sve_tests

An earlier patch failed to update a string in allow_aarch64_sve_tests.

22 months agoAutomatic date update in version.in
GDB Administrator [Sun, 22 Jan 2023 00:00:10 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agoAutomatic date update in version.in
GDB Administrator [Sat, 21 Jan 2023 00:00:09 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agogdb: make frame_info_ptr auto-reinflatable
Simon Marchi [Wed, 14 Dec 2022 03:34:41 +0000 (22:34 -0500)]
gdb: make frame_info_ptr auto-reinflatable

This is the second step of making frame_info_ptr automatic, reinflate on
demand whenever trying to obtain the wrapper frame_info pointer, either
through the get method or operator->.  Make the reinflate method
private, it is used as a convenience method in those two.

Add an "is_null" method, because it is often needed to know whether the
frame_info_ptr wraps an frame_info or is empty.

Make m_ptr mutable, so that it's possible to reinflate const
frame_info_ptr objects.  Whether m_ptr is nullptr or not does not change
the logical state of the object, because we re-create it on demand.  I
believe this is the right use case for mutable.

Change-Id: Icb0552d0035e227f81eb3c121d8a9bb2f9d25794
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: make frame_info_ptr grab frame level and id on construction
Simon Marchi [Wed, 14 Dec 2022 03:34:40 +0000 (22:34 -0500)]
gdb: make frame_info_ptr grab frame level and id on construction

This is the first step of making frame_info_ptr automatic.  Remove the
frame_info_ptr::prepare_reinflate method, move that code to the
constructor.

Change-Id: I85cdae3ab1c043c70e2702e7fb38e9a4a8a675d8
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: make user-created frames reinflatable
Simon Marchi [Wed, 14 Dec 2022 03:34:39 +0000 (22:34 -0500)]
gdb: make user-created frames reinflatable

This patch teaches frame_info_ptr to reinflate user-created frames
(frames created through create_new_frame, with the "select-frame view"
command).

Before this patch, frame_info_ptr doesn't support reinflating
user-created frames, because it currently reinflates by getting the
current target frame (for frame 0) or frame_find_by_id (for other
frames).  To reinflate a user-created frame, we need to call
create_new_frame, to make it lookup an existing user-created frame, or
otherwise create one.

So, in prepare_reinflate, get the frame id even if the frame has level
0, if it is user-created.  In reinflate, if the saved frame id is user
create it, call create_new_frame.

In order to test this, I initially enhanced the gdb.base/frame-view.exp
test added by the previous patch by setting a pretty-printer for the
type of the function parameters, in which we do an inferior call.  This
causes print_frame_args to not reinflate its frame (which is a
user-created one) properly.  On one machine (my Arch Linux one), it
properly catches the bug, as the frame is not correctly restored after
printing the first parameter, so it messes up the second parameter:

    frame
    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
    40        return z1.m + z2.n;
    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
    frame
    #0  baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
    40        return z1.m + z2.n;
    (gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again

However, on another machine (my Ubuntu 22.04 one), it just passes fine,
without the appropriate fix.  I then thought about writing a selftest
for that, it's more reliable.  I left the gdb.base/frame-view.exp pretty
printer test there, it's already written, and we never know, it might
catch some unrelated issue some day.

Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: make it possible to restore selected user-created frames
Simon Marchi [Wed, 14 Dec 2022 03:34:38 +0000 (22:34 -0500)]
gdb: make it possible to restore selected user-created frames

I would like to improve frame_info_ptr to automatically grab the
information needed to reinflate a frame, and automatically reinflate it
as needed.  One thing that is in the way is the fact that some frames
can be created out of thin air by the create_new_frame function.  These
frames are not the fruit of unwinding from the target's current frame.
These frames are created by the "select-frame view" command.

These frames are not correctly handled by the frame save/restore
functions, save_selected_frame, restore_selected_frame and
lookup_selected_frame.  This can be observed here, using the test
included in this patch:

    $ ./gdb --data-directory=data-directory -nx -q testsuite/outputs/gdb.base/frame-view/frame-view
    Reading symbols from testsuite/outputs/gdb.base/frame-view/frame-view...
    (gdb) break thread_func
    Breakpoint 1 at 0x11a2: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c, line 42.
    (gdb) run
    Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/frame-view/frame-view

    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
    [New Thread 0x7ffff7cc46c0 (LWP 4171134)]
    [Switching to Thread 0x7ffff7cc46c0 (LWP 4171134)]

    Thread 2 "frame-view" hit Breakpoint 1, thread_func (p=0x0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
    42        foo (11);
    (gdb) info frame
    Stack level 0, frame at 0x7ffff7cc3ee0:
     rip = 0x5555555551a2 in thread_func (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42); saved rip = 0x7ffff7d4e8fd
     called by frame at 0x7ffff7cc3f80
     source language c.
     Arglist at 0x7ffff7cc3ed0, args: p=0x0
     Locals at 0x7ffff7cc3ed0, Previous frame's sp is 0x7ffff7cc3ee0
     Saved registers:
      rbp at 0x7ffff7cc3ed0, rip at 0x7ffff7cc3ed8
    (gdb) thread 1
    [Switching to thread 1 (Thread 0x7ffff7cc5740 (LWP 4171122))]
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

Here, we create a custom frame for thread 1 (using the stack from thread
2, for convenience):

    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2

The first calls to "frame" looks good:

    (gdb) frame
    #0  thread_func (p=0x7ffff7d4e630) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:42
    42        foo (11);

But not the second one:

    (gdb) frame
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6

This second "frame" command shows the current target frame instead of
the user-created frame.

It's not totally clear how the "select-frame view" feature is expected
to behave, especially since it's not tested.  I heard accounts that it
used to be possible to select a frame like this and do "up" and "down"
to navigate the backtrace starting from that frame.  The fact that
create_new_frame calls frame_unwind_find_by_frame to install the right
unwinder suggest that it used to be possible.  But that doesn't work
today:

    (gdb) select-frame view 0x7ffff7cc3f80 0x5555555551a2
    (gdb) up
    Initial frame selected; you cannot go up.
    (gdb) down
    Bottom (innermost) frame selected; you cannot go down.

and "backtrace" always shows the actual thread's backtrace, it ignores
the user-created frame:

    (gdb) bt
    #0  0x00007ffff7d4b4b6 in ?? () from /usr/lib/libc.so.6
    #1  0x00007ffff7d50403 in ?? () from /usr/lib/libc.so.6
    #2  0x000055555555521a in main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:56

I don't want to address all the `select-frame view` issues , but I think
we can agree that the "frame" command changing the selected frame, as
shown above, is a bug.  I would expect that command to show the
currently selected frame and not change it.

This happens because of the scoped_restore_selected_frame object in
print_frame_args.  The frame information is saved in the constructor
(the backtrace below), and restored in the destructor.

    #0  save_selected_frame (frame_id=0x7ffdc0020ad0, frame_level=0x7ffdc0020af0) at /home/simark/src/binutils-gdb/gdb/frame.c:1682
    #1  0x00005631390242f0 in scoped_restore_selected_frame::scoped_restore_selected_frame (this=0x7ffdc0020ad0) at /home/simark/src/binutils-gdb/gdb/frame.c:324
    #2  0x000056313993581e in print_frame_args (fp_opts=..., func=0x62100023bde0, frame=..., num=-1, stream=0x60b000000300) at /home/simark/src/binutils-gdb/gdb/stack.c:755
    #3  0x000056313993ad49 in print_frame (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1401
    #4  0x000056313993835d in print_frame_info (fp_opts=..., frame=..., print_level=1, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1126
    #5  0x0000563139932e0b in print_stack_frame (frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:368
    #6  0x0000563139932bbe in print_stack_frame_to_uiout (uiout=0x611000016840, frame=..., print_level=1, print_what=SRC_AND_LOC, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:346
    #7  0x0000563139b0641e in print_selected_thread_frame (uiout=0x611000016840, selection=...) at /home/simark/src/binutils-gdb/gdb/thread.c:1993
    #8  0x0000563139940b7f in frame_command_core (fi=..., ignored=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1871
    #9  0x000056313994db9e in frame_command_helper<frame_command_core>::base_command (arg=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1976

Since the user-created frame has level 0 (identified by the saved level
-1), lookup_selected_frame just reselects the target's current frame,
and the user-created frame is lost.

My goal here is to fix this particular problem.

Currently, select_frame does not set selected_frame_id and
selected_frame_level for frames with level 0.  It leaves them at
null_frame_id / -1, indicating to restore_selected_frame to use the
target's current frame.  User-created frames also have level 0, so add a
special case them such that select_frame saves their selected id and
level.

save_selected_frame does not need any change.

Change the assertion in restore_selected_frame that checks `frame_level
!= 0` to account for the fact that we can restore user-created frames,
which have level 0.

Finally, change lookup_selected_frame to make it able to re-create
user-created frame_info objects from selected_frame_level and
selected_frame_id.

Add a minimal test case for the case described above, that is the
"select-frame view" command followed by the "frame" command twice.  In
order to have a known stack frame to switch to, the test spawns a second
thread, and tells the first thread to use the other thread's top frame.

Change-Id: Ifc77848dc465fbd21324b9d44670833e09fe98c7
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: add create_new_frame(frame_id) overload
Simon Marchi [Wed, 14 Dec 2022 03:34:37 +0000 (22:34 -0500)]
gdb: add create_new_frame(frame_id) overload

The subsequent patches will need to call create_new_frame with an
existing frame_id representing a user created frame.  They could call
the existing create_new_frame, passing both addresses, but it seems
nicer to have a version of the function that takes a frame_id directly.

Change-Id: If31025314fec0c3e644703e4391a5ef8079e1a32
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: add user-created frames to stash
Simon Marchi [Wed, 14 Dec 2022 03:34:36 +0000 (22:34 -0500)]
gdb: add user-created frames to stash

A subsequent patch makes it possible for frame_info_ptr to reinflate
user-created frames.  If two frame_info_ptr objects wrapping the same
user-created frame_info need to do reinflation, we want them to end up
pointing to the same frame_info instance, and not create two separate
frame_infos.  Otherwise, GDB gets confused down the line, as the state
kept in one frame_info object starts differing from the other
frame_info.

Achieve this by making create_new_frame place the user-created frames in
the frame stash.  This way, when the second frame_info_ptr does
reinflation, it will find the existing frame_info object, created by the
other frame_info_ptr, in the frame stash.

To make the frame stash differentiate between regular and user-created
frame infos which would otherwise be equal, change frame_addr_hash and
frame_id::operator== to account for frame_id::user_created_p.

I made create_new_frame look up existing frames in the stash, and only
create one if it doesn't find one.  The goal is to avoid the
"select-frame view"/"info frame view"/"frame view" commands from
overriding existing entries into the stash, should the user specify the
same frame more than once.  This will also help in the subsequent patch
that makes frame_info_ptr capable of reinflating user-created frames.
It will be able to just call create_new_frame and it will do the right
thing.

Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: add frame_id::user_created_p
Simon Marchi [Wed, 14 Dec 2022 03:34:35 +0000 (22:34 -0500)]
gdb: add frame_id::user_created_p

Later in this series, we'll need to differentiate frame ids for regular
frames (obtained from the target state and unwinding from it) vs frame
ids for user-created frames (created with create_new_frame).  Add the
frame_id::user_created_p field to indicate a frame is user-created, and
set it in create_new_frame.

The field is otherwise not used yet, so not changes in behavior are
expected.

Change-Id: I60de3ce581ed01bf0fddb30dff9bd932840120c3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: move frame_info_ptr to frame.{c,h}
Simon Marchi [Tue, 3 Jan 2023 17:48:48 +0000 (12:48 -0500)]
gdb: move frame_info_ptr to frame.{c,h}

A patch later in this series will make frame_info_ptr access some
fields internal to frame_info, which we don't want to expose outside of
frame.c.  Move the frame_info_ptr class to frame.h, and the definitions
to frame.c.  Remove frame-info.c and frame-info.h.

Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: move call site types to call-site.h
Simon Marchi [Wed, 14 Dec 2022 03:34:33 +0000 (22:34 -0500)]
gdb: move call site types to call-site.h

I hesitated between putting  the file in the dwarf2 directory (as
gdb/dwarf2/call-site.h) or in the common directory (as gdb/call-site.h).
The concept of call site is not DWARF-specific, another debug info
reader could provide this information.  But as it is, the implementation
is a bit DWARF-specific, as one form it can take is a DWARF expression
and parameters can be defined using a DWARF register number.  So I ended up
choosing to put it under dwarf2/.  If another debug info reader ever
wants to provide call site information, we can introduce a layer of
abstraction between the "common" call site and the "dwarf2" call site.

The copyright start year comes from the date `struct call_site` was
introduced.

Change-Id: I1cd84aa581fbbf729edc91b20f7d7a6e0377014d
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: move sect_offset and cu_offset to dwarf2/types.h
Simon Marchi [Wed, 14 Dec 2022 03:34:32 +0000 (22:34 -0500)]
gdb: move sect_offset and cu_offset to dwarf2/types.h

I want to move the call_site stuff out of gdbtypes.h, to a new header
file, to break some cyclic include problem.  The call_site stuff uses
cu_offset, also defined in gdbtypes.h, so cu_offset also needs to move
somewhere else (otherwise, call-site.h will need to include gdbtypes.h,
and we are back to square 1).  I could move cu_offset to the future new
file dwarf2/call-site.h, but it doesn't sound like a good place for it,
at cu_offset is not specific to call sites, it's used throughout
dwarf2/.  So, move it to its own file, dwarf2/types.h.  For now,
gdbtypes.h includes dwarf2/types.h, but that will be removed once the
call site stuff is moved to its own file.

Move sect_offset with it too.  sect_offset is not a DWARF-specific
concept, but for the moment it is only used in dwarf2/.

Change-Id: I1fd2a3b7b67dee789c4874244b044bde7db43d8e
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: remove language.h include from frame.h
Simon Marchi [Wed, 14 Dec 2022 03:34:31 +0000 (22:34 -0500)]
gdb: remove language.h include from frame.h

This helps resolve some cyclic include problem later in the series.
The only language-related thing frame.h needs is enum language, and that
is in defs.h.

Doing so reveals that a bunch of files were relying on frame.h to
include language.h, so fix the fallouts here and there.

Change-Id: I178a7efec1953c2d088adb58483bade1f349b705
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: move compile_instance to compile/compile.h
Simon Marchi [Wed, 14 Dec 2022 03:34:30 +0000 (22:34 -0500)]
gdb: move compile_instance to compile/compile.h

struct compile_instance needs to be visible to users, since we use
std::unique<compile_instance>.  language.c and c-lang.c currently
includes compile-internal.h for this reason, which kind of defeats the
purpose of having an "internal" header file.

Change-Id: Iedffe5f1173b3de7bdc1be533ee2a68e6f6c549f
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agogdb: move type_map_instance to compile/compile.c
Simon Marchi [Wed, 14 Dec 2022 03:34:29 +0000 (22:34 -0500)]
gdb: move type_map_instance to compile/compile.c

It's only used in compile/compile.c, it doesn't need to be in a header.

Change-Id: Ic5bec996b7b0cd7130055d1e8ff238b5ac4292a3
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
22 months agoUpload SFrame spec files as well
Indu Bhagat [Fri, 20 Jan 2023 19:14:11 +0000 (11:14 -0800)]
Upload SFrame spec files as well

binutils/
* README-how-to-make-a-release: Include sframe-spec html and pdf
files.

22 months agoUse bool in pc_in_* functions
Tom Tromey [Wed, 18 Jan 2023 23:36:52 +0000 (16:36 -0700)]
Use bool in pc_in_* functions

I noticed that pc_in_unmapped_range had a weird return type -- it was
returning a CORE_ADDR but intending to return a bool.  This patch
changes all the pc_in_* functions to return bool instead.

22 months agoConstify notif_client
Tom Tromey [Wed, 21 Dec 2022 21:15:16 +0000 (14:15 -0700)]
Constify notif_client

It seems to me that a notif_client is read-only, so this patch changes
the code to use "const" everywhere.

22 months agogdb: remove struct trad_frame forward declaration
Simon Marchi [Fri, 20 Jan 2023 17:35:01 +0000 (12:35 -0500)]
gdb: remove struct trad_frame forward declaration

I found this forward declaration for a struct that doesn't exist, remove
it.

Change-Id: Ib9473435a949452160598035e5e0fe19fcdc4d20

22 months agoMake gdb.ada/ptype_tagged_param.exp pass
Tom Tromey [Thu, 19 Jan 2023 16:30:18 +0000 (09:30 -0700)]
Make gdb.ada/ptype_tagged_param.exp pass

gdb.ada/ptype_tagged_param.exp is failing for me on x86-64 Fedora 36.
However, it's actually generating the correct output -- it is just
that the test thinks that the "ptype" will not work because I do not
have the GNAT debuginfo installed.

This patch changes the code to accept either result, and then to issue
a kfail as appropriate.

22 months agogdb/dwarf: fix UBsan crash in read_subrange_type
Simon Marchi [Fri, 20 Jan 2023 16:51:54 +0000 (11:51 -0500)]
gdb/dwarf: fix UBsan crash in read_subrange_type

When running gdb.ada/arrayptr.exp (and others) on Ubuntu 22.04, with the
`gnat-11` package installed (not `gnat`), with UBSan activated, I get:

    (gdb) break foo.adb:40
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:17689:20: runtime error: shift exponent 127 is too large for 64-bit type 'long unsigned int'

The problematic DIEs are:

    0x00001460:       DW_TAG_subrange_type
                        DW_AT_lower_bound [DW_FORM_data1]   (0x00)
                        DW_AT_upper_bound [DW_FORM_data16]  (ffffffffffffffff3f00000000000000)
                        DW_AT_name [DW_FORM_strp]   ("foo__packed_array___XP7___XDLU_0__1180591620717411303423")
                        DW_AT_type [DW_FORM_ref4]   (0x0000153f "long_long_long_unsigned")
                        DW_AT_GNAT_descriptive_type [DW_FORM_ref4]  (0x0000147e)
                        DW_AT_artificial [DW_FORM_flag_present]     (true)

    0x0000153f:   DW_TAG_base_type
                    DW_AT_byte_size [DW_FORM_data1] (0x10)
                    DW_AT_encoding [DW_FORM_data1]  (DW_ATE_unsigned)
                    DW_AT_name [DW_FORM_strp]       ("long_long_long_unsigned")
                    DW_AT_artificial [DW_FORM_flag_present] (true)

When processed by this code:

    negative_mask =
      -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
    if (low.kind () == PROP_CONST
        && !base_type->is_unsigned () && (low.const_val () & negative_mask))
      low.set_const_val (low.const_val () | negative_mask);

When the base type's length (16 bytes in this case) is larger than a
ULONGEST (typically 8 bytes), the bit shift is too large.

My obvious fix is just to skip the fixup for base types larger than a
ULONGEST (8 bytes).  I don't think we really handle constant attribute
values larger than 8 bytes anyway, so this is part of a much larger
problem.

Add a test that replicates this situation, but uses bounds that fit in a
signed 64 bit, so we get a sensible result.

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

22 months agogdb/testsuite: add test for negative subrange bounds with unsigned form
Simon Marchi [Fri, 20 Jan 2023 16:41:08 +0000 (11:41 -0500)]
gdb/testsuite: add test for negative subrange bounds with unsigned form

I am looking at this code [1]:

  /* Normally, the DWARF producers are expected to use a signed
     constant form (Eg. DW_FORM_sdata) to express negative bounds.
     But this is unfortunately not always the case, as witnessed
     with GCC, for instance, where the ambiguous DW_FORM_dataN form
     is used instead.  To work around that ambiguity, we treat
     the bounds as signed, and thus sign-extend their values, when
     the base type is signed.  */
  negative_mask =
    -((ULONGEST) 1 << (base_type->length () * TARGET_CHAR_BIT - 1));
  if (low.kind () == PROP_CONST
      && !base_type->is_unsigned () && (low.const_val () & negative_mask))
    low.set_const_val (low.const_val () | negative_mask);
  if (high.kind () == PROP_CONST
      && !base_type->is_unsigned () && (high.const_val () & negative_mask))
    high.set_const_val (high.const_val () | negative_mask);

Nothing in the testsuite seems to exercise it, as when I remove it, all
of gdb.dwarf2 still passes.  And tests in other directories would be
compiler-dependent, so would rely on having a buggy compiler.

Update gdb.dwarf2/subrange.exp to have a test for it.  When removing the
code above, the new test fails with:

  ptype array_with_buggy_negative_bounds_type^M
  type = array [240..244] of signed_byte^M
  (gdb) FAIL: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type

instead of the expected:

  ptype array_with_buggy_negative_bounds_type^M
  type = array [-16..-12] of signed_byte^M
  (gdb) PASS: gdb.dwarf2/subrange.exp: ptype array_with_buggy_negative_bounds_type

[1] https://gitlab.com/gnutools/binutils-gdb/-/blob/5ea14aa4e53fa37f4ba4517497ed2c1e4c60dee2/gdb/dwarf2/read.c#L17681-17695

Change-Id: I1992a3ff0cb1e90fa8a9114dae6c591792f059c2

22 months agoAdd testcase ld-elf/merge4
Michael Matz [Wed, 12 Oct 2022 15:29:43 +0000 (17:29 +0200)]
Add testcase ld-elf/merge4

to check a situation that once failed with the new section merging
when it mishandled offsets pointing into alignment padding in mergable
string sections (i.e. pointing to zeros).  It made bootstrap.exp fail
but that depends on many factors to actually go wrong so this is a more
explicit variant of it.

22 months agoarm32: Fix rodata-merge-map
Michael Matz [Thu, 3 Nov 2022 17:00:04 +0000 (18:00 +0100)]
arm32: Fix rodata-merge-map

the test expects a second, but useless, $d mapping symbol for
the partially merged section, and specifically disallows one
for the completely merged section.  The new merging algorithm
makes it so that also the partially merged sections are conceptually
SEC_EXCLUDED, except the first merge section (e.g. as if the very
first object file already contains all strings).  So that second mapping
symbol is now missing.  It never was needed anyway.

So, adjust the test.

22 months agoFaster string merging
Michael Matz [Wed, 20 Jul 2022 15:22:15 +0000 (17:22 +0200)]
Faster string merging

* use power-of-two hash table
* use better hash function (hashing 32bits at once and with better
  mixing characteristics)
* use input-offset-to-entry maps instead of retaining full input
  contents for lookup time
* don't reread SEC_MERGE section multiple times
* care for cache behaviour for the hot lookup routine

The overall effect is less usage in libz and much faster string merging
itself.  On a debug-info-enabled cc1 the effect at the time of this
writing on the machine I used was going from 14400 perf samples to 9300
perf samples or from 3.7 seconds to 2.4 seconds, i.e. about 33% .

22 months agoAdd OpenBSD ARM GAS support.
Frederic Cambus [Fri, 20 Jan 2023 10:46:37 +0000 (10:46 +0000)]
Add OpenBSD ARM GAS support.

22 months agox86: split i386-gen's opcode hash entry struct
Jan Beulich [Fri, 20 Jan 2023 09:18:40 +0000 (10:18 +0100)]
x86: split i386-gen's opcode hash entry struct

All glibc malloc() implementations I've checked have a smallest
allocation size worth of 3 pointers, with an increment worth of 2
pointers. Hence mnemonics with multiple templates can be stored more
efficiently when maintaining the shared "name" field only in the actual
hash entry. (To express the shared nature, also convert "name" to by
pointer-to-const.)

While doing the conversation also pull out common code from the involved
if/else construct in expand_templates().

22 months agox86: embed register and alike names in disassembler
Jan Beulich [Fri, 20 Jan 2023 09:18:17 +0000 (10:18 +0100)]
x86: embed register and alike names in disassembler

Register names are (including their nul terminators) on average almost 4
bytes long. Otoh no register name is longer than 8 bytes. Hence even for
32-bit builds using a pointer is only slightly more space efficient than
embedding the strings. A level of indirection can be also avoided by
embedding the names as an array of 8 characters directly in the arrays,
and the number of base relocations in libopcodes.so (or PIE builds of
statically linked executables) goes down as well.

To amortize for the otherwise reduced folding of string literals by the
linker, use att_names_seg[] in place of string literals in append_seg()
and OP_ESreg().

22 months agox86: embed register names in reg_entry
Jan Beulich [Fri, 20 Jan 2023 09:17:53 +0000 (10:17 +0100)]
x86: embed register names in reg_entry

Register names are (including their nul terminators) on average almost 4
bytes long. Otoh no register name is longer than 7 bytes. Hence even for
32-bit builds using a pointer is only slightly more space efficient than
embedding the strings. A level of indirection can be also avoided by
embedding the names as an array of 8 characters directly in the struct,
and the number of base relocations in PIE builds of gas goes down as
well.

22 months agox86: avoid strcmp() in a few places
Jan Beulich [Fri, 20 Jan 2023 09:17:23 +0000 (10:17 +0100)]
x86: avoid strcmp() in a few places

Now that we have identifiers for the mnemonic strings we can avoid
strcmp() in a number of places, comparing the offsets into the mnemonic
string table instead. While doing this also
- convert a leftover strncmp() to startswith() (apparently an oversight
  when rebasing the original patch introducing the startswith() uses),
- use the new shorthand for current_templates->start also elsewhere in
  md_assemble() (valid up to the point where match_template() is
  called).

22 months agox86: absorb allocation in i386-gen
Jan Beulich [Fri, 20 Jan 2023 09:16:56 +0000 (10:16 +0100)]
x86: absorb allocation in i386-gen

When generating the mnemonic string table we already set up an
identifier for the following entry in a number of cases. Re-use that on
the next loop iteration rather than re-doing allocation and conversion.

22 months agox86: re-use insn mnemonic strings as much as possible
Jan Beulich [Fri, 20 Jan 2023 09:16:17 +0000 (10:16 +0100)]
x86: re-use insn mnemonic strings as much as possible

Compact the mnemonic string table such that the tails of longer
mnemonics are re-used for shorter ones, going beyond what compilers
would typically do, but matching what ELF linkers may do when processing
SHF_MERGE|SHF_STRINGS sections. This reduces table size by about 12.5%.

22 months agox86: move insn mnemonics to a separate table
Jan Beulich [Fri, 20 Jan 2023 09:15:48 +0000 (10:15 +0100)]
x86: move insn mnemonics to a separate table

Using full pointers to reference the insn mnemonic strings is not very
efficient. With overall string size presently just slightly over 20k,
even a 16-bit value would suffice. Use "unsigned int" for now, as
there's no good use we could presently make of the otherwise saved 16
bits.

For 64-bit builds this reduces table size by 6.25% (prior to the recent
ISA extension additions it would have been 12.5%), with a similar effect
on cache occupation of table entries accessed. For PIE builds of gas
this also reduces the number of base relocations quite a bit (obviously
independent of bitness).

22 months agox86: abstract out obtaining of a template's mnemonic
Jan Beulich [Fri, 20 Jan 2023 09:14:46 +0000 (10:14 +0100)]
x86: abstract out obtaining of a template's mnemonic

In preparation for changing the representation of the "name" field
introduce a wrapper function. This keeps the mechanical change separate
from the functional one.

22 months agoAutomatic date update in version.in
GDB Administrator [Fri, 20 Jan 2023 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agoUse "maint ignore-probes" in no-libstdcxx-probe.exp
Tom Tromey [Thu, 19 Jan 2023 18:26:53 +0000 (11:26 -0700)]
Use "maint ignore-probes" in no-libstdcxx-probe.exp

While looking at some test output, I saw that no-libstdcxx-probe.exp
was not being run.  However, it occurred to me that Tom de Vries' new
"maint ignore-probes" command could be used to enable this test
unconditionally.

Reviewed-by: Tom de Vries <tdevries@suse.de>
22 months agoi386: Don't emit unsupported TLS relocs on Solaris
Rainer Orth [Thu, 19 Jan 2023 21:48:58 +0000 (13:48 -0800)]
i386: Don't emit unsupported TLS relocs on Solaris

Emit R_386_TLS_LE and R_386_TLS_IE, instead of R_386_TLS_LE_32 and
R_386_TLS_IE_32, on Solaris.

PR ld/13671
* elf32-i386.c (elf_i386_tls_transition): Only emit R_386_TLS_LE,
R_386_TLS_IE on Solaris.
(elf_i386_relocate_section): Only use R_386_TLS_GD->R_386_TLS_LE
transition on Solaris.

Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
22 months agoGDB/testsuite: Expand for character string limiting options
Andrew Burgess [Thu, 19 Jan 2023 21:15:56 +0000 (21:15 +0000)]
GDB/testsuite: Expand for character string limiting options

Modify test cases that verify the operation of the array element limit
with character strings such that they are executed twice, once with the
`set print characters' option set to `elements' and the limit controlled
with the `set print elements' option, and then again with the limit
controlled with the `set print characters' option instead.  Similarly
with the `-elements' and `-characters' options for the `print' command.
Additionally verify that said `print' command options combined yield the
expected result.

Verify correct $_gdb_setting and $_gdb_setting_str values for the `print
characters' setting, in particular the `void' value for the `elements'
default, which has no corresponding integer value exposed.

Add Guile and Python coverage for the `print characters' GDB setting.

There are new tests for Ada and Pascal, as the string printing code for
these languages is different than the generic string printing code used
by other languages.  Modula2 also has different string printing code,
but (a) this is similar to Pascal, and (b) there are no existing modula2
tests written in Modula2, so I'm not sure how I'd even test the Modula2
string printing.

Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
22 months agoGDB: Add a character string limiting option
Andrew Burgess [Thu, 19 Jan 2023 21:15:56 +0000 (21:15 +0000)]
GDB: Add a character string limiting option

This commit splits the `set/show print elements' option into two.  We
retain `set/show print elements' for controlling how many elements of an
array we print, but a new `set/show print characters' setting is added
which is used for controlling how many characters of a string are
printed.

The motivation behind this change is to allow users a finer level of
control over how data is printed, reflecting that, although strings can
be thought of as arrays of characters, users often want to treat these
two things differently.

For compatibility reasons by default the `set/show print characters'
option is set to `elements', which makes the limit for character strings
follow the setting of the `set/show print elements' option, as it used
to.  Using `set print characters' with any other value makes the limit
independent from the `set/show print elements' setting, however it can
be restored to the default with the `set print characters elements'
command at any time.

A corresponding `-characters' option for the `print' command is added,
with the same semantics, i.e. one can use `elements' to make a given
`print' invocation follow the limit of elements, be it set with the
`-elements' option also given with the same invocation or taken from the
`set/show print elements' setting, for characters as well regardless of
the current setting of the `set/show print characters' option.

The GDB changes are all pretty straightforward, just changing references
to the old 'print_max' to use a new `get_print_max_chars' helper which
figures out which of the two of `print_max' and `print_max_chars' values
to use.

Likewise, the documentation is just updated to reference the new setting
where appropriate.

To make people's life easier the message shown by `show print elements'
now indicates if the setting also applies to character strings:

(gdb) set print characters elements
(gdb) show print elements
Limit on string chars or array elements to print is 200.
(gdb) set print characters unlimited
(gdb) show print elements
Limit on array elements to print is 200.
(gdb)

and the help text shows the dependency as well:

(gdb) help set print elements
Set limit on array elements to print.
"unlimited" causes there to be no limit.
This setting also applies to string chars when "print characters"
is set to "elements".
(gdb)

In the testsuite there are two minor updates, one to add `-characters'
to the list of completions now shown for the `print' command, and a bare
minimum pair of checks for the right handling of `set print characters'
and `show print characters', copied from the corresponding checks for
`set print elements' and `show print elements' respectively.

Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
22 months agoGDB: Allow arbitrary keywords in integer set commands
Maciej W. Rozycki [Thu, 19 Jan 2023 21:15:56 +0000 (21:15 +0000)]
GDB: Allow arbitrary keywords in integer set commands

Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.

Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.

Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.

The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".

Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user.  An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX.  Such translation can now
be arbitrary.  Literals defined by this structure are automatically used
for completion as necessary.

So for example:

const literal_def integer_unlimited_literals[] =
  {
    { "unlimited", INT_MAX, 0 },
    { nullptr }
  };

defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.

Similarly:

const literal_def zuinteger_unlimited_literals[] =
  {
    { "unlimited", -1, -1 },
    { nullptr }
  };

defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting.  If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.

Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type.  It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types.  Similarly update the "must be >= -1" Guile error
message.

Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values.  Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.

With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.

Update the testsuite accordingly.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
22 months agolibsframe: Use AM_SILENT_RULES macro in configure.ac
Indu Bhagat [Thu, 19 Jan 2023 20:40:44 +0000 (12:40 -0800)]
libsframe: Use AM_SILENT_RULES macro in configure.ac

Silence 'make' by default.

libsframe/
* configure.ac: Use AM_SILENT_RULES.
* configure: Regenerate.

22 months agoRemove some unused includes
Tom Tromey [Thu, 19 Jan 2023 18:08:06 +0000 (11:08 -0700)]
Remove some unused includes

I noticed a few spots that include gnu-stabs.h but that do not need
to.  This patch removes these unnecessary includes.  Tested by
rebuilding.

22 months ago[gdb/tdep, aarch64] Remove fp and sp reg aliases, add x31 reg alias
Tom de Vries [Thu, 19 Jan 2023 13:05:08 +0000 (14:05 +0100)]
[gdb/tdep, aarch64] Remove fp and sp reg aliases, add x31 reg alias

In aarch64-tdep.c we find these register aliases:
...
{
  /* 64-bit register names.  */
  {"fp", AARCH64_FP_REGNUM},
  {"lr", AARCH64_LR_REGNUM},
  {"sp", AARCH64_SP_REGNUM},
...

The sp alias is superfluous, because the canonical name of x31 is already sp.

The fp alias is superfluous, because it's already taken by the default meaning
of fp, assigned here in _initialize_frame_reg:
...
  user_reg_add_builtin ("fp", value_of_builtin_frame_fp_reg, NULL);
...

Fix this by removing the fp and sp aliases.

While we're at it, add an x31 alias for sp.

Approved-By: Luis Machado <luis.machado@arm.com>
Tested on aarch64-linux.
PR tdep/30012
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30012

22 months ago[gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian
Tom de Vries [Thu, 19 Jan 2023 12:44:13 +0000 (13:44 +0100)]
[gdb/testsuite] Fix gdb.python/py-value-cc.exp for big endian

On s390x-linux, I run into:
...
(gdb) python print(u[u_fields[0]])^M
99^M
(gdb) PASS: gdb.python/py-value-cc.exp: u's first field via field
python print(u[u_fields[1]])^M
0 '\000'^M
(gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field
...

There's a var u of this type:
...
union U {
  int a;
  char c;
};
...
and after assigning 99 to u.a, the test-case expects u.c to contain 99 (which
it does on x86_64), but instead it contains 0.

Fix this by instead assigning 0x63636363, to ensure that u.c == 99 for both
little and big endian.

Tested on x86_64-linux and s390x-linux.

22 months agoReinitialise macro_nest
Alan Modra [Wed, 18 Jan 2023 23:10:20 +0000 (09:40 +1030)]
Reinitialise macro_nest

* input-scrub.c (input_scrub_begin): Init macro_nest.

22 months agoPR 30022, concurrent builds can fail
Alan Modra [Wed, 18 Jan 2023 23:04:56 +0000 (09:34 +1030)]
PR 30022, concurrent builds can fail

So let's not copy .libs/libbfd.a to libbfd.a now that nothing in the
binutils-gdb source tries to link against it.

PR 30022
* Makefile.am (noinst_LIBRARIES, libbfd_a_SOURCES, stamp-lib),
(libbfd.a): Delete rules.
(CLEANFILES): Adjust to suit.

22 months agotoplevel: Makefile.def: add install-strip dependency on libsframe
Indu Bhagat [Thu, 19 Jan 2023 07:17:49 +0000 (23:17 -0800)]
toplevel: Makefile.def: add install-strip dependency on libsframe

As noted in PR libsframe/30014 - FTBFS: install-strip fails because
bfdlib relinks and fails to find libsframe, the install time
dependencies of libbfd need to be updated.

PR libsframe/30014
* Makefile.def: Reflect that libsframe needs to installed before
libbfd.  Reorder a bit to better track libsframe dependencies.
* Makefile.in: Regenerate.

22 months agoThe fuzzers have found the reloc special functions in coff-aarch64.c
Alan Modra [Tue, 17 Jan 2023 11:23:00 +0000 (21:53 +1030)]
The fuzzers have found the reloc special functions in coff-aarch64.c

All of them need a bfd_reloc_offset_in_range check before accessing
data + reloc_entry->address.  This patch adds the missing checks and
sanity checks reloc offsets in coff_pe_aarch64_relocate_section too.

All of them also need changing to support objdump -W calls to
bfd_simple_get_relocated_section_contents.  At least, secrel_reloc
needs the support, the others might not be present in dwarf debug
sections.

* coff-aarch64.c (coff_aarch64_rel21_reloc): Range check
reloc offset.  Support final-linking.
(coff_aarch64_po12l_reloc): Likewise.
(coff_aarch64_addr32nb_reloc): Likewise.
(coff_aarch64_secrel_reloc): Likewise.
(coff_pe_aarch64_relocate_section): Range check reloc offset.

22 months agoCorrect coff-aarch64 howtos and delete unnecessary special functions
Alan Modra [Sat, 14 Jan 2023 11:43:30 +0000 (22:13 +1030)]
Correct coff-aarch64 howtos and delete unnecessary special functions

The remaining special functions are still broken except when called
by gas bfd_install_relocation.

* coff-aarch64.c (coff_aarch64_addr64_reloc),
(coff_aarch64_addr32_reloc, coff_aarch64_branch26_reloc),
(coff_aarch64_branch19_reloc, coff_aarch64_branch14_reloc),
(coff_aarch64_po12a_reloc): Delete.
(HOWTO_INSTALL_ADDEND): Define as 1.
(HOW): Remove pcrel_off.  Correct all the howtos.
(CALC_ADDEND): Define.
(coff_aarch64_rtype_to_howto): New function.
(coff_rtype_to_howto): Define.

22 months agocoff-aarch64.c howtos
Alan Modra [Fri, 13 Jan 2023 06:11:54 +0000 (16:41 +1030)]
coff-aarch64.c howtos

This is just a patch to fix overlong lines.  Wrapping the HOWTO macro
in a new HOW macro helps in this.  No functional changes here.

* coff-aarch64.c (HOW): Define and use for reloc howtos.

22 months agohowto install_addend
Alan Modra [Mon, 16 Jan 2023 02:19:03 +0000 (12:49 +1030)]
howto install_addend

This adds a new flag to the reloc howtos that can be used to
incrementally change targets over to simple bfd_install_relocation
that just installs the addend without any weird adjustments.
I've made a few other changes to bfd_install_relocation, removing dead
code and comments that are really only applicable to
bfd_perform_relocation.

There is also a reloc offset bounds check change.  I've moved the
check to where data is accessed, as it seems reasonable to me to not
perform the check unless it is needed.  There is precedence for this;
Relocations against absolute symbols already avoided the check.

I also tried always performing the reloc offset check, and ran into
testsuite failures due to _NONE and _ALIGN relocs at the end of
sections.  These likely would be fixed if all such reloc howtos had
size set to zero, but I would rather not edit lots of files when it
involves checking that target code does not use the size.

* reloc.c (struct reloc_howto_struct): Add install_addend.
(HOWTO_INSTALL_ADDEND): Define.
(HOWTO): Init new field with HOWTO_INSTALL_ADDEND.
(bfd_install_relocation): Remove comments copied from
bfd_perform_relocation that aren't applicable here.  Remove
code dealing with output_offset and output_section.  Just set
relocation to addend if install_addend.  Move reloc offset
bounds check to just before section data is accessed, avoiding
the check when data is not accessed.
* bfd-in2.h: Regenerate.

22 months agosim: info: convert verbose field to a bool
Mike Frysinger [Thu, 19 Jan 2023 01:14:54 +0000 (20:14 -0500)]
sim: info: convert verbose field to a bool

The verbose argument has always been an int treated as a bool, so
convert it to an explicit bool.  Further, update the API docs to
match the reality that the verbose value is actually used by some
of the internal modules.

22 months agosim: unify sim-signal.o building
Mike Frysinger [Thu, 19 Jan 2023 00:26:58 +0000 (19:26 -0500)]
sim: unify sim-signal.o building

Now that sim-main.h has been reduced significantly, we can remove it
from sim-signal.c and unify it across all boards since it compiles to
the same code.

22 months agosim: v850: reduce extra header inclusion to igen files
Mike Frysinger [Thu, 19 Jan 2023 00:11:38 +0000 (19:11 -0500)]
sim: v850: reduce extra header inclusion to igen files

Limit these extra header includes to only when specific igen files
include us until we can move the includes to the igen fils directly.

22 months agosim: v850: drop redundant define
Mike Frysinger [Thu, 19 Jan 2023 00:07:19 +0000 (19:07 -0500)]
sim: v850: drop redundant define

This is already in v850/local.mk, so we can drop it from sim-main.h.

22 months agosim: mn10300: minimize mn10300-sim.h include in sim-main.h
Mark Wielaard [Sun, 15 Jan 2023 19:24:06 +0000 (20:24 +0100)]
sim: mn10300: minimize mn10300-sim.h include in sim-main.h

sim-main.h is special since it is one of the files automatically
included in igen generated files. But this means anything including
sim-main.h might get everything included just for the igen files.

To prevent clashing symbols/defines only include sim-fpu.h,
sim-signal.h, mn10300-sim.h from sim-main.h if it is included
from one of the generated igen C files. Add explicit includes
of mn10300-sim.h, sim-fpu.h and/or sim-signal.h to dv-mn103cpu.c,
interp.c and op_utils.c.

22 months agoAutomatic date update in version.in
GDB Administrator [Thu, 19 Jan 2023 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agoGDB: Add references to erased args in cli-decode.c
Maciej W. Rozycki [Wed, 18 Jan 2023 23:38:50 +0000 (23:38 +0000)]
GDB: Add references to erased args in cli-decode.c

Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct within
cmd_list_element") and commit 702991711a91 ("gdb: Have setter and getter
callbacks for settings") and update inline documentation accordingly for
`add_set_or_show_cmd' and `add_setshow_cmd_full_erased', documenting the
`args' parameter and removing references to `var', `set_setting_func'
and `get_setting_func'.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
22 months agoGDB: Add missing inline documentation for `add_setshow_cmd_full'
Maciej W. Rozycki [Wed, 18 Jan 2023 23:23:00 +0000 (23:23 +0000)]
GDB: Add missing inline documentation for `add_setshow_cmd_full'

Complement commit 1d7fe7f01b93 ("gdb: Introduce setting construct
within cmd_list_element") and add missing description for
`add_setshow_cmd_full'.

22 months agoGDB: Correct inline documentation for `add_setshow_cmd_full_erased'
Maciej W. Rozycki [Wed, 18 Jan 2023 23:23:00 +0000 (23:23 +0000)]
GDB: Correct inline documentation for `add_setshow_cmd_full_erased'

Use proper English in the description of SET_LIST and SHOW_LIST.

22 months agoGDB: Fix documentation for `theclass' parameters in cli-decode.c
Maciej W. Rozycki [Wed, 18 Jan 2023 21:54:37 +0000 (21:54 +0000)]
GDB: Fix documentation for `theclass' parameters in cli-decode.c

Rename CLASS to THECLASS in the documentation for `theclass' parameters
throughout cli-decode.c, complementing commit fe978cb071b4 ("C++ keyword
cleanliness, mostly auto-generated").

Approved-By: Simon Marchi <simon.marchi@efficios.com>
22 months agoFix 'make TAGS' in gdbserver
Tom Tromey [Fri, 23 Dec 2022 20:28:20 +0000 (13:28 -0700)]
Fix 'make TAGS' in gdbserver

PR build/29003 points out that "make TAGS" is broken in gdbserver.
This patch fixes the problem that is pointed out there, plus another
one I noticed while working on that -- namely that the "sed" computes
the wrong names for some source files.  Finally, a couple of obsolete
variable references are removed.

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

22 months agoRevert "X86: reverse-finish fix"
Carl Love [Wed, 18 Jan 2023 16:13:17 +0000 (11:13 -0500)]
Revert "X86: reverse-finish fix"

This reverts commit b22548ddb30bfb167708e82d3bb932461c1b703a.

This patch is being reverted since the patch series is causing regressions.

22 months agoRevert "PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-rever...
Carl Love [Wed, 18 Jan 2023 16:12:13 +0000 (11:12 -0500)]
Revert "PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp"

This reverts commit 92e07580db6a5572573d5177ca23933064158f89.

Reverting patch as the patch series is causing regressions.

22 months agogdb: care for dynamic objfiles in build_id_bfd_get ()
Jan Vrany [Wed, 18 Jan 2023 11:34:37 +0000 (11:34 +0000)]
gdb: care for dynamic objfiles in build_id_bfd_get ()

Accessing gdb.Objfile.build_id caused GDB to crash when objfile is
dynamic, that is created by JIT reader API.

The issue was NULL-pointer dereferencing in build_id_bfd_get () because
dynamic objfiles have no underlaying BFD structure. This commit fixes
the problem by a NULL-check in build_id_bfd_get ().

22 months agoSpeed up objcopy's note merging.
Nick Clifton [Wed, 18 Jan 2023 11:32:21 +0000 (11:32 +0000)]
Speed up objcopy's note merging.

   PR 29993
  * objcopy.c (merge_gnu_build_notes): Remember the last non-deleted note in order to speed up the scan for matching notes.

22 months agosim: ppc: drop local psim link
Mike Frysinger [Wed, 18 Jan 2023 04:21:31 +0000 (23:21 -0500)]
sim: ppc: drop local psim link

This has never been installed, and it's not clear anyone cares about
it in the local build dir (when the main program is sim/ppc/run), so
drop all the logic to simplify.

22 months agoUse subsystem to distinguish between pei-arm-little and pei-arm-wince-little
Mark Harmstone [Wed, 11 Jan 2023 18:32:04 +0000 (18:32 +0000)]
Use subsystem to distinguish between pei-arm-little and pei-arm-wince-little

Running objdump against a 32-bit ARM PE file currently needs
disambiguation, as it gets picked up by both pei-arm-little and
pei-arm-wince-little.

This adds a check in pe_bfd_object_p so that the subsystem in the PE
header is used to do the disambiguation for us, so that WinCE images get
assigned to pei-arm-wince-little, and everything else to pei-arm-little.

22 months agoRevert "gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'"
Vladimir Mezentsev [Wed, 18 Jan 2023 02:53:38 +0000 (18:53 -0800)]
Revert "gprofng: PR29987 bfd/archive.c:1447: undefined reference to `filename_ncmp'"

This reverts commit c2a5d74050ea9d7897b4122ef57c627d395683b3.

22 months agoAutomatic date update in version.in
GDB Administrator [Wed, 18 Jan 2023 00:00:17 +0000 (00:00 +0000)]
Automatic date update in version.in

22 months agoRemove two unused fields from gdbarch
Tom Tromey [Tue, 17 Jan 2023 19:45:11 +0000 (12:45 -0700)]
Remove two unused fields from gdbarch

When I converted gdbarch to use the registry, I forgot to remove the
two fields that were used to implement the previous approach.  This
patch removes them.  Tested by rebuilding.

22 months agoUse require in paramless.exp
Tom Tromey [Tue, 17 Jan 2023 18:45:40 +0000 (11:45 -0700)]
Use require in paramless.exp

The new paramless.exp test was not converted to the new "require"
approach.  This patch fixes the problem.

22 months agoPowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
Carl Love [Fri, 13 Jan 2023 22:59:33 +0000 (17:59 -0500)]
PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

PR record/29927 - reverse-finish requires two reverse next instructions to
reach previous source line

PowerPC uses two entry points called the local entry point (LEP) and the
global entry point (GEP).  Normally the LEP is used when calling a
function.  However, if the table of contents (TOC) value in register 2 is
not valid the GEP is called to setup the TOC before execution continues at
the LEP.  When executing in reverse, the function finish_backward sets the
break point at the alternate entry point (GEP).  However if the forward
execution enters via the normal entry point (LEP), the reverse execution
never sees the break point at the GEP of the function.  Reverse execution
continues until the next break point is encountered or the end of the
recorded log is reached causing gdb to stop at the wrong place.

This patch adds a new address to struct execution_control_state to hold the
address of the alternate function start address, known as the GEP on
PowerPC.  The finish_backwards function is updated.  If the stopping point
is between the two entry points (the LEP and GEP on PowerPC), the stepping
range is set to execute back to the alternate entry point (GEP on PowerPC).
Otherwise, a breakpoint is inserted at the normal entry point (LEP on
PowerPC).

Function process_event_stop_test checks uses a stepping range to stop
execution in the caller at the first instruction of the source code line.
Note, on systems that only support one entry point, the address of the two
entry points are the same.

Test finish-reverse-next.exp is updated to include tests for the
reverse-finish command when the function is entered via the normal entry
point (i.e. the LEP) and the alternate entry point (i.e. the GEP).

The patch has been tested on X86 and PowerPC with no regressions.

22 months agoX86: reverse-finish fix
Carl Love [Mon, 19 Dec 2022 17:48:54 +0000 (12:48 -0500)]
X86: reverse-finish fix

PR record/29927  - reverse-finish requires two reverse next instructions to
reach previous source line

Currently on X86, when executing the finish command in reverse, gdb does a
single step from the first instruction in the callee to get back to the
caller.  GDB stops on the last instruction in the source code line where
the call was made.  When stopped at the last instruction of the source code
line, a reverse next or step command will stop at the first instruction
of the same source code line thus requiring two step/next commands to
reach the previous source code line.  It should only require one step/next
command to reach the previous source code line.

By contrast, a reverse next or step command from the first line in a
function stops at the first instruction in the source code line where the
call was made.

This patch fixes the reverse finish command so it will stop at the first
instruction of the source line where the function call was made.  The
behavior on X86 for the reverse-finish command now matches doing a
reverse-next from the beginning of the function.

The proceed_to_finish flag in struct thread_control_state is no longer
used.  This patch removes the declaration, initialization and setting of
the flag.

This patch requires a number of regression tests to be updated.  Test
gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
previous line.  The gdb output for tests gdb.reverse/until-precsave.exp
and gdb.reverse/until-reverse.exp changed slightly.  The expected result in
tests gdb.reverse/amd64-failcall-reverse.exp and
gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
result.

This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
reverse-finish command when returning from the entry point and from the
body of the function.

The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
was moved to lib/gdb.exp and renamed cmd_until.

The patch has been tested on X86 and PowerPC to verify no additional
regression failures occured.

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

22 months agogdb/testsuite: expect SIGSEGV from top GDB spawn id
Simon Marchi [Sat, 14 Jan 2023 01:08:41 +0000 (20:08 -0500)]
gdb/testsuite: expect SIGSEGV from top GDB spawn id

When testing with the native-extended-gdbserver, I get:

    Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.
    0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1
    (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt

This is because the -re that is supposed to match this SIGSEGV is after
`-i $inferior_spawn_id`.  On native, the top and bottom GDB are on the
same spawn id, so it ends up working.  But with a gdbserver board,
that's not the case.  Move the SIGSEGV -re before the `-i
$inferior_spawn_id` line, such that it matches what the top GDB outputs.

Do the same fix in gdb.gdb/python-helper.exp.

Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927
Approved-By: Tom Tromey <tom@tromey.com>
22 months agoFix parameter-less template regression in new DWARF reader
Tom Tromey [Wed, 14 Dec 2022 21:37:41 +0000 (14:37 -0700)]
Fix parameter-less template regression in new DWARF reader

PR c++/29896 points out a regression in the new DWARF reader.  It does
not properly handle a case like "break fn", where "fn" is a template
function.

This happens because the new index uses strncasecmp to compare.
However, to make this work correctly, we need a custom function that
ignores template parameters.

This patch adds a custom comparison function and fixes the bug.  A new
test case is included.

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

22 months agoMove hash_entry and eq_entry into cooked_index::do_finalize
Tom Tromey [Thu, 15 Dec 2022 16:38:05 +0000 (09:38 -0700)]
Move hash_entry and eq_entry into cooked_index::do_finalize

I was briefly confused by the hash_entry and eq_entry functions in the
cooked index.  They are only needed in a single method, and that
method already has a couple of local lambdas for a different hash
table.  So, it seemed cleaner to move these there as well.

22 months agoDon't erase empty indices in DWARF reader
Tom Tromey [Wed, 14 Dec 2022 14:20:49 +0000 (07:20 -0700)]
Don't erase empty indices in DWARF reader

The DWARF reader has some code to remove empty indices.  However, I
think this code has been obsolete since some earlier changes to
parallel_for_each.  This patch removes this code.

22 months agoAvoid submitting empty tasks in parallel_for_each
Tom Tromey [Tue, 13 Dec 2022 19:03:34 +0000 (12:03 -0700)]
Avoid submitting empty tasks in parallel_for_each

I found that parallel_for_each would submit empty tasks to the thread
pool.  For example, this can happen if the number of tasks is smaller
than the number of available threads.  In the DWARF reader, this
resulted in the cooked index containing empty sub-indices.  This patch
arranges to instead shrink the result vector and process the trailing
entries in the calling thread.

22 months agogas: arm: Change warning message to not reference specific A-class architecture revision
Stam Markianos-Wright [Tue, 17 Jan 2023 13:37:40 +0000 (13:37 +0000)]
gas: arm: Change warning message to not reference specific A-class architecture revision

We noticed that a warning message about the use of scalar fp16
instructions being UNPREDICTABLE when conditionalized in an IT
block referenced the specific A-class architecture revision
ARMv8.2-A.
Many of these instructions are now also part of ARMv8.1-M, so
the warning message had become misleading.  Here we just change
the message to not specify an architecture revision at all and
update all testing accordingly.  This was done with a simple
find-n-replace within the binutils sources.  No tests have
regressed for the arm target.

gas/ChangeLog:

        * config/tc-arm.c (do_scalar_fp16_v82_encode): Remove
        ARMv8.2-A from the warning message.
        (do_neon_movhf): Likewise
        * testsuite/gas/arm/armv8-2-fp16-scalar-bad.l: Likewise
        * testsuite/gas/arm/mve-vaddsub-it-bad.l: Likewise
        * testsuite/gas/arm/mve-vcvtne-it-bad.l: Likewise
        * testsuite/gas/arm/mve-vcvtne-it.d: Likewise

22 months agogas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn
Stam Markianos-Wright [Tue, 17 Jan 2023 12:57:47 +0000 (12:57 +0000)]
gas: arm: Fix a further IT-predicated vcvt issue in the presense of MVE vcvtn

Previously we had experienced issues with assembling a "VCVTNE" instruction
in the presence of the MVE architecture extension, because it could be
interpreted both as:

* The base instruction VCVT + NE for IT predication when inside an IT block.
* The MVE instruction VCVTN + E in the Else of a VPT block.

Given a C reproducer of:
```
int test_function(float value)
{
  int ret_val = 10;
  if (value != 0.0)
  {
    ret_val = (int) value;
  }
  return ret_val;
}
```
GCC generates a VCVTNE instruction based on the `truncsisf2_vfp`
pattern, which will look like:
`vcvtne.s32.f32 s-reg, s-reg`
This still triggers an error due to being misidentified as "vcvtn+e"
Similar errors were found with other type combinations and instruction
patterns (these have all been added to the testing of this patch).

This class of errors was previously worked around by:
https://sourceware.org/pipermail/binutils/2020-August/112728.html
which addressed this by looking at the operand types, however,
that isn't adequate to cover all the extra cases that have been
found.  Instead, we add some special-casing logic earlier when
the instructions are parsed that is conditional on whether we are
in a VPT block or not, when the instruction is parsed.

gas/ChangeLog:

* config/tc-arm.c (opcode_lookup): Add special vcvtn handling.
* testsuite/gas/arm/mve-vcvtne-it-bad.l: Add further testing.
* testsuite/gas/arm/mve-vcvtne-it-bad.s: Likewise.
* testsuite/gas/arm/mve-vcvtne-it.d: Likewise.
* testsuite/gas/arm/mve-vcvtne-it.s: Likewise.

22 months agoFix snafu in previous delta for elf32-csky.c
Nick Clifton [Tue, 17 Jan 2023 12:55:33 +0000 (12:55 +0000)]
Fix snafu in previous delta for elf32-csky.c