I found a typo in a test name in py-arch.exp.

A sequence such as:

	li	at,-1
	bne	xx,at,0f
	 li	at,1
	dsll32	at,at,0x1f

is produced in the expansion of the DDIV and DREM assembly macros, where
a redundant `li at,1' instruction is used to load an intermediate value
of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f'
yielding 0x8000000000000000.  However this value likewise results from
left-shifting the value of -1, already present in $at at this point.

Remove the extraneous instruction then, shortening the sequence emitted.
Adjust dumps in the testsuite accordingly.

Add `--show-raw-insn' to division tests so as to verify branch offsets
without the need to know actual offsets into the text section individual
instructions have been assembled at.  Add `-z' where applicable to make
interlock NOP instructions appear in output so as to verify them without
the need to know the offsets too.  Replace individual offsets to match
against with generic patterns so that a change in the expansion of an
assembly macro does not affect code that follows.

Rewrite the inline documentation for the characters used in the `args'
member of `struct mips_opcode' to make it consistent in terms of style
and formatting.  Discard references to inexistent macros.

Following

        commit 6cce0251
        Date:   Fri Mar 3 19:03:15 2023 +0000

            gdb: only insert thread-specific breakpoints in the relevant inferior

... when building amd-dbgapi-target.c:

      CXX    amd-dbgapi-target.o
    /home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override
      486 |   void re_set () override;
          |        ^~~~~~

Update the signature to match the base.

Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692

After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
 <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
    <120>   DW_AT_specification: <0x130>
 <2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
    <125>   DW_AT_name        : val1
    <12a>   DW_AT_const_value : 1
 <2><12b>: Abbrev Number: 0
 <1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
    <12d>   DW_AT_name        : ns
 <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
    <131>   DW_AT_name        : e
    <133>   DW_AT_type        : <0x118>
    <137>   DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
  Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...

This was reported in PR32160 comment 1.

This is a regression since commit 4e417d7b ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Fix this by reverting the commit.

[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]

That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
    [27] ((cooked_index_entry *) 0x7fbbb4002ef0)
    name:       val1
    canonical:  val1
    qualified:  val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x124
    parent:     ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked.  This is to be
addressed in a follow-up patch.

Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix?  I've investigated this and filed
PR32160 to track this.

My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.

Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
  occur, and
- a DIE that represent the parent scope.

In most cases, these two are the same, but some times they're not.

The debug info above demonstrates such a case.  The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.

In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.

So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.

Tested on x86_64-linux.

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

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160

Consider test-case:
...
namespace ns {
  enum class ec {
    val2 = 2
  };
}

int main () {
  return (int)ns::ec::val2;
}
...
compiled with debug info:
...
$ g++ test.c -g
...

When looking at the cooked index entry for val2 using "maint print objfiles",
we get:
...
    [7] ((cooked_index_entry *) 0x7f8ecc002ef0)
    name:       val2
    canonical:  val2
    qualified:  ns::val2
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0xe9
    parent:     ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
...
which is wrong, there is no source level entity ns::val2.

This is PR symtab/32158.

This is a regression since commit 4e417d7b ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Reverting the commit on current trunk fixes the problem, and gets us instead:
...
    [7] ((cooked_index_entry *) 0x7fba70002ef0)
    name:       val2
    canonical:  val2
    qualified:  ns::ec::val2
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0xe9
    parent:     ((cooked_index_entry *) 0x7fba70002ec0) [ec]
...

Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.

Tested on x86_64-linux.

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

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

Consider the following test-case:
...
$ cat a.h
namespace ns {

class A {
public:
  enum {
    val1 = 1
  };
};

}
$ cat main.c

ns::A a;

int
main (void)
{
  return 0;
}
$ cat val1.c

int u1 = ns::A::val1;
...
compiled with debug info:
...
$ g++ main.c val1.c -g
...

When trying to print ns::A::val with current trunk and gdb 15.1 we get:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
There is no field named val1
...

This PR c++/31900.

With gdb 14.2 we get the expected:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
$1 = ns::A::val1
...

This is a regression since commit 4e417d7b ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Reverting the commit on current trunk fixes the problem.

So how does this problem happen?

First, let's consider the current trunk, with the commit reverted.

Gdb looks for the entry ns::A::val1, and find this entry:
...
    [29] ((cooked_index_entry *) 0x7f7830002ef0)
    name:       val1
    canonical:  val1
    qualified:  ns::A::val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x15a
    parent:     ((cooked_index_entry *) 0x7f7830002ec0) [A]
...
and expands the corresponding CU val1.c containing this debug info:
...
 <2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
    <14b>   DW_AT_name        : A
    <14d>   DW_AT_byte_size   : 1
 <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
    <151>   DW_AT_encoding    : 7       (unsigned)
    <152>   DW_AT_byte_size   : 4
    <153>   DW_AT_type        : <0x163>
    <159>   DW_AT_accessibility: 1      (public)
 <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
    <15b>   DW_AT_name        : val1
    <15f>   DW_AT_const_value : 1
 <4><160>: Abbrev Number: 0
 <3><161>: Abbrev Number: 0
 <2><162>: Abbrev Number: 0
...
after which it finds ns::A::val1 in the expanded symtabs.

Now let's consider the current trunk as is (so, with the commit present).

Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
entry is missing its parent:
...
   [29] ((cooked_index_entry *) 0x7f5240002ef0)
    name:       val1
    canonical:  val1
    qualified:  val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x15a
    parent:     ((cooked_index_entry *) 0)
...

Then gdb looks for the entry ns::A, and finds this entry:
...
   [3] ((cooked_index_entry *) 0x7f5248002ec0)
    name:       A
    canonical:  A
    qualified:  ns::A
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0xdd
    parent:     ((cooked_index_entry *) 0x7f5248002e90) [ns]
...
which corresponds to this debug info, which doesn't contain val1
due to -fno-eliminate-unused-debug-types:
...
 <2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
    <de>   DW_AT_name        : A
    <e0>   DW_AT_byte_size   : 1
 <2><e3>: Abbrev Number: 0
...

Gdb expands the corresponding CU main.c, after which it doesn't find
ns::A::val1 in the expanded symtabs.

The root cause of the problem is the missing parent on the val1
cooked_index_entry, but this only becomes user-visible through the
elaborate scenario above.

Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
for this problem that doesn't rely on expansion state or
-feliminate-unused-debug-types, but simply tests for the root cause by
grepping for ns::A::val1 in the output of "maint print objfile".

Tested on x86_64-linux.

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

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

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

Commit f89276a2 ("change type of `general_symbol_info::m_section`
to int") did what it says in the title -- changed the type of the
section index from short to int.  However, it seems incomplete, in
that there are uses of the section index that use the type 'short'.

This patch fixes the ones I found, first by searching for
"short.*sect" and then by looking at all the callers of section_index
(and then functions called with the resulting value) just to try to be
more sure.

Approved-by: Kevin Buettner <kevinb@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

When the filename quoting change was merged into the AdaCore tree, we
saw a regression in a test setup that uses the DWARF 5 index (that is
running gdb-add-index), and a filename with a space in it.

Initially I thought this was a change in the 'file' command -- but
looking again, I found out that 'file' has worked this way for a
while, and our immediate error was caused by the (documented) change
to "save gdb-index".

While I'm not sure why this test was working previously, it seems to
me that gdb-add-index.sh requires a change to quote the arguments to
"file" and "save gdb-index".

While working on this, though, it seemed to me that multiple other
spots needed quoting for the script to work correctly.  And, I was
unable to get quoting working correctly in the objcopy calls, so I
split it into multiple different invocations.

Approved-by: Kevin Buettner <kevinb@redhat.com>

Oleg Tolmatcev noticed that DAP launch and attach requests don't
properly handle Windows filenames, because "file" doesn't handle the
backslash characters correctly.  This patch adds quoting to the
command in an attempt to fix this.

Functions implementing `solib_ops::current_sos` return a list of solib
object, transferring the ownership to their callers.  However, the
return type, `intrusive_list<solib>`, does not reflect that.

Also, some of these functions build these lists incrementally, reading
this from the target for each solib.  If a target read were to throw,
for instance, the already created solibs would just be leaked.

Change `solib_ops::current_sos` to return an owning_intrusive_list to
address that.  Change `program_space::so_list` to be an
owning_intrusive_list as well.  This also saves us doing a few manual
deletes.

Change-Id: I6e4071d49744874491625075136c59cce8e608d4
Reviewed-by: Keith Seitz <keiths@redhat.com>

It occured to me that `intrusive_list<solib>`, as returned by
`solib_ops::current_sos`, for instance, is not very safe.  The
current_sos method returns the ownership of the solib objects
(heap-allocated) to its caller, but the `intrusive_list<solib>` type
does not convey it.  If a function is building an
`intrusive_list<solib>` and something throws, the solibs won't
automatically be deleted.  Introduce owning_intrusive_list to fill this
gap.

Interface
---------

The interface of owning_intrusive_list is mostly equivalent to
intrusive_list, with the following differences:

 - When destroyed, owning_intrusive_list deletes all element objects.
   The clear method does so as well.

 - The erase method destroys the removed object.

 - The push_front, push_back and insert methods accept a `unique_ptr<T>`
   (compared to `T &` for intrusive_list), taking ownership of the
   object.

 - owning_intrusive_list has emplace_front, emplace_back and emplace
   methods, allowing to allocate and construct an object directly in the
   list.  This is really just a shorthand over std::make_unique and
   insert (or push_back / push_front if you don't care about the return
   value), but I think it is nicer to read:

     list.emplace (pos, "hello", 2);

   rather than

     list.insert (pos, std::make_unique<Foo> ("hello", 2));

   These methods are not `noexcept`, since the allocation or the
   constructor could throw.

 - owning_intrusive_list has a release method, allowing to remove an
   element without destroying it.  The release method returns a
   pair-like struct with an iterator to the next element in the list
   (like the erase method) and a unique pointer transferring the
   ownership of the released element to the caller.

 - owning_intrusive_list does not have a clear_and_dispose method, since
   that is typically used to manually free items.

Implementation
--------------

owning_intrusive_list privately inherits from intrusive_list, in order
to re-use the linked list machinery.  It adds ownership semantics around
it.

Testing
-------

Because of the subtle differences in the behavior in behavior and what
we want to test for each type of intrusive list, I didn't see how to
share the tests for the two implementations.  I chose to copy the
intrusive_list tests and adjust them for owning_intrusive_list.

The verify_items function was made common though, and it tries to
dereference the items in the list, to make sure they have not been
deleted by mistake (which would be caught by Valgrind / ASan).

Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760
Co-Authored-By: Pedro Alves <pedro@palves.net>
Reviewed-by: Keith Seitz <keiths@redhat.com>

Make the insert method return an iterator to the inserted element.  This
mimics what boost does [1] and what the standard library insert methods
generally do [2].

[1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33771-bb
[2] https://en.cppreference.com/w/cpp/container/vector/insert



Change-Id: I59082883492c60ee95e8bb29a18c9376283dd660
Reviewed-by: Keith Seitz <keiths@redhat.com>

Some methods of intrusive_list are marked noexcept.  But really,
everything in that file could be noexcept.  Add it everywhere.

The only one I had a doubt about is clear_and_dispose: what if the
disposer throws?  The boost equivalent [1] is noexcept and requires the
disposer not to throw.  The rationale is probably the same as for
destructors.  What if the disposer throws for an element in the middle
of the list?  Do you skip the remaining elements?  Do you swallow the
exception and keep calling the disposer for the remaining elements?
It's simpler to say no exceptions allowed.

[1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33710-bb



Change-Id: I402646cb12c6b7906f4bdc2ad85203d8c8cdf2cc
Reviewed-by: Keith Seitz <keiths@redhat.com>

Several tests in gdb.trace trigger TCL errors if the In-Process Agent
library is not found, e.g.:

  Running gdb/testsuite/gdb.trace/change-loc.exp ...
  ERROR: tcl error sourcing gdb/testsuite/gdb.trace/change-loc.exp.
  ERROR: error copying "gdb/gdb/testsuite/../../gdbserver/libinproctrace.so":
	 no such file or directory
      while executing
  "file copy -force $fromfile $tofile"
      (procedure "gdb_remote_download" line 29)
      invoked from within
  "gdb_remote_download target $target_file"
      (procedure "gdb_download_shlib" line 6)
      invoked from within
  "gdb_download_shlib $file"
      (procedure "gdb_load_shlib" line 2)
      invoked from within
  "gdb_load_shlib $libipa"
      (file "gdb/testsuite/gdb.trace/change-loc.exp" line 354)
      invoked from within
  "source gdb/testsuite/gdb.trace/change-loc.exp"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 source gdb/testsuite/gdb.trace/change-loc.exp"
      invoked from within
  "catch "uplevel #0 source $test_file_name""

Protect against this error by checking if the library is available.

Distributions like Debian [0] and Gentoo are phasing out the use of
the non-portable `which` utility. Use POSIX's `command -v` instead.

[0] https://lwn.net/Articles/874049/

gprofng/ChangeLog
	PR gprofng/32166
	* testsuite/lib/Makefile.skel (JAVABIN): Replace use of which.

The binary provided with bug 32165 [1] has 36139 ELF sections.  GDB
crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1:

    $ ./gdb  -nx -q --data-directory=data-directory ./vmlinux
    Reading symbols from ./vmlinux...
    (No debugging symbols found in ./vmlinux)
    (gdb) info func
    /usr/include/c++/14.2.1/debug/vector:508:
    In function:
        std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp,
        _Allocator>::operator[](size_type) [with _Tp = long unsigned int;
        _Allocator = std::allocator<long unsigned int>; reference = long
        unsigned int&; size_type = long unsigned int]

    Error: attempt to subscript container with out-of-bounds index -29445, but
    container only holds 36110 elements.

    Objects involved in the operation:
        sequence "this" @ 0x514000007340 {
          type = std::debug::vector<unsigned long, std::allocator<unsigned long> >;
        }

The crash occurs here:

    #3  0x00007ffff5e334c3 in __GI_abort () at abort.c:79
    #4  0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320
    #5  0x0000555561119a16 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[] (this=0x514000007340, __n=18446744073709522171)
        at /usr/include/c++/14.2.1/debug/vector:508
    #6  0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517
    #7  0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value])
        at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983
    #8  0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189
    #9  0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1)
        at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361
    #10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525

That is, at this line of `minimal_symbol::value_address`, where
`objfile->section_offsets` is an `std::vector`:

    return (CORE_ADDR (this->unrelocated_address ())
	    + objfile->section_offsets[this->section_index ()]);

A section index of -29445 is suspicious.  The minimal_symbol at play
here is:

    (top-gdb) p m_name
    $1 = 0x521001de10af "_sinittext"

So I restarted debugging, breaking on:

   (top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name)

And I see that weird -29445 value:

    (top-gdb) frame
    #0  general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611
    611       { m_section = idx; }

But going up one frame, the section index is 36091:

    (top-gdb) frame
    #1  0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false,
        address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228
    1228      msymbol->set_section_index (section);

It seems like the problem is just that the type used for the section
index (short) is not big enough.  Change from short to int.  If somebody
insists, we could even go long long / int64_t, but I doubt it's
necessary.

With that fixed, I get:

    (gdb) info func
    All defined functions:

    Non-debugging symbols:
    0xffffffff81000000  _stext
    0xffffffff82257000  _sinittext
    0xffffffff822b4ebb  _einittext

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165



Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>

This leverages commit ("s390: Simplify (dis)assembly of insn operands
with const bits") to relax the operand constraints of the immediate
operand that contains the constant Z- or T-bit of the following extended
mnemonics:
risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt

Previously those instructions were the only ones where the assembler
on s390 restricted the specification of the subject I3/I4 operand values
exactly according to their specification to an unsigned 6- or 5-bit
unsigned integer. For any other instructions the assembler allows to
specify any operand value allowed by the instruction format, regardless
of whether the instruction specification is more restrictive.

Allow to specify the subject I3/I4 operand as unsigned 8-bit integer
with the constant operand bits being ORed during assembly.
Relax the instructions subject significant operand bit masks to only
consider the Z/T-bit as significant, so that the instructions get
disassembled as their *z or *t flavor regardless of whether any reserved
bits are set in addition to the Z/T-bit.
Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set
the T-bit in operand I3, as they otherwise get disassembled as their
rnsbgt, rosbgt, and rxsbgt counterpart.

This aligns GNU Assembler to LLVM Assembler.

opcodes/
	* s390-opc.c (U6_18, U5_27, U6_26): Remove.
	(INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define
	as INSTR_RIE_RRUUU while retaining insn fmt mask.
	(MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only
	Z/T-bit of I3/I4 operand as significant.

gas/testsuite/
	* gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit.

Reported-by: Dominik Steenken <dost@de.ibm.com>
Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

Simplify assembly and disassembly of extended mnemonics with operands
with constant ORed bits:
Their instruction template already contains the respective constant
operand bits, as they are significant to distinguish the extended from
their base mnemonic. Operands are ORed into the instruction template.
Therefore it is not necessary to OR the constant bits into the operand
value during assembly in s390_insert_operand.
Additionally the constant operand bits from the instruction template
can be used to mask them from the operand value during disassembly in
s390_print_insn_with_opcode. For now do so for non-length unsigned
integer operands only.

The separate instruction formats need to be retained, as their masks
differ, which is relevant during disassembly to distinguish the base
and extended mnemonics from each other.

This affects the following extended mnemonics:
- vfaebs, vfaehs, vfaefs
- vfaezb, vfaezh, vfaezf
- vfaezbs, vfaezhs, vfaezfs
- vstrcbs, vstrchs, vstrcfs
- vstrczb, vstrczh, vstrczf
- vstrczbs, vstrczhs, vstrczfs
- wcefb, wcdgb
- wcelfb, wcdlgb
- wcfeb, wcgdb
- wclfeb, wclgdb
- wfisb, wfidb, wfixb
- wledb, wflrd, wflrx

include/
	* opcode/s390.h (S390_OPERAND_OR1, S390_OPERAND_OR2,
	S390_OPERAND_OR8): Remove.

opcodes/
	* s390-opc.c (U4_OR1_24, U4_OR2_24, U4_OR8_28): Remove.
	(INSTR_VRR_VVV0U1, INSTR_VRR_VVV0U2, INSTR_VRR_VVV0U3): Define
	as INSTR_VRR_VVV0U0 while retaining respective insn fmt mask.
	(INSTR_VRR_VV0UU8): Define as INSTR_VRR_VV0UU while retaining
	respective insn fmt mask.
	(INSTR_VRR_VVVU0VB1, INSTR_VRR_VVVU0VB2, INSTR_VRR_VVVU0VB3):
	Define as INSTR_VRR_VVVU0VB while retaining respective insn fmt
	mask.
	* s390-dis.c (s390_print_insn_with_opcode): Mask constant
	operand bits set in insn template of non-length unsigned
	integer operands.

gas/
	* config/tc-s390.c (s390_insert_operand): Do not OR constant
	operand value bits.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>

Fixed UBSAN runtime errors such as:
 - load of value 4294967295, which is not a valid value for type 'Cmsg_warn'
 - null pointer passed as argument 2, which is declared to never be null
 - load of value 4294967295, which is not a valid value for type 'ProfData_type'
 - reference binding to misaligned address 0x00000357583c for type 'long unsigned int', which requires 8 byte alignment

gprofng/ChangeLog
2024-09-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>.

	PR gprofng/32096
	* src/BaseMetric.cc: Fix UBSAN runtime errors.
	* src/BaseMetric.h: Likewise.
	* src/Emsg.h: Likewise.
	* src/Experiment.cc: Likewise.
	* src/Table.h: Likewise.

Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple
to parse this cooked_index_entry:
...
    [5] ((cooked_index_entry *) 0x7f01f0004040)^M
    name:       v^M
    canonical:  v^M
    qualified:  ns::v^M
    DWARF tag:  DW_TAG_variable^M
    flags:      0x2 [IS_STATIC]^M
    DIE offset: 0xcb^M
    parent:     ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M
...
which allows us to verify that the entry has a parent.

After commit 8f258a6c ("[gdb/symtab] Dump qualified name of
cooked_index_entry") that's no longer necessary.

Simplify this by checking for ns::v instead.

While we're at it, also fix the test-case for target boards readnow,
cc-with-gdb-index and cc-with-debug-names.

Tested on x86_64-linux.

A previous patch made ld fail early on Thumb-only where branch_type is
ST_BRANCH_UNKNOWN.

However, this fails erroneously when the target is undefweak: in that
case the branch should be replaced by a branch to the next instruction
(or nop.w on thumb2).  This patch accepts this case and restores the
previous behaviour in such cases.

This was reported by failures in the GCC testsuite, where we fail to
link executables because __deregister_frame_info is undefweak:

(__deregister_frame_info): Unknown destination type (ARM/Thumb) in ...crtbegin.o
crtbegin.o: in function `__do_global_dtors_aux':
crtstuff.c:(.text+0x52): dangerous relocation: unsupported relocation

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

I noticed a typo in the Python TUI window documentation.

What's past an active .end directive (when that has its default purpose)
is supposed to be entirely ignored. That should be true not just for
regular processing, but also for "pre-processing" (aka scrubbing). A
complication is that such a directive may of course occur inside a
(false) conditional or a macro definition. To deal with that make sure
we can continue as usual if called another time.

Note however that .end inside a macro will still have the full macro
body expanded; dealing with that would require further (perhaps
intrusive) adjustments in sb_scrub_and_add_sb() and/or callers thereof.
However, at least some of the warnings issued by do_scrub_chars() are
unlikely to occur when expanding a macro. (If we needed to go that far,
presumably .exitm would also want recognizing.)

They're needed with TC_M68K only. Group them accordingly, just like is
the case for Arm's symver vars.

In that mode the comment char is ; while @ has no special meaning.
Engaging the special logic in that case results in comments not being
respected on .symver lines.

EVEX.B4 is used only for GPR (or addressing of memory) operands. SIMD
registers encoded via ModR/M.rm (when ModR/M.mod == 3) have their top
bit in EVEX.X3. Supposedly (doc version 004) EVEX.B4 is ignored when
unused, hence also don't flag such encodings as invalid.

Error messages there would better not be followed by further "junk at
end of line" diagnostics. Arrange for this to be the case uniformly.

While there also replace a somewhat unhelpful open-coding of
restore_line_pointer().

A bug in ld meant that we were erroneously generating image relocations
for .secrel32 ops, which we then reflected in our PDB section
contributions because the linker was adding a .reloc section.

This was incidental to what we were testing for, so pass
--disable-reloc-section to ld in order to ensure a consistent output.

Small typo in some example code inside a comment; the arguments were
in the wrong order.

There's no functional change after this commit.

In gdb.base/corefile-buildid.exp, in the function
do_corefile_buildid_tests, if we fail to find the build-id for the
test binary then we call 'untested', but then push on with the test,
which inevitably fails as the rest of the test depends on having found
the build-id.

I think we're missing a 'return' after the call to 'untested' which
I've now added.

Also I noticed that we call build_id_debug_filename_get and then
manually remove '.debug' from the end.  This is no longer necessary,
we can just ask build_id_debug_filename_get to not add the suffix.