Mike Frysinger [Thu, 10 Nov 2022 08:53:25 +0000 (15:53 +0700)]
sim: ppc: rename ppc-instructions to powerpc.igen
To make it clear this is an input to the igen tool, rename it with an
igen extension. This matches the other files in the ppc dir (altivec
& e500 igen files), and the other igen ports (mips, mn10300, v850).
H.J. Lu [Fri, 4 Nov 2022 20:47:59 +0000 (13:47 -0700)]
i386: Check invalid (%dx) usage
(%dx) isn't a valid memory address in any modes. It is used as a special
memory operand for input/output port address in AT&T syntax and should
only be used with input/output instructions. Update i386_att_operand to
set i.input_output_operand to true for (%dx) and issue an error if (%dx)
is used with non-input/output instructions.
PR gas/29751
* config/tc-i386.c (_i386_insn): Add input_output_operand.
(md_assemble): Issue an error if input/output memory operand is
used with non-input/output instructions.
(i386_att_operand): Set i.input_output_operand to true for
(%dx).
* testsuite/gas/i386/inval.l: Updated.
* testsuite/gas/i386/x86-64-inval.l: Likewise.
* testsuite/gas/i386/inval.s: Add tests for invalid (%dx) usage.
* testsuite/gas/i386/x86-64-inval.s: Likewise.
Simon Marchi [Thu, 4 Aug 2022 15:49:12 +0000 (11:49 -0400)]
gdb: make "start" breakpoint inferior-specific
I saw this failure on a CI:
(gdb) add-inferior
[New inferior 2]
Added inferior 2
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior
inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2
kill
The program is not being run.
(gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep...
(gdb) run &
Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2
inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1
kill
The program is not being run.
(gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior...
(gdb) break should_break_here
Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25.
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
start
Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations)
Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23
23 sleep (30);
(gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1
What happens is:
1. We start inferior 2 with "run&", it runs very slowly, takes time to
get to main
2. We switch to inferior 1, and run "start"
3. The temporary breakpoint inserted by "start" applies to all inferiors
4. Inferior 2 hits that breakpoint and GDB reports that hit
To avoid this, breakpoints inserted by "start" should be
inferior-specific. However, we don't have a nice way to make
inferior-specific breakpoints yet. It's possible to make
pspace-specific breakpoints (for example how the internal_breakpoint
constructor does) by creating a symtab_and_line manually. However,
inferiors can share program spaces (usually on particular embedded
targets), so we could have a situation where two inferiors run the same
code in the same program space. In that case, it would just not be
possible to insert a breakpoint in one inferior but not the other.
A simple solution that should work all the time is to add a condition to
the breakpoint inserted by "start", to check the inferior reporting the
hit is the expected one. This is what this patch implements.
Add a test that does:
- start in background inferior 1 that sleeps before reaching its main
function (using a sleep in a global C++ object's constructor)
- start inferior 2 with the "start" command, which also sleeps before
reaching its main function
- validate that we hit the breakpoint in inferior 2
Without the fix, we hit the breakpoint in inferior 1 pretty much all the
time. There could be some unfortunate scheduling causing the test not
to catch the bug, for instance if the scheduler decides not to schedule
inferior 1 for a long time, but it would be really rare. If the bug is
re-introduced, the test will catch it much more often than not, so it
will be noticed.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a
Bruno Larsen [Thu, 10 Nov 2022 16:58:58 +0000 (17:58 +0100)]
gdb: Fix regressions caused by
041de3d73aa121f2ff0c077213598963bfb34b79
Commit
041de3d73aa changed the output format of all error messages when
GDB couldn't determine a compatible overload for a given function, but
it was only supposed to change if the failure happened due to incomplete
types. This commit removes the stray . that was added
Aaron Merey [Mon, 24 Oct 2022 18:05:06 +0000 (14:05 -0400)]
gdb/debuginfod: Improve progress updates
If the download size is known, a progress bar is displayed along with
the percentage of completion and the total download size.
Downloading separate debug info for /lib/libxyz.so
[############ ] 25% (10.01 M)
If the download size is not known, a progress indicator is displayed
with a ticker ("###") that moves across the screen at a rate of 1 tick
every 0.5 seconds.
Downloading separate debug info for /lib/libxyz.so
[ ### ]
If the output stream is not a tty, batch mode is enabled, the screen is
too narrow or width has been set to 'unlimited', then only a static
description of the download is printed. No bar or ticker is displayed.
Downloading separate debug info for /lib/libxyz.so...
In any case, if the size of the download is known at the time the
description is printed then it will be included in the description.
Downloading 10.01 MB separate debug info for /lib/libxyz.so...
Simon Marchi [Mon, 24 Oct 2022 20:18:43 +0000 (16:18 -0400)]
gdb: add special handling for frame level 0 in frame_info_ptr
I noticed this problem while preparing the initial submission for the
ROCm GDB port. One particularity of this patch set is that it does not
support unwinding frames, that requires support of some DWARF extensions
that will come later. It was still possible to run to a breakpoint and
print frame #0, though.
When rebasing on top of the frame_info_ptr work, GDB started tripping on
a prepare_reinflate call, making it not possible anymore to event print
the frame when stopping on a breakpoint. One thing to know about frame
0 is that its id is lazily computed when something requests it through
get_frame_id. See:
https://gitlab.com/gnutools/binutils-gdb/-/blob/
23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L2070-2080
So, up to that prepare_reinflate call, frame 0's id was not computed,
and prepare_reinflate, calling get_frame_id, forces it to be computed.
Computing the frame id generally requires unwinding the previous frame,
which with my ROCm GDB patch fails. An exception is thrown and the
printing of the frame is simply abandonned.
Regardless of this ROCm GDB problem (which is admittedly temporary, it
will be possible to unwind with subsequent patches), we want to avoid
prepare_reinflate to force the computing of the frame id, for the same
reasons we lazily compute it in the first place.
In addition, frame 0's id is subject to change across a frame cache
reset. This is why save_selected_frame and restore_selected_frame have
special handling for frame 0:
https://gitlab.com/gnutools/binutils-gdb/-/blob/
23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L1841-1863
For this last reason, we also need to handle frame 0 specially in
prepare_reinflate / reinflate. Because the frame id of frame 0 can
change across a frame cache reset, we must not rely on the frame id from
that frame to reinflate it. We should instead just re-fetch the current
frame at that point.
This patch adds a frame_info_ptr::m_cached_level field, set in
frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0.
There are cases where a frame_info_ptr object wraps a sentinel frame,
for which frame_relative_level returns -1, so I have chosen the value -2
to represent "invalid frame level", for when the frame_info_ptr object
is empty.
In frame_info_ptr::prepare_reinflate, only cache the frame id if the
frame level is not 0. It's fine to cache the frame id for the sentinel
frame, it will be properly handled by frame_find_by_id later.
In frame_info_ptr::reinflate, if the frame level is 0, call
get_current_frame to get the target's current frame. Otherwise, use
frame_find_by_id just as before.
This patch should not have user-visible changes with upstream GDB. But
it will avoid forcing the computation of frame 0's when calling
prepare_reinflate. And, well, it fixes the upcoming ROCm GDB patch
series.
Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Simon Marchi [Fri, 21 Oct 2022 15:49:44 +0000 (11:49 -0400)]
gdb: add missing prepare_reinflate call in print_frame_info
print_frame_info calls frame_info_ptr::reinflate, but not
frame_info_ptr::prepare_reinflate, add the call to prepare_reinflate.
It works right now, because all callers of print_frame_info that could
possibly lead to the pretty printers being called, and the frame_info
objects being invalidated, do call prepare_reinflate themselves. And
since the cached frame id is copied when passing a frame_info_ptr by
value, print_frame_info does have a cached frame id on entry. So
technically, this change isn't needed. But I don't think it's good for
a function to rely on its callers to have called prepare_reinflate, if
it intends to call reinflate.
Change-Id: Ie332b2d5479aef46f83fdc1120c7c83f4e84d1b0
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Simon Marchi [Mon, 24 Oct 2022 20:16:09 +0000 (16:16 -0400)]
gdb: use frame_id_p instead of comparing to null_frame_id in frame_info_ptr::reinflate
The assertion
gdb_assert (m_cached_id != null_frame_id);
is always true, as comparing equal to null_frame_id is always false
(it's the first case in frame_id::operator==, not sure why it's not this
way, but that's what it is).
Replace the comparison with a call to frame_id_p.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb
Simon Marchi [Mon, 24 Oct 2022 19:57:26 +0000 (15:57 -0400)]
gdb: remove manual frame_info reinflation code in backtrace_command_1
With the following patch applied (gdb: use frame_id_p instead of
comparing to null_frame_id in frame_info_ptr::reinflate), I would get:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full"
Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame...
Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22.
Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
22 }
#0 breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
No locals.
/home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed.
This is because the code in backtrace_command_1 to manually reinflate
`fi` steps overs frame_info_ptr's toes.
When calling
fi.prepare_reinflate ();
`fi` gets properly filled with the cached frame id. But when this
happens:
fi = frame_find_by_id (frame_id);
`fi` gets replaced by a brand new frame_info_ptr that doesn't have a
cached frame id. Then this is called without a cached frame id:
fi.reinflate ();
That doesn't cause any problem currently, since
- the gdb_assert in the reinflate method doesn't actually do anything
(the following patch fixes that)
- `fi.m_ptr` will always be non-nullptr, since we just got it from
frame_find_by_id, so reinflate will not do anything, it won't try to
use m_cached_id
Fix that by removing the code to manually re-fetch the frame. That
should be taken care of by frame_info_ptr::reinflate.
Note that the old code checked if we successfully re-inflated the frame
or not, and if not it did emit a warning. The equivalent in
frame_info_ptr::reinflate asserts that the frame has been successfully
re-inflated. It's not clear if / when this can happen, but if it can
happen, we'll need to find a solution to this problem globally
(everywhere a frame_info_ptr can be re-inflated), not just here. So I
propose to leave it like this, until it does become a problem.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I07b783d94e2853e0a2d058fe7deaf04eddf24835
Simon Marchi [Fri, 21 Oct 2022 20:06:59 +0000 (16:06 -0400)]
gdb: move frame_info_ptr method implementations to frame-info.c
I don't see any particular reason why the implementations of the
frame_info_ptr object are in the header file. It only seems to add some
complexity. Since we can't include frame.h in frame-info.h, we have to
add declarations of functions defined in frame.c, in frame-info.h. By
moving the implementations to a new frame-info.c, we can avoid that.
Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 7 Nov 2022 14:55:23 +0000 (09:55 -0500)]
gdb: add prepare_reinflate/reinflate around print_frame_args in info_frame_command_core
I noticed this crash:
$ ./gdb --data-directory=data-directory -nx -q \
testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \
-x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \
-ex "b g" -ex r
(gdb) info frame
Stack level 0, frame at 0x7fffffffdd80:
rip = 0x555555555160 in g
(/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3
called by frame at 0x7fffffffdda0
source language c.
Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world",
depth=10
Fatal signal: Segmentation fault
This is another case of frame_info being invalidated under a function's
feet. The stack trace when the frame_info get invalidated looks like:
... many frames to pretty print the arg, that eventually invalidate the frame_infos ...
#35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489
#36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300)
at /home/simark/src/binutils-gdb/gdb/stack.c:898
#37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682
print_frame_args knows that print_frame_arg can invalidate frame_info
objects, and therefore calls prepare_reinflate/reinflate. However,
info_frame_command_core has a separate frame_info_ptr instance (it is
passed by value / copy). So info_frame_command_core needs to know that
print_frame_args can invalidate frame_info objects, and therefore needs
to prepare_reinflate/reinflate as well. Add those calls, and enhance
the gdb.python/pretty-print-call-by-hand.exp test to test that command.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I9edaae06d62e97ffdb30938d364437737238a960
Simon Marchi [Fri, 21 Oct 2022 15:57:15 +0000 (11:57 -0400)]
gdb: clear other.m_cached_id in frame_info_ptr's move ctor
We do it in the move assignment operator, so I think it makes sense to
do it here too for consistency. I don't think it's absolutely necessary
to clear the other object's fields (in other words, copy constructor and
move constructor could be the same), as there is no exclusive resource
being transfered. The important thing is to leave the moved-from object
in an unknown, but valid state. But still, I think that clearing the
fields of the moved-from object is not a bad idea, it helps ensure we
don't rely on the moved-from object after.
Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Bruno Larsen [Wed, 5 Oct 2022 12:22:56 +0000 (14:22 +0200)]
gdb/c++: Improve error messages in overload resolution
When resolving overloaded functions, GDB relies on knowing relationships
between types, i.e. if a type inherits from another. However, some
compilers may not add complete information for given types as a way to
reduce unnecessary debug information. In these cases, GDB would just say
that it couldn't resolve the method or function, with no extra
information.
The problem is that sometimes the user may not know that the type
information is incomplete, and may just assume that there is a bug in
GDB. To improve the user experience, we attempt to detect if the
overload match failed because of an incomplete type, and warn the user
of this.
This commit also adds a testcase confirming that the message is only
triggered in the correct scenario. This test was not developed as an
expansion of gdb.cp/overload.cc because it needed the dwarf assembler,
and porting all of overload.cc seemed unnecessary.
Approved-By: Tom Tromey <tom@tromey.com>
Bruno Larsen [Wed, 12 Oct 2022 12:51:10 +0000 (14:51 +0200)]
gdb/testsuite: allowed for function_range to deal with mangled functions
When calling get_func_info inside a test case, it would cause failures
if the function was printed using a C++ style mangled name. The current
patch fixes this by allowing for mangled names along with the current
rules.
Approved-By: Tom Tromey <tom@tromey.com>
Clément Chigot [Wed, 9 Nov 2022 16:21:03 +0000 (17:21 +0100)]
ld/testsuite: skip ld-size when -shared is not supported
ld/ChangeLog:
* testsuite/ld-size/size.exp: Skip when -shared is not
supported.
Alan Modra [Wed, 9 Nov 2022 23:07:36 +0000 (09:37 +1030)]
mach-o reloc size overflow
* mach-o.c (bfd_mach_o_canonicalize_reloc): Set bfd_error on
multiply overflow.
Alan Modra [Thu, 10 Nov 2022 01:18:01 +0000 (11:48 +1030)]
Sanity check reloc count in get_reloc_upper_bound
The idea here is the stop tools from allocating up to 32G per section
for the arelent pointer array, only to find a little later that the
section reloc count was fuzzed. This usually doesn't hurt much (on
systems that allow malloc overcommit) except when compiled with asan.
We already do this for ELF targets, and while fixing the logic
recently I decided other targets ought to do the same.
* elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Sanity check
section reloc count against file size.
* mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
* aoutx.h (get_reloc_upper_bound): Likewise, and don't duplicate
check done in bfd_get_reloc_upper_bound.
* pdp11.c (get_reloc_upper_bound): Likewise.
* coffgen.c (coff_get_reloc_upper_bound): Likewise.
Lancelot SIX [Wed, 9 Nov 2022 23:02:44 +0000 (23:02 +0000)]
gdb/testsuite: Fix rtld-step-nodebugsym.exp
The test case introduced in
bafcc335266 (Fix stepping in rtld without
debug symbol) fails on some systems as reported by PR/29768. This can
be seen if the system does not have debug info for the libc:
(gdb) step^M
Single stepping until exit from function main,^M
which has no line number information.^M
hello world[Inferior 1 (process 48203) exited normally]^M
(gdb) PASS: gdb.base/rtld-step-nodebugsym.exp: step
continue^M
The program is not being run.^M
(gdb) FAIL: gdb.base/rtld-step-nodebugsym.exp: continue until exit (the program is no longer running)
Without glibc debug info, GDB steps until the program finishes, and
then "gdb_continue_to_end" fails.
As this test was designed to check that GDB does not crash in the "step"
command, the continue does not carry real meaning to the test.
Replace it by "print 0" so we still check that after the step command
GDB is still alive, which is what we care about.
Tested on Ubuntu-22.04 x86_64, with and without libc6-dbg.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29768
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Mike Frysinger [Thu, 10 Nov 2022 07:45:47 +0000 (14:45 +0700)]
sim: ppc: drop old makefile fragment
Support for these files was dropped almost 30 years ago, but the ppc
arch was missed. Clean that up now too.
Mike Frysinger [Wed, 9 Nov 2022 19:44:38 +0000 (02:44 +0700)]
sim: ppc: drop support for dgen -L option
Nothing passes this to dgen, and even if it did, nothing would happen
because the generated spreg.[ch] files don't include any references
back to the original data table. So drop it to simplify.
Mike Frysinger [Wed, 9 Nov 2022 19:24:41 +0000 (02:24 +0700)]
sim: ppc: collapse is_readonly & length switch tables heavily
Since we know we'll return 0 by default, we don't have to output case
statements for readonly or length fields whose values are also zero.
This is the most common case by far and thus generates a much smaller
switch table in the end.
Mike Frysinger [Wed, 9 Nov 2022 19:15:34 +0000 (02:15 +0700)]
sim: ppc: collapse is_valid switch table more
Instead of writing:
case 1:
return 1;
case 2:
return 1;
...etc...
Output a single return so we get:
case 1:
case 2:
case ...
return 1;
This saves ~100 lines of code. Hopefully the compiler was already
smart enough to optimize to the same code, but if not, this probably
helps there too :).
Mike Frysinger [Wed, 9 Nov 2022 19:12:42 +0000 (02:12 +0700)]
sim: ppc: pull default switch return out
This saves a single line for the same result. By itself, it's not
interesting, but we can further optimize the generated output and
completely omit the switch table in some cases. Which we'll do in
follow up commits.
Mike Frysinger [Wed, 9 Nov 2022 19:06:48 +0000 (02:06 +0700)]
sim: ppc: constify spreg table
This internal table is only ever read, so constify it.
Mark Harmstone [Thu, 3 Nov 2022 02:46:04 +0000 (02:46 +0000)]
ld: Add module information substream to PDB files
Luis Machado [Wed, 2 Nov 2022 07:17:46 +0000 (07:17 +0000)]
[opcodes/arm] Fix potential null pointer dereferences
PR tdep/29598
As pointed out in the bug ticket, we have a couple potential null pointer
dereferencing situations. Harden those.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29598
Luis Machado [Mon, 31 Oct 2022 13:26:20 +0000 (13:26 +0000)]
[gdb/aarch64] Use safer memory read routines
PR tdep/28796
As reported, we are using some memory read routines that don't handle read
errors gracefully. Convert those to use the safe_* versions if available.
This allows the code to handle those read errors in a more sensible way.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28796
GDB Administrator [Thu, 10 Nov 2022 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Lancelot SIX [Fri, 4 Nov 2022 15:14:38 +0000 (15:14 +0000)]
Fix stepping in rtld without debug symbol
Commit
be6276e0aed "Allow debugging of runtime loader / dynamic linker"
introduced a small regression when stepping into the runtime loader /
dynamic linker from function we do not have debug information for. This
is reported in PR/29747.
This can be shown by the following example (given by Simon Marchi in
buzilla bug report):
$ cat test.c
#include <stdio.h>
int main()
{
printf("Hi\n");
return 0;
}
$ gcc test.c -O0 -o test
$ ./gdb -q -nx --data-directory=data-directory test -ex start -ex s
Reading symbols from test...
(No debugging symbols found in test)
Temporary breakpoint 1 at 0x1151
Starting program: .../binutils-gdb/gdb/test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Temporary breakpoint 1, 0x0000555555555151 in main ()
Single stepping until exit from function main,
which has no line number information.
/home/smarchi/src/binutils-gdb/gdb/infrun.c:6960:64: runtime error: member call on null pointer of type 'struct symbol'
The crash happens here:
#0 __sanitizer::Die () at ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
#1 0x00007ffff5dd7128 in __ubsan::__ubsan_handle_type_mismatch_v1_abort (Data=<optimized out>, Pointer=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:148
#2 0x000055556183e1a7 in process_event_stop_test (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6960
#3 0x0000555561838ea4 in handle_signal_stop (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:6615
#4 0x000055556182f77b in handle_inferior_event (ecs=0x7fffffffccd0) at .../binutils-gdb/gdb/infrun.c:5866
When evaluating:
6956 if (execution_direction != EXEC_REVERSE
6957 && ecs->event_thread->control.step_over_calls == STEP_OVER_UNDEBUGGABLE
6958 && in_solib_dynsym_resolve_code (ecs->event_thread->stop_pc ())
6959 && !in_solib_dynsym_resolve_code (
6961 ecs->event_thread->control.step_start_function->value_block ()
6962 ->entry_pc ()))
we dereference, ecs->event_thread->control.step_start_function which is
nullptr.
This patch changes this condition so it evaluates to true if
ecs->event_thread->control.step_start_function is nullptr since this
matches the behaviour before
be6276e0aed.
Tested on ubuntu-22.04 x86_64.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29747
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Kevin Buettner <kevinb@redhat.com>
Mike Frysinger [Wed, 9 Nov 2022 17:29:27 +0000 (00:29 +0700)]
sim: igen: add missing newline to various error messages
The error() function expects a trailing newline in its message.
Most callers do this already, so adding it to the few that don't.
Mike Frysinger [Wed, 9 Nov 2022 17:19:45 +0000 (00:19 +0700)]
sim: restore lstat & mkdir func checks
When merging ppc configure checks into the top-level, these 2 funcs
were accidentally dropped (probably due to incorrect resolution of
conflicts). Restore them since the ppc code utilizes them both.
Mike Frysinger [Wed, 9 Nov 2022 17:11:17 +0000 (00:11 +0700)]
sim: ppc: drop obsolete USE_WIN32API check
This controls only one thing: how to call mkdir(). The gnulib code
already has a mkdir module that provides this exact logic for us, so
punt the code entirely.
Tankut Baris Aktemur [Wed, 9 Nov 2022 16:46:21 +0000 (17:46 +0100)]
gdbserver: do not report btrace support if target does not announce it
Gdbserver unconditionally reports support for btrace packets. Do not
report the support, if the underlying target does not say it supports
it. Otherwise GDB would query the server with btrace-related packets
unnecessarily.
Tom Tromey [Mon, 7 Nov 2022 18:12:35 +0000 (11:12 -0700)]
Allow 'ptype/o' for assembly
PR exp/28359 points out that 'ptype/o' does not work when the current
language is "asm".
I tracked this down to a hard-coded list of languages in typeprint.c.
This patch replaces this list with a method on 'language_defn'
instead. If all languages are ever updated to have this feature, the
method could be removed; but in the meantime this lets each language
control what happens.
I looked at having each print_type method simply modify the flags
itself, but this doesn't work very well with the feature that disables
method-printing by default (but allows it via a flag).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28359
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Keith Seitz <keiths@redhat.com>
Mike Frysinger [Wed, 9 Nov 2022 15:33:27 +0000 (22:33 +0700)]
sim: ppc: add missing parens with e500 macro
This macro expansion was missing a set of outer-most parenthesis which
some compilers would complain about depending on how the macro is used.
This is just standard good macro hygiene too.
Mike Frysinger [Wed, 9 Nov 2022 15:31:47 +0000 (22:31 +0700)]
sim: ppc: drop useless linking of helper tools
We've never run these helper programs directly. The igen program
includes the relevant source files directly and runs the code that
way. So stop wasting developer CPU time linking programs that are
never run. We leave the rules in place for people who need to test
and debug the specific bits of code every now & then.
Jan Beulich [Wed, 9 Nov 2022 10:09:34 +0000 (11:09 +0100)]
x86/Intel: don't accept malformed EXTRQ / INSERTQ
Operand swapping was mistakenly suppressed when the first two operands
were immediate ones, not taking into account overall operand count. This
way EXTRQ / INSERTQ would have been accepted also with kind-of-AT&T
operand order.
For the testcase being extended, in order to not move around "GAS
LISTING" expectations, suppress pagination.
Alan Modra [Wed, 9 Nov 2022 06:07:42 +0000 (16:37 +1030)]
Re: Fuzzed files in archives
Like commit
ffbe89531c2e this avoids more silliness writing output
that is going to be deleted. bfd_close and bfd_close_all_done differ
in that only the former calls _bfd_write_contents.
* objcopy.c (copy_archive): Don't call bfd_close for elements
that are going to be deleted, call bfd_close_all_done instead.
Do the same for the archive itself.
Christoph Müllner [Mon, 7 Nov 2022 12:46:20 +0000 (13:46 +0100)]
RISC-V: xtheadfmemidx: Use fp register in mnemonics
Although the encoding for scalar and fp registers is identical,
we should follow common pratice and use fp register names
when referencing fp registers.
The xtheadmemidx extension consists of indirect load/store instructions
which all load to or store from fp registers.
Let's use fp register names in this case and adjust the test cases
accordingly.
gas/
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Updated since rd need to
be float register.
* testsuite/gas/riscv/x-thead-fmemidx-fail.s: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.d: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.s: Likewise.
opcodes/
* riscv-opc.c (riscv_opcodes): Updated since rd need to be float register.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
H.J. Lu [Tue, 8 Nov 2022 22:46:25 +0000 (14:46 -0800)]
ld: Always output local symbol for relocatable link
PR ld/29761
* elflink.c (elf_link_output_symstrtab): Don't skip local symbol
in SEC_EXCLUDE section for relocatable link.
GDB Administrator [Wed, 9 Nov 2022 00:00:31 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Fri, 4 Nov 2022 14:07:09 +0000 (10:07 -0400)]
gdb/linux-nat: get core count using /sys/devices/system/cpu/possible
I get this test failure on my CI;
FAIL: gdb.base/info-os.exp: get process list
The particularity of this setup is that builds are done in containers
who are allocated 4 CPUs on a machine that has 40. The code in
nat/linux-osdata.c fails to properly fetch the core number for each
task.
linux_xfer_osdata_processes uses `sysconf (_SC_NPROCESSORS_ONLN)`, which
returns 4, so it allocates an array of 4 integers. However, the core
numbers read from /proc/pid/task/tid/stat, by function
linux_common_core_of_thread, returns a value anywhere between 0 and 39.
The core numbers above 3 are therefore ignored, many processes end up
with no core value, and the regexp in the test doesn't match (it
requires an integer as the core field).
The way this the CPUs are exposed to the container is that the container
sees 40 CPUs "present" and "possible", but only 4 arbitrary CPUs
actually online:
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/present
0-39
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/online
5,11,24,31
root@ci-node-jammy-amd64-04-08:~# cat /sys/devices/system/cpu/possible
0-39
The solution proposed in this patch is to find out the number of
possible CPUs using /sys/devices/system/cpu/possible. In practice, this
will probably always contain `0-N`, where N is the number of CPUs, minus
one. But the documentation [1] doesn't such guarantee, so I'll assume
that it can contain a more complex range list such as `2,4-31,32-63`,
like the other files in that directory can have. The solution is to
iterate over these numbers to find the highest possible CPU id, and
use that that value plus one as the size of the array to allocate.
[1] https://www.kernel.org/doc/Documentation/admin-guide/cputopology.rst
Change-Id: I7abce2e43b000c1327fa94cd7b99d46e49d7ccf3
Simon Marchi [Fri, 4 Nov 2022 13:39:12 +0000 (09:39 -0400)]
gdbsupport, gdb: add read_text_file_to_string, use it in linux_common_core_of_thread
I would like to add more code to nat/linux-osdata.c that reads an entire
file from /proc or /sys and processes it as a string afterwards. I
would like to avoid duplicating the somewhat error-prone code that reads
an entire file to a buffer. I think we should have a utility function
that does that.
Add read_file_to_string to gdbsupport/filestuff.{c,h}, and make
linux_common_core_of_thread use it. I want to make the new function
return an std::string, and because strtok doesn't play well with
std::string (it requires a `char *`, std::string::c_str returns a `const
char *`), change linux_common_core_of_thread to use std::string methods
instead.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I1793fda72a82969c28b944a84acb953f74c9230a
Peter Bergner [Tue, 8 Nov 2022 18:15:06 +0000 (12:15 -0600)]
PowerPC: Add XSP operand define
opcodes/
* ppc-opc.c (XSP): New define.
(powerpc_opcodes) <stxvp, stxvpx, pstxvp>: Use it.
Tom de Vries [Tue, 8 Nov 2022 17:47:24 +0000 (18:47 +0100)]
[gdb/cli] Make quit really quit after remote connection closed
Consider a hello world a.out, started using gdbserver:
...
$ gdbserver --once 127.0.0.1:2345 ./a.out
Process ./a.out created; pid = 15743
Listening on port 2345
...
that we can connect to using gdb:
...
$ gdb -ex "target remote 127.0.0.1:2345"
Remote debugging using 127.0.0.1:2345
Reading /home/vries/a.out from remote target...
...
0x00007ffff7dd4550 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb)
...
After that, we can for instance quit with confirmation:
...
(gdb) quit
A debugging session is active.
Inferior 1 [process 16691] will be killed.
Quit anyway? (y or n) y
$
...
Or, kill with confirmation and quit:
...
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 16829) killed]
(gdb) quit
$
...
Or, monitor exit, kill with confirmation, and quit:
...
(gdb) monitor exit
(gdb) kill
Kill the program being debugged? (y or n) y
Remote connection closed
(gdb) quit
$
...
But when doing monitor exit followed by quit with confirmation, we get the gdb
prompt back, requiring us to do quit once more:
...
(gdb) monitor exit
(gdb) quit
A debugging session is active.
Inferior 1 [process 16944] will be killed.
Quit anyway? (y or n) y
Remote connection closed
(gdb) quit
$
...
So, the first quit didn't quit. This happens as follows:
- quit_command calls query_if_trace_running
- a TARGET_CLOSE_ERROR is thrown
- it's caught in remote_target::get_trace_status, but then
rethrown because it's TARGET_CLOSE_ERROR
- catch_command_errors catches the error, at which point the quit command
has been aborted.
The TARGET_CLOSE_ERROR is defined as:
...
/* Target throwing an error has been closed. Current command should be
aborted as the inferior state is no longer valid. */
TARGET_CLOSE_ERROR,
...
so in a way this is expected behaviour. But aborting quit because the inferior
state (which we've already confirmed we're not interested in) is no longer
valid, and having to type quit again seems pointless.
Furthermore, the purpose of not catching errors thrown by
query_if_trace_running as per commit
2f9d54cfcef ("make -gdb-exit call
disconnect_tracing too, and don't lose history if the target errors on
"quit""), was to make sure that error (_("Not confirmed.") had effect.
Fix this in quit_command by catching only the TARGET_CLOSE_ERROR exception
during query_if_trace_running and reporting it:
...
(gdb) monitor exit
(gdb) quit
A debugging session is active.
Inferior 1 [process 19219] will be killed.
Quit anyway? (y or n) y
Remote connection closed
$
...
Tested on x86_64-linux.
PR server/15746
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15746
Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 8 Nov 2022 17:40:25 +0000 (18:40 +0100)]
[gdb/testsuite] Remove test-case from test name
Remove test-cases from test-names, such that we don't have the redundant:
...
PASS: gdb.base/corefile.exp: backtrace in corefile.exp
...
but simply:
...
PASS: gdb.base/corefile.exp: backtrace
...
Fixed all instances found using:
...
$ grep ":.*:.*\.exp" gdb.sum
...
Tested on x86_64-linux.
Tom de Vries [Tue, 8 Nov 2022 15:28:11 +0000 (16:28 +0100)]
[gdb/testsuite] Fix find_core_file for core named core
With test-case gdb.base/bigcore.exp I run into:
...
(gdb) PASS: gdb.base/bigcore.exp: get inferior pid
signal SIGABRT^M
Continuing with signal SIGABRT.^M
^M
Program terminated with signal SIGABRT, Aborted.^M
The program no longer exists.^M
(gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
UNTESTED: gdb.base/bigcore.exp: can't generate a core file
...
due to find_core_file returning "".
There is a core file name core:
...
$ ls ./outputs/gdb.base/bigcore
bigcore bigcore.corefile core gdb.cmd.1 gdb.in.1 gdbserver.cmd.1
...
but it's not found.
The problem is this statement:
...
lappend files [list ${::testfile}.core core]
...
which adds a single list item "${::testfile}.core core".
Fix this in the most readable way:
...
lappend files ${::testfile}.core
lappend files core
...
Tested on x86_64-linux.
Mike Frysinger [Fri, 4 Nov 2022 00:38:20 +0000 (07:38 +0700)]
sim: mips: call Unpredictable instead of setting bogus values [PR sim/29276]
The intention of this code seems to be to indicate that this insn
should not be used and produces undefined behavior, so instead of
setting registers to bogus values, call Unpredictable. This fixes
build warnings due to 32-bit/64-bit type conversions, and outputs
a log message for users at runtime instead of silent corruption.
Bug: https://sourceware.org/PR29276
Mike Frysinger [Tue, 8 Nov 2022 07:09:06 +0000 (14:09 +0700)]
sim: drop unused CORE_ADDR_TYPE
This hasn't been used by gdb in decades, and doesn't make sense with
a standalone sim program/library where the ABI is fixed. So punt it
to simplify the code.
Haochen Jiang [Tue, 8 Nov 2022 01:20:18 +0000 (09:20 +0800)]
x86: Correct wrong comments in vex_w_table
Hi all,
This wrong comment was introduced by previous AVX-VNNI-INT8 commit.
Committed as obvious fix.
BRs,
Haochen
opcodes/ChangeLog:
* i386-dis.c (VEX_W_0F3851): Corrected from
VEX_W_0F3851_P_0.
Kong Lingling [Tue, 8 Nov 2022 01:51:07 +0000 (09:51 +0800)]
Support Intel RAO-INT
gas/ChangeLog:
* NEWS: Support Intel RAO-INT.
* config/tc-i386.c: Add raoint.
* doc/c-i386.texi: Document .raoint.
* testsuite/gas/i386/i386.exp: Run RAO_INT tests.
* testsuite/gas/i386/raoint-intel.d: New test.
* testsuite/gas/i386/raoint.d: Ditto.
* testsuite/gas/i386/raoint.s: Ditto.
* testsuite/gas/i386/x86-64-raoint-intel.d: Ditto.
* testsuite/gas/i386/x86-64-raoint.d: Ditto.
* testsuite/gas/i386/x86-64-raoint.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (PREFIX_0F38FC): New.
(prefix_table): Add PREFIX_0F38FC.
* i386-gen.c: (cpu_flag_init): Add CPU_RAO_INT_FLAGS and
CPU_ANY_RAO_INT_FLAGS.
* i386-init.h: Regenerated.
* i386-opc.h: (CpuRAO_INT): New.
(i386_cpu_flags): Add cpuraoint.
* i386-opc.tbl: Add RAO_INT instructions.
* i386-tbl.h: Regenerated.
GDB Administrator [Tue, 8 Nov 2022 00:00:30 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Mon, 7 Nov 2022 17:43:25 +0000 (10:43 -0700)]
Silence libtool during link
The switch to linking with libtool now shows a very long link line
even when V=0. This patch arranges to silence libtool in this
situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Fri, 4 Nov 2022 19:12:55 +0000 (15:12 -0400)]
gdb: make lookup_selected_frame static
Change-Id: Ide2749a34333110c7f0112b25852c78cace0d2b4
Mike Frysinger [Mon, 7 Nov 2022 16:44:36 +0000 (23:44 +0700)]
sim: riscv: add missing AC_MSG_RESULT call
Previous commit in here forgot to include this.
Mike Frysinger [Mon, 7 Nov 2022 16:07:43 +0000 (23:07 +0700)]
sim: v850: drop subdir configure logic
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
Mike Frysinger [Mon, 7 Nov 2022 16:05:46 +0000 (23:05 +0700)]
sim: mn10300: drop subdir configure logic
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
Mike Frysinger [Mon, 7 Nov 2022 16:04:25 +0000 (23:04 +0700)]
sim: or1k: drop subdir configure logic
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
Mike Frysinger [Mon, 7 Nov 2022 15:59:30 +0000 (22:59 +0700)]
sim: bpf: drop subdir configure logic
We've been using this only to set the default word size to 64. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
Mike Frysinger [Mon, 7 Nov 2022 15:56:58 +0000 (22:56 +0700)]
sim: riscv: drop subdir configure logic
We've been using this only to set the default word size to 32-vs-64
based on the $target. We can easily merge this with the top-level
configure script to clean things up a bit.
Jose E. Marchesi [Sat, 5 Nov 2022 10:52:09 +0000 (11:52 +0100)]
gdb: link executables with libtool
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script.
NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
libctf.so are used by gdb if binutils is installed with
--enable-shared.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. No regressions found.
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Mon, 7 Nov 2022 14:38:12 +0000 (09:38 -0500)]
gdb/testsuite: use a more unique name in gdb.mi/mi-breakpoint-multiple-locations.exp
I see failures in this test, due to the function name "add" being too
generic, and unexpected breakpoint locations being found in my
libstdc++, such as (wrapped for readability):
{
number="2.4",enabled="y",addr="0x00007ffff7d67e68",
func="(anonymous namespace)::fast_float::bigint::add",
file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
line="1815", thread-groups=["i1"]
}
Change the test to use a more unique name.
Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d
Pedro Alves [Fri, 14 Oct 2022 19:17:36 +0000 (20:17 +0100)]
Don't explicitly set clone child ptrace options
linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options. However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:
"Flags are inherited by new tracees created and "auto-attached" via
active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
options."
This removes the unnecessary call.
[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
Mike Frysinger [Mon, 7 Nov 2022 14:49:53 +0000 (21:49 +0700)]
sim: .gdbinit: generate for all arch subdirs
This was being skipped for ports that had a recursive configure,
but we want it for them too.
Mike Frysinger [Mon, 7 Nov 2022 14:30:10 +0000 (21:30 +0700)]
sim: build: add a proper var for enabled arches
The install code was using $SUBDIRS to track all enabled arches. This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level. Create a new var
explicitly to track the list of enabled arches instead.
Christophe Lyon [Fri, 4 Nov 2022 10:06:47 +0000 (11:06 +0100)]
configure: require libzstd >= 1.4.0
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
Clément Chigot [Fri, 4 Nov 2022 15:52:05 +0000 (16:52 +0100)]
ld/testsuite: skip tests related to -shared when disabled
Call the helper function "check_shared_lib_support" to ensure -shared
is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
This allows to catch custom targets explicitly disabling it.
ld/ChangeLog:
* testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
Tsukasa OI [Sat, 10 Sep 2022 08:32:17 +0000 (08:32 +0000)]
RISC-V: Remove RV32EF conflict
Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
versions beginning with the version
20190608-Base-Ratified removed this
restriction. Because the 'E' extension is still a draft, the author chose
to *just* remove the conflict (not checking the ISA version).
Note that, because RV32E is only used with a soft-float calling convention,
there's no valid official ABI for RV32EF. It means, even if we can assemble
a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
in an unmanaged state (outside ABI management).
The purpose of this commit is to suppress unnecessary errors while parsing
an ISA string and/or disassembling, not to allow hard-float with RVE.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
because only older specifications disallowed it.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
prohibited.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
GDB Administrator [Mon, 7 Nov 2022 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in
Mike Frysinger [Sun, 6 Nov 2022 14:09:25 +0000 (21:09 +0700)]
sim: build: respect AM_MAKEFLAGS when entering subdirs
This doesn't matter right now, but it will as we add more flags to
the recursive make step to pass state down.
Mike Frysinger [Sun, 6 Nov 2022 14:08:04 +0000 (21:08 +0700)]
sim: build: stop passing down SIM_PRIMARY_TARGET
This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.
GDB Administrator [Sun, 6 Nov 2022 00:00:20 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Wed, 21 Sep 2022 16:46:51 +0000 (10:46 -0600)]
Deprecate MI version 1
MI version 1 is long since obsolete. Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.
This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.
Mike Frysinger [Sat, 5 Nov 2022 14:21:31 +0000 (21:21 +0700)]
sim: fix readline linkage
Now that we link programs in the top dir instead of the arch subdir,
update the readline library path to be relative to the top dir.
Mike Frysinger [Sat, 5 Nov 2022 13:27:16 +0000 (20:27 +0700)]
sim: use libtool to install programs
Now that we use libtool to link, we have to use it to install instead
of keeping the manual logic so we don't install wrapper shell scripts.
Mike Frysinger [Sat, 5 Nov 2022 09:15:30 +0000 (16:15 +0700)]
sim: bfin: move linux-fixed-code.h to top-level
Mike Frysinger [Thu, 3 Nov 2022 11:19:13 +0000 (18:19 +0700)]
sim: run: move linking into top-level
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
Mike Frysinger [Sat, 5 Nov 2022 07:44:15 +0000 (14:44 +0700)]
sim: build: add uninstall support
This never worked before, but adding it to the common top-level dir
is pretty easy to do now that we're unified.
Mike Frysinger [Sat, 5 Nov 2022 07:35:00 +0000 (14:35 +0700)]
sim: build: move install steps to the top-level
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
Mike Frysinger [Sat, 5 Nov 2022 03:38:37 +0000 (10:38 +0700)]
sim: cris: move rvdummy linking to top-level
This is only used by `make check`, so we can move it out of the
default build too.
Mike Frysinger [Sat, 5 Nov 2022 03:33:37 +0000 (10:33 +0700)]
sim: build: add SIM_HW_CFLAGS to top-level build too
This matches what we do with targets already.
Mike Frysinger [Sat, 5 Nov 2022 03:31:15 +0000 (10:31 +0700)]
sim: drop unused SIM_HARDWARE variable
This hasn't been used since the refactor way back in commit
f872d0d643968c1101bb8c07b252edd54f626da2 ("Only enable H/W
on some mips targets."), so punt it.
Mike Frysinger [Sat, 5 Nov 2022 03:23:28 +0000 (10:23 +0700)]
sim: adjust sim_hw options style
We use uppercase for other variables, and are already turning it to
uppercase in the arch-subdir.mk, so convert it in the configure step.
Mike Frysinger [Sat, 5 Nov 2022 03:02:58 +0000 (10:02 +0700)]
sim: ppc: drop unused /dev/zero logic
Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.
Mike Frysinger [Sat, 5 Nov 2022 02:52:29 +0000 (09:52 +0700)]
sim: ppc: delete unused host bitsize settings
Nothing checks this define anywhere, so drop all the logic. We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.
Mike Frysinger [Sat, 5 Nov 2022 02:29:17 +0000 (09:29 +0700)]
sim: ppc: inline the sim-packages option
This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.
GDB Administrator [Sat, 5 Nov 2022 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in
H.J. Lu [Tue, 1 Nov 2022 00:02:17 +0000 (17:02 -0700)]
binutils: Run PR binutils/26160 test
Update expected PR binutils/26160 test output for readelf out change
and run PR binutils/26160 test.
PR binutils/26160
* testsuite/binutils-all/pr26160.r: Updated.
* testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.
Lancelot SIX [Fri, 4 Nov 2022 15:36:21 +0000 (15:36 +0000)]
[testsuite] gdb.base/dlmopen: Fix test name and use gdb_attach
One test name in gdb.base/dlmopen.exp changes from run to run
since it includes a process id:
PASS: gdb.base/dlmopen.exp: attach
3442682
This is not convenient do diff gdb.sum files to compare test runs.
Fix by using gdb_attach helper function to handle attaching to the
process as it produce a constant test name.
While at it also check gdb_attach's return value to only run the
rest of the test if the attach was successful.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Carl Love [Fri, 4 Nov 2022 16:14:01 +0000 (12:14 -0400)]
PowerPC update comments for the MMA instruction name changes.
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit
bb98553cad4e017f1851153fa5de91f2cee98fb2
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
This patch updates the comments in the various gdb files to reflect the
name changes. There are no functional changes made by this patch.
The older instruction names are still used in the test
gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.
Patch has been tested on Power 10 with no regressions.
Carl Love [Fri, 4 Nov 2022 16:13:52 +0000 (12:13 -0400)]
PowerPC fix for the gdb.arch/powerpc-power10.exp test.
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit
bb98553cad4e017f1851153fa5de91f2cee98fb2
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
The above commit results in about 224 failures on Power 10 since the
disassembled names do not match the expected names in the test. This
patch updates the expected names in the test to match the values produced
by the disassembler.
This patch updates file gdb.arch/powerpc-power10.exp with the new expected
values to the instructions. The comment giving the name of the instruction
for each binary value in the file gdb.arch/powerpc-power10.c is updated
with the new name. There are no functional changes in file
gdb.arch/powerpc-power10.c.
Carl Love [Fri, 4 Nov 2022 16:06:37 +0000 (12:06 -0400)]
Powerpc fix for gdb.base/unwind-on-each-insn.exp
The test disassembles function foo and searches for the line
"End of assembler dump" to determing the last address in the function. The
assumption is the last instruction will be given right before the line
"End of assembler dump". This assumption fails on PowerPC.
The PowerPC disassembly of the function foo looks like:
Dump of assembler code for function foo:
# => 0x00000000100006dc <+0>: std r31,-8(r1)
# 0x00000000100006e0 <+4>: stdu r1,-48(r1)
# 0x00000000100006e4 <+8>: mr r31,r1
# 0x00000000100006e8 <+12>: nop
# 0x00000000100006ec <+16>: addi r1,r31,48
# 0x00000000100006f0 <+20>: ld r31,-8(r1)
# 0x00000000100006f4 <+24>: blr
# 0x00000000100006f8 <+28>: .long 0x0
# 0x00000000100006fc <+32>: .long 0x0
# 0x0000000010000700 <+36>: .long 0x1000180
# End of assembler dump.
The blr instruction is the last instruction in function foo. The lines
with .long following the blr instruction need to be ignored.
This patch adds a new condition to the gdb_test_multiple "disassemble foo"
test to ignore the lines with the .long.
The patch has been tested on PowerPC and Intel X86-64.
Jan Beulich [Fri, 4 Nov 2022 13:13:01 +0000 (14:13 +0100)]
x86: adjust recently introduced testcases
The issue addressed by
2c02c72c62d2 ("re: Support Intel AMX-FP16") has
been introduced once again in a number of new tests.
Nick Clifton [Fri, 4 Nov 2022 12:01:03 +0000 (12:01 +0000)]
Update release documentation with regard to uploading gprofng docs
Bruno Larsen [Thu, 3 Nov 2022 09:01:42 +0000 (10:01 +0100)]
gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp
Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
PR record/29745, where we can't skip one funcion forward if we're using
native-gdbserver. This commit just adds kfails to the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 4 Nov 2022 10:46:59 +0000 (10:46 +0000)]
opcodes/arm: silence compiler warning about uninitialized variable use
After this commit:
commit
6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
Date: Thu Jul 7 13:43:45 2022 +0100
opcodes/arm: add disassembler styling for arm
Some people were seeing their builds failing with complaints about a
possible uninitialized variable usage. I previously fixed an instance
of this issue in this commit:
commit
2df82cd4b459fbc32120e0ad1ce19e26349506fe
Date: Tue Nov 1 10:36:59 2022 +0000
opcodes/arm: silence compiler warning about uninitialized variable use
which did fix the build problems that the sourceware buildbot was
hitting, however, an additional instance of the same problem was
brought to my attention, and that is fixed in this commit.
Where commit
2df82cd4b4 fixed the uninitialized variable problem in
print_mve_unpredictable, this commit fixes the same problem in
print_mve_undefined.
As with the previous commit, I don't believe we could really ever get
an uninitialized variable usage, based on the current usage of the
function, so I have just initialized the reason variable to "??".
Mike Frysinger [Fri, 4 Nov 2022 07:23:50 +0000 (14:23 +0700)]
sim: rx: drop unused $arch setting
This is only needed for CGEN ports which RX isn't, so drop it.
Mike Frysinger [Thu, 3 Nov 2022 13:26:01 +0000 (20:26 +0700)]
sim: build: remove various obsolete generation dep variables
These manual settings were necessary when we weren't doing automatic
header dependency tracking. That was changed a while ago, and we use
automake now to do it all for us. As a result, many of these vars
aren't even referenced anymore.
Further, some of the source file generation (e.g. .c files, or igen,
or cgen outputs) were moved to the common automake build, and it takes
care of dependency tracking for us with the object files.
Mike Frysinger [Thu, 3 Nov 2022 10:38:46 +0000 (17:38 +0700)]
sim: don't hardcode -ldl for SDL support
Since we use AC_SEARCH_LIBS to find dlopen, we don't need to hardcode
-ldl when using SDL ourselves.
konglin1 [Fri, 4 Nov 2022 02:40:07 +0000 (10:40 +0800)]
Support Intel AVX-NE-CONVERT
gas/ChangeLog:
* NEWS: Support Intel AVX-NE-CONVERT.
* config/tc-i386.c: Add avx_ne_convert.
* doc/c-i386.texi: Document .avx_ne_convert.
* testsuite/gas/i386/i386.exp: Run AVX NE CONVERT tests.
* testsuite/gas/i386/avx-ne-convert-intel.d: New test.
* testsuite/gas/i386/avx-ne-convert.d: Ditto.
* testsuite/gas/i386/avx-ne-convert.s: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (Mw): New.
(PREFIX_VEX_0F3872): Ditto.
(PREFIX_VEX_0F38B0_W_0): Ditto.
(PREFIX_VEX_0F38B1_W_0): Ditto.
(VEX_W_0F3872_P_1): Ditto.
(VEX_W_0F38B0): Ditto.
(VEX_W_0F38B1): Ditto.
(prefix_table): Add PREFIX_VEX_0F3872, PREFIX_VEX_0F38B0_W_0,
PREFIX_VEX_0F38B1_W_0.
(vex_w_table): Add VEX_W_0F3872_P_1, VEX_W_0F38B0, VEX_W_0F38B1.
* i386-gen.c (cpu_flag_init): Add CPU_AVX_NE_CONVERT_FLGAS and
CPU_ANY_AVX_NE_CONVERT_FLAGS.
(cpu_flags): Add CpuAVX_NE_CONVERT.
* i386-init.h: Regenerated.
* i386-opc.h (CpuAVX_NE CONVERT): New.
(i386_cpu_flags): Add cpuavx_ne_convert.
* i386-opc.tbl: Add Intel AVX-NE-CONVERT instructions.
* i386-tbl.h: Regenerated.