Pedro Alves [Tue, 23 Nov 2021 20:35:12 +0000 (20:35 +0000)]
Support clone events in the remote protocol
The previous patch taught GDB about a new
TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target
report clone events.
A following patch will teach Linux GDBserver to do the same thing.
But before we get there, we need to teach the remote protocol about
TARGET_WAITKIND_THREAD_CLONED. That's what this patch does. Clone is
very similar to vfork and fork, and the new stop reply is likewise
handled similarly. The stub reports "T05clone:...".
GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and
forward it to GDB in this patch, but no backend actually emits it yet.
That will be done in a following patch.
Documentation for this new remote protocol feature is included in a
documentation patch later in the series.
Pedro Alves [Fri, 12 Nov 2021 20:50:29 +0000 (20:50 +0000)]
Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED
(A good chunk of the problem statement in the commit log below is
Andrew's, adjusted for a different solution, and for covering
displaced stepping too.)
This commit addresses bugs gdb/19675 and gdb/27830, which are about
stepping over a breakpoint set at a clone syscall instruction, one is
about displaced stepping, and the other about in-line stepping.
Currently, when a new thread is created through a clone syscall, GDB
sets the new thread running. With 'continue' this makes sense
(assuming no schedlock):
- all-stop mode, user issues 'continue', all threads are set running,
a newly created thread should also be set running.
- non-stop mode, user issues 'continue', other pre-existing threads
are not affected, but as the new thread is (sort-of) a child of the
thread the user asked to run, it makes sense that the new threads
should be created in the running state.
Similarly, if we are stopped at the clone syscall, and there's no
software breakpoint at this address, then the current behaviour is
fine:
- all-stop mode, user issues 'stepi', stepping will be done in place
(as there's no breakpoint to step over). While stepping the thread
of interest all the other threads will be allowed to continue. A
newly created thread will be set running, and then stopped once the
thread of interest has completed its step.
- non-stop mode, user issues 'stepi', stepping will be done in place
(as there's no breakpoint to step over). Other threads might be
running or stopped, but as with the continue case above, the new
thread will be created running. The only possible issue here is
that the new thread will be left running after the initial thread
has completed its stepi. The user would need to manually select
the thread and interrupt it, this might not be what the user
expects. However, this is not something this commit tries to
change.
The problem then is what happens when we try to step over a clone
syscall if there is a breakpoint at the syscall address.
- For both all-stop and non-stop modes, with in-line stepping:
+ user issues 'stepi',
+ [non-stop mode only] GDB stops all threads. In all-stop mode all
threads are already stopped.
+ GDB removes s/w breakpoint at syscall address,
+ GDB single steps just the thread of interest, all other threads
are left stopped,
+ New thread is created running,
+ Initial thread completes its step,
+ [non-stop mode only] GDB resumes all threads that it previously
stopped.
There are two problems in the in-line stepping scenario above:
1. The new thread might pass through the same code that the initial
thread is in (i.e. the clone syscall code), in which case it will
fail to hit the breakpoint in clone as this was removed so the
first thread can single step,
2. The new thread might trigger some other stop event before the
initial thread reports its step completion. If this happens we
end up triggering an assertion as GDB assumes that only the
thread being stepped should stop. The assert looks like this:
infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.
- For both all-stop and non-stop modes, with displaced stepping:
+ user issues 'stepi',
+ GDB starts the displaced step, moves thread's PC to the
out-of-line scratch pad, maybe adjusts registers,
+ GDB single steps the thread of interest, [non-stop mode only] all
other threads are left as they were, either running or stopped.
In all-stop, all other threads are left stopped.
+ New thread is created running,
+ Initial thread completes its step, GDB re-adjusts its PC,
restores/releases scratchpad,
+ [non-stop mode only] GDB resumes the thread, now past its
breakpoint.
+ [all-stop mode only] GDB resumes all threads.
There is one problem with the displaced stepping scenario above:
3. When the parent thread completed its step, GDB adjusted its PC,
but did not adjust the child's PC, thus that new child thread
will continue execution in the scratch pad, invoking undefined
behavior. If you're lucky, you see a crash. If unlucky, the
inferior gets silently corrupted.
What is needed is for GDB to have more control over whether the new
thread is created running or not. Issue #1 above requires that the
new thread not be allowed to run until the breakpoint has been
reinserted. The only way to guarantee this is if the new thread is
held in a stopped state until the single step has completed. Issue #3
above requires that GDB is informed of when a thread clones itself,
and of what is the child's ptid, so that GDB can fixup both the parent
and the child.
When looking for solutions to this problem I considered how GDB
handles fork/vfork as these have some of the same issues. The main
difference between fork/vfork and clone is that the clone events are
not reported back to core GDB. Instead, the clone event is handled
automatically in the target code and the child thread is immediately
set running.
Note we have support for requesting thread creation events out of the
target (TARGET_WAITKIND_THREAD_CREATED). However, those are reported
for the new/child thread. That would be sufficient to address in-line
stepping (issue #1), but not for displaced-stepping (issue #3). To
handle displaced-stepping, we need an event that is reported to the
_parent_ of the clone, as the information about the displaced step is
associated with the clone parent. TARGET_WAITKIND_THREAD_CREATED
includes no indication of which thread is the parent that spawned the
new child. In fact, for some targets, like e.g., Windows, it would be
impossible to know which thread that was, as thread creation there
doesn't work by "cloning".
The solution implemented here is to model clone on fork/vfork, and
introduce a new TARGET_WAITKIND_THREAD_CLONED event. This event is
similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except
that we end up with a new thread in the same process, instead of a new
thread of a new process. Like FORKED and VFORKED, THREAD_CLONED
waitstatuses have a child_ptid property, and the child is held stopped
until GDB explicitly resumes it. This addresses the in-line stepping
case (issues #1 and #2).
The infrun code that handles displaced stepping fixup for the child
after a fork/vfork event is thus reused for THREAD_CLONE, with some
minimal conditions added, addressing the displaced stepping case
(issue #3).
The native Linux backend is adjusted to unconditionally report
TARGET_WAITKIND_THREAD_CLONED events to the core.
Following the follow_fork model in core GDB, we introduce a
target_follow_clone target method, which is responsible for making the
new clone child visible to the rest of GDB.
Subsequent patches will add clone events support to the remote
protocol and gdbserver.
A testcase will be added by a later patch.
displaced_step_in_progress_thread becomes unused with this patch, but
a new use will reappear later in the series. To avoid deleting it and
readding it back, this patch marks it with attribute unused, and the
latter patch removes the attribute again. We need to do this because
the function is static, and with no callers, the compiler would warn,
(error with -Werror), breaking the build.
Pedro Alves [Wed, 13 Jul 2022 16:16:38 +0000 (17:16 +0100)]
gdb/linux: Delete all other LWPs immediately on ptrace exec event
I noticed that after a following patch ("Step over clone syscall w/
breakpoint, TARGET_WAITKIND_THREAD_CLONED"), the
gdb.threads/step-over-exec.exp was passing cleanly, but still, we'd
end up with four new unexpected GDB core dumps:
=== gdb Summary ===
# of unexpected core files 4
# of expected passes 48
That said patch is making the pre-existing
gdb.threads/step-over-exec.exp testcase (almost silently) expose a
latent problem in gdb/linux-nat.c, resulting in a GDB crash when:
#1 - a non-leader thread execs
#2 - the post-exec program stops somewhere
#3 - you kill the inferior
Instead of #3 directly, the testcase just returns, which ends up in
gdb_exit, tearing down GDB, which kills the inferior, and is thus
equivalent to #3 above.
Vis:
$ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true
...
(top-gdb) r
...
(gdb) b main
...
(gdb) r
...
Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69
69 argv0 = argv[0];
(gdb) c
Continuing.
[New Thread 0x7ffff7d89700 (LWP 2506975)]
Other going in exec.
Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28
28 foo ();
(gdb) k
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
393 return m_suspend.waitstatus_pending_p;
(top-gdb) bt
#0 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
#1 0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345
#2 0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564
#3 0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284
#4 0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278
#5 0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247
#6 0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864
#7 0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590
#8 0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911
...
The root of the problem is that when a non-leader LWP execs, it just
changes its tid to the tgid, replacing the pre-exec leader thread,
becoming the new leader. There's no thread exit event for the execing
thread. It's as if the old pre-exec LWP vanishes without trace. The
ptrace man page says:
"PTRACE_O_TRACEEXEC (since Linux 2.5.46)
Stop the tracee at the next execve(2). A waitpid(2) by the
tracer will return a status value such that
status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))
If the execing thread is not a thread group leader, the thread
ID is reset to thread group leader's ID before this stop.
Since Linux 3.0, the former thread ID can be retrieved with
PTRACE_GETEVENTMSG."
When the core of GDB processes an exec events, it deletes all the
threads of the inferior. But, that is too late -- deleting the thread
does not delete the corresponding LWP, so we end leaving the pre-exec
non-leader LWP stale in the LWP list. That's what leads to the crash
above -- linux_nat_target::kill iterates over all LWPs, and after the
patch in question, that code will look for the corresponding
thread_info for each LWP. For the pre-exec non-leader LWP still
listed, won't find one.
This patch fixes it, by deleting the pre-exec non-leader LWP (and
thread) from the LWP/thread lists as soon as we get an exec event out
of ptrace.
GDBserver does not need an equivalent fix, because it is already doing
this, as side effect of mourning the pre-exec process, in
gdbserver/linux-low.cc:
else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events)
{
...
/* Delete the execing process and all its threads. */
mourn (proc);
switch_to_thread (nullptr);
Pedro Alves [Fri, 12 Nov 2021 20:50:29 +0000 (20:50 +0000)]
linux-nat: introduce pending_status_str
I noticed that some debug log output printing an lwp's pending status
wasn't considering lp->waitstatus. This fixes it, by introducing a
new pending_status_str function.
Also fix the comment in gdb/linux-nat.h describing
lwp_info::waitstatus and details the description of lwp_info::status
while at it.
Pedro Alves [Tue, 22 Jun 2021 14:42:51 +0000 (15:42 +0100)]
displaced step: pass down target_waitstatus instead of gdb_signal
This commit tweaks displaced_step_finish & friends to pass down a
target_waitstatus instead of a gdb_signal. This is needed because a
patch later in the series will want to make
displaced_step_buffers::finish handle TARGET_WAITKIND_THREAD_EXITED.
It also helps with the TARGET_WAITKIND_THREAD_CLONED patch later in
the series.
Tom de Vries [Thu, 9 Mar 2023 14:49:17 +0000 (15:49 +0100)]
[gdb/testsuite] Fix gdb.threads/pending-fork-event-detach.exp for remote target
Fix test-case gdb.threads/pending-fork-event-detach.exp for target board
remote-gdbserver-on-localhost using gdb_remote_download for $touch_file_bin.
Then, fix the test-case for target board remote-stdio-gdbserver with
REMOTE_TMPDIR=~/tmp.remote-stdio-gdbserver by creating $touch_file_path
on target using remote_download, and using the resulting path.
Alan Modra [Thu, 9 Mar 2023 06:05:12 +0000 (16:35 +1030)]
gas: allow frag address wrapping in absolute section
This:
.struct -1
x:
.fill 1
y:
results in an internal error in frag_new due to abs_section_offset
wrapping from -1 to 0. Frags in the absolute section don't do much so
I think we can allow the address wrap.
* frags.c (frag_new): Allow address wrap in absolute section.
Tom de Vries [Thu, 9 Mar 2023 11:56:27 +0000 (12:56 +0100)]
[gdb/testsuite] Fix gdb.threads/multiple-successive-infcall.exp on native-gdbserver
With test-case gdb.threads/multiple-successive-infcall.exp and target board
native-gdbserver I run into:
...
(gdb) continue^M
Continuing.^M
[New Thread 758.759]^M
^M
Thread 1 "multiple-succes" hit Breakpoint 2, main () at \
multiple-successive-infcall.c:97^M
97 thread_ids[tid] = tid + 2; /* prethreadcreationmarker */^M
(gdb) FAIL: gdb.threads/multiple-successive-infcall.exp: thread=5: \
created new thread
...
The problem is that the new thread message doesn't match the regexp, which
expects something like this instead:
...
[New Thread 0x7ffff746e700 (LWP 570)]^M
...
Fix this by accepting this form of new thread message.
Tom de Vries [Thu, 9 Mar 2023 11:31:26 +0000 (12:31 +0100)]
[gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver
With test-case gdb.threads/thread-specific-bp.exp and target board
native-gdbserver I run into:
...
(gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=off: thread 1 selected
continue^M
Continuing.^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
^M
Thread 1 "thread-specific" hit Breakpoint 4, end () at \
thread-specific-bp.c:29^M
29 }^M
(gdb) FAIL: gdb.threads/thread-specific-bp.exp: non_stop=off: \
continue to end (timeout)
...
The problem is that the test-case tries to match the "[Thread ... exited]"
message which we do see with native testing:
...
Continuing.^M
[Thread 0x7ffff746e700 (LWP 7047) exited]^M
Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.^M
...
The fact that the message is missing was reported as PR remote/30129.
We could add a KFAIL for this, but the functionality the test-case is trying
to test has nothing to do with the message, so it should pass. I only added
matching of the message in commit 2e5843d87c4 ("[gdb/testsuite] Fix
gdb.threads/thread-specific-bp.exp") to handle a race, not realizing doing so
broke testing on native-gdbserver.
Fix this by matching the "Thread-specific breakpoint $decimal deleted" message
instead.
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdb.server/unittest.exp for remote target
With test-case gdb.server/unittest.exp and a build with --disable-unit-tests I
get:
...
(gdb) builtin_spawn /data/vries/gdb/leap-15-4/build/gdbserver/gdbserver \
--selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
but with target board remote-stdio-gdbserver I get instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
/data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Selftests have been disabled for this build.^M
Connection to localhost closed.^M^M
FAIL: gdb.server/unittest.exp: unit tests
...
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdbserver path in remote-stdio-gdbserver.exp
With test-case gdb.server/unittest.exp and target board remote-stdio-gdbserver
I run into:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost /usr/bin/gdbserver \
--selftest^M
Selftests have been disabled for this build.^M
UNSUPPORTED: gdb.server/unittest.exp: unit tests
...
due to using the system gdbserver /usr/bin/gdbserver rather than the one from
the build.
Fix this by removing the hard-coding of /usr/bin/gdbserver in
remote-stdio-gdbserver, allowing find_gdbserver to do its work, such that we
have instead:
...
(gdb) builtin_spawn /usr/bin/ssh -t -l vries localhost \
/data/vries/gdb/leap-15-4/build/gdbserver/gdbserver --selftest^M
Running selftest remote_memory_tagging.^M
Ran 1 unit tests, 0 failed^M
Connection to localhost closed.^M^M
PASS: gdb.server/unittest.exp: unit tests
...
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdb.server/sysroot.exp for remote target
Fix test-case gdb.server/sysroot.exp with target board
remote-gdbserver-on-localhost, by:
- using gdb_remote_download, and
- disabling the "local" scenario for remote host.
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
Test-case gdb.server/multi-ui-errors.exp fails for target board
remote-gdbserver-on-localhost with REMOTE_TARGET_USERNAME=remote-target:
...
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
Executing on target: kill -9 6447 (timeout = 300)
builtin_spawn [open ...]^M
XYZ1ZYX
sh: line 0: kill: (6447) - Operation not permitted
...
The problem is that the kill command:
...
remote_exec target "kill -9 $gdbserver_pid"
...
intended to kill gdbserver instead tries to kill the ssh client session in
which the gdbserver runs, and fails because it's trying as the remote target
user (remote-target on localhost) to kill a pid owned by the the build user
($USER on localhost).
Fix this by getting the gdbserver pid using the ppid trick from
server-kill.exp.
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdb.server/server-kill.exp for remote target
In commit 80dc83fd0e7 ("gdb/remote: handle target dying just before a stepi")
an observation is made that test-case gdb.server/server-kill.exp claims to
kill gdbserver, but actually kills the inferior. Consequently, the commit
adds testing of killing gdbserver alongside.
The problem is that:
- the original observation is incorrect (possibly caused by misreading getppid
as getpid)
- consequently, the test-case doesn't test killing the inferior, instead it
tests killing gdbserver twice
- the method to get the gdbserver PID added in the commit doesn't work
for target board remote-gdbserver-on-localhost, it returns the
PID of the ssh client session instead.
Fixing the method for getting the inferior PID gives us fails, and there's no
evidence that killing the inferior ever worked.
So, fix this by reverting the commit and just killing gdbserver, using the
original method of getting the gdbserver PID which does work for target board
remote-gdbserver-on-localhost.
Tom de Vries [Thu, 9 Mar 2023 09:45:03 +0000 (10:45 +0100)]
[gdb/testsuite] Fix gdb.server/connect-with-no-symbol-file.exp for remote target
Test-case gdb.server/connect-with-no-symbol-file.exp fails with target board
remote-gdbserver-on-localhost.
The problem is here:
...
set target_exec [gdb_remote_download target $binfile.bak $binfile]
...
A "gdb_remote_download target" copies from build to target. So $binfile is
assumed to be a target path, but it's actually a build path.
Fix this by:
- fist copying $binfile.bak to $binfile, and
- simply doing [gdb_remote_download target $binfile].
Then, $binfile.bak is created here:
...
# Make sure we have the original symbol file in a safe place to copy from.
gdb_remote_download host $binfile $binfile.bak
...
and since "gdb_remote_download host" copies from build to host, $binfile.bak
is assumed to be a host path, but it's actually a build path. This happens to
cause no problems in this configuration (because build == host), but it would
for a remote host configuration.
So let's fix this by making build rather than host the "safe place to copy
from".
Tom Tromey [Sun, 26 Feb 2023 17:29:22 +0000 (10:29 -0700)]
Remove OBJF_REORDERED
OBJF_REORDERED is set for nearly every object format. And, despite
the ominous warnings here and there, it does not seem very expensive.
This patch removes the flag entirely.
Carl Love [Tue, 7 Mar 2023 19:34:44 +0000 (13:34 -0600)]
PowerPC, fix test gdb.arch/altivec-regs.exp
The test fails on Power 10 with the RHEL9 distro. It also fails on
Power 9.
The test set a the breakpoint in main that stops at line:
a = 9; /* start here */. The test then sets a break point at the same
line where it wants to start the test and does a continue. GDB does not
stop again on the same line where it is stopped, but rather continues to
the end of the program.
Initialize variable A to zero so the break on main will stop before setting
a break point on line a = 9; /* start here */.
Make the match on the breakpoint number generic.
Patch has been tested on Power 10 with RHEL 9, Power 10 with Ubuntu 22.04,
and Power 9 with Fedora 36 with no regression failures.
Alan Modra [Wed, 8 Mar 2023 03:11:07 +0000 (13:41 +1030)]
Tidy pe_ILF_build_a_bfd a little
* peicode.h (ILF section, pe_ILF_object_p): Correct comments
and update the reference to Microsoft's docs.
(pe_ILF_build_a_bfd): Move all symbol creation before flipping
the bfd over to in-memory.
Alan Modra [Wed, 8 Mar 2023 02:52:00 +0000 (13:22 +1030)]
Re: DIGEST: testsuite
Correct test target/skip lines to fix fails on alpha-dec-vms,
alpha-linux-gnuecoff, i386-bsd, i386-msdos, ns32k-openbsd,
ns32k-pc532-mach, pdp11-dec-aout, rs6000-aix*, tic4x-coff, and
tic54x-coff.
Alan Modra [Tue, 7 Mar 2023 22:49:38 +0000 (09:19 +1030)]
Re: Move nm.c cached line number info to bfd usrdata
Commit e3f450f3933d resulted in a nm -l segfault on object files
without undefined symbols. Fix that, and be paranoid about bfd
section count changing.
* nm.c (struct lineno_cache): Add seccount.
(free_lineno_cache): Don't segfault on NULL lc->relocs.
(print_symbol): Stash section count when creating arrays.
Simon Marchi [Mon, 6 Mar 2023 21:46:50 +0000 (16:46 -0500)]
gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value
The AMD GPU support has been merged shortly after commit 4e1d2f5814b2
("Add new overload of gdbarch_return_value"), which made it mandatory
for architectures to provide either a return_value or
return_value_as_value implementation. Because of my failure to test
properly after rebasing and before pushing, we get this with the current
master:
$ gdb ./gdb -nx --data-directory=data-directory -q -ex "set arch amdgcn:gfx1010" -batch
/home/simark/src/binutils-gdb/gdb/gdbarch.c:517: internal-error: verify_gdbarch: the following are invalid ...
return_value_as_value
I started trying to change GDB to not force architectures to provide a
return_value or return_value_as_value implementation, but Andrew pointed
out that any serious port will have an implementation one day or
another, and it's easy to add a dummy implementation in the mean time.
So it's better to not complicate the core of GDB to know how to deal
with this.
There is an implementation of return_value in the downstream ROCgdb port
(which we'll need to convert to the new return_value_as_value), which
we'll contribute soon-ish. In the mean time, add a dummy implementation
of return_value_as_value to avoid the failed assertion.
Change-Id: I26edf441b511170aa64068fd248ab6201158bb63 Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
Tom Tromey [Tue, 21 Feb 2023 22:03:38 +0000 (15:03 -0700)]
Merge forget_cached_source_info_for_objfile into objfile method
forget_cached_source_info_for_objfile does some objfile-specific work
and then calls objfile::forget_cached_source_info. It seems better to
me to just have the method do all the work.
Tom Tromey [Fri, 27 Jan 2023 04:38:31 +0000 (21:38 -0700)]
Clean up attribute reprocessing
I ran across the attribute reprocessing code recently and noticed that
it unconditionally sets members of the CU when reading a DIE. Also,
each spot reading attributes needs to be careful to "reprocess" them
as a separate step.
This seemed excessive to me, because while reprocessing applies to any
DIE, setting the CU members is only necessary for the toplevel DIE in
any given CU.
This patch introduces a new read_toplevel_die function and changes a
few spots to call it. This is easily done because reading the
toplevel DIE is already special.
I left the reprocessing flag and associated checks in attribute. It
could be stripped out, but I am not sure it would provide much value
(maybe some iota of performance).
Simon Marchi [Thu, 2 Mar 2023 20:32:23 +0000 (15:32 -0500)]
gdb: make interp::m_name an `const char *`
I realized that the memory for interp names does not need to be
allocated. The name used to register interp factory functions is always
a literal string, so has static storage duration. If we change
interp_lookup to pass that name instead of the string that it receives
as a parameter (which does not always have static storage duration),
then interps can simply store pointers to the name.
So, change interp_lookup to pass `factory.name` rather than `name`.
Change interp::m_name to be a `const char *` rather than an std::string.
Change-Id: I0474d1f7b3512e7d172ccd73018aea927def3188 Reviewed-By: Tom Tromey <tom@tromey.com>
gprofng reads Dwarf to find function names, sources, and line numbers.
gprofng skips other debug information.
I fixed three places in gprofng Dwarf reader:
- parsing the compilation unit header.
- parsing the line number table header.
- parsing new DW_FORMs.
Tested on aarch64-linux/x86_64-linux.
gprofng/ChangeLog
2023-03-05 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
Richard Purdie [Tue, 7 Mar 2023 14:21:50 +0000 (14:21 +0000)]
gdb: Fix GDB_AC_CHECK_BFD macro regression
Commit 5218fa9e8937b007d554f1e01c2e4ecdb9b7e271, "gdb: use libtool in
GDB_AC_CHECK_BFD" dropped passing in existing LDFLAGS. In our environment,
this caused the configure check "checking for ELF support in BFD" to stop
working causing build failures as we need our LDFLAGS to be used for
correct linking.
That change also meant the code failed to match the comments. Add back the
missing LDFLAGS preservation, fix our builds and match the comment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change-Id: Ie91509116fab29f95b9db1ff0b6ddc280d460112 Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Jose E. Marchesi <jose.marchesi@oracle.com>
Tom Tromey [Fri, 3 Mar 2023 16:41:35 +0000 (09:41 -0700)]
Ensure index cache entry written in test
Now that index cache files are written in the background, one test in
index-cache.exp is racy -- it assumes that the cache file will have
been written during startup.
This patch fixes the problem by introducing a new maintenance command
to wait for all pending writes to the index cache.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom de Vries [Tue, 7 Mar 2023 14:45:47 +0000 (15:45 +0100)]
[gdb/testsuite] Use shlib gdb_compile option in gdb.base/skip-solib.exp
In test-case gdb.base/skip-solib.exp the linking against a shared library is
done manually:
...
if {[gdb_compile "${binfile_main}.o" "${binfile_main}" executable \
[list debug "additional_flags=-L$testobjdir" \
"additional_flags=-l${test}" \
"ldflags=-Wl,-rpath=$testobjdir"]] != ""} {
...
Instead, use the shlib gdb_compile option such that we simply have:
...
[list debug shlib=$binfile_lib]] != ""} {
...
Tom de Vries [Tue, 7 Mar 2023 14:28:52 +0000 (15:28 +0100)]
[gdb/testsuite] Fix gdb.base/fork-no-detach-follow-child-dlopen.exp for remote target
Fix test-case gdb.base/fork-no-detach-follow-child-dlopen.exp for target board
remote-gdbserver-on-localhost.exp by using gdb_download_shlib and gdb_locate_shlib.
Ulf Samuelsson [Mon, 6 Mar 2023 13:31:57 +0000 (14:31 +0100)]
DIGEST: Makefile.*
The Makefile.in was generated using automake
after adding a few files.
When adding the ldreflect.* files, the autotools
versions were wrong.
After upgrading the host OS, autotools were upgraded to 2.71
reinstalling the desired 2.69 still generates a lot of changes.
Tom de Vries [Tue, 7 Mar 2023 13:46:24 +0000 (14:46 +0100)]
[gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost
With test-case gdb.base/signals-state-child.exp on target board
remote-gdbserver-on-localhost I run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
$outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
Permission denied^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
The problem is that we're trying to run an executable on the target board using
a host path.
After fixing this by downloading the exec to the target board, we run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
signals-state-child-standalone^M
bash: signals-state-child-standalone: command not found^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...
Fix this by using an absolute path name for the exec on the target board.
The dejagnu proc standard_file does not support op == "absolute" for target
boards, so add an implementation in remote-gdbserver-on-localhost.exp.
Also:
- fix a PATH-in-test-name issue
- cleanup gdb.txt and standalone.txt on target board
On AIX, the debugger cannot access vector registers before they
are first used by the inferior. Hence we change the test case
such that some vector registers are accessed by the variable 'x' in AIX
and other targets are not affected as a consequence of the same.
Tom de Vries [Tue, 7 Mar 2023 08:59:56 +0000 (09:59 +0100)]
[gdb/testsuite] Fix gdb.mi/*.exp with remote-gdbserver-on-localhost
When running test-cases gdb.mi/*.exp with target board
remote-gdbserver-on-localhost, we run into a few fails.
Fix these (and make things more similar to the gdb.exp procs) by:
- factoring out mi_load_shlib out of mi_load_shlibs
- making mi_load_shlib use gdb_download_shlib, like
gdb_load_shlib
- factoring out mi_locate_shlib out of mi_load_shlib
- making mi_locate_shlib check for mi_spawn_id, like
gdb_locate_shlib
- using gdb_download_shlib and mi_locate_shlib in the test-cases.
Tested on x86_64-linux, with and without target board
remote-gdbserver-on-localhost.
Simon Marchi [Thu, 23 Feb 2023 17:35:41 +0000 (12:35 -0500)]
gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.c
When building with clang 16, I see:
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.load_args = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.critical = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.interrupt = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
/home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
info->prologue_type.fp_sdcc = 1;
^ ~
Fix that by using "unsigned int" as the bitfield's underlying type.
Simon Marchi [Thu, 23 Feb 2023 17:35:40 +0000 (12:35 -0500)]
gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h
When building with clang 16, we get:
CXX gdb.o
In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]
integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
^
The error message does not make it clear in the context of which enum
flag this fails (i.e. what is T in this context), but it doesn't really
matter, we have similar warning/errors for many of them, if we let the
build go through.
clang is right that the value -1 is invalid for the enum type we cast -1
to. However, we do need this expression in order to select an integer
type with the appropriate signedness. That is, with the same signedness
as the underlying type of the enum.
I first wondered if that was really needed, if we couldn't use
std::underlying_type for that. It turns out that the comment just above
says:
/* Note that std::underlying_type<enum_type> is not what we want here,
since that returns unsigned int even when the enum decays to signed
int. */
I was surprised, because std::is_signed<std::underlying_type<enum_type>>
returns the right thing. So I tried replacing all this with
std::underlying_type, see if that would work. Doing so causes some
build failures in unittests/enum-flags-selftests.c:
This is a bit hard to decode, but basically enumerations have the
following funny property that they decay into a signed int, even if
their implicit underlying type is unsigned. This code:
enum A {};
enum B {};
int main() {
std::cout << std::is_signed<std::underlying_type<A>::type>::value
<< std::endl;
std::cout << std::is_signed<std::underlying_type<B>::type>::value
<< std::endl;
auto result = true ? A() : B();
std::cout << std::is_signed<decltype(result)>::value << std::endl;
}
produces:
0
0
1
So, the "CHECK_VALID" above checks that this property works for enum flags the
same way as it would if you were using their underlying enum types. And
somehow, changing integer_for_size to use std::underlying_type breaks that.
Since the current code does what we want, and I don't see any way of doing it
differently, ignore -Wenum-constexpr-conversion around it.
John Baldwin [Tue, 7 Mar 2023 00:55:22 +0000 (16:55 -0800)]
gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.
- Some OS's use a different syscall for exit(). For example, the
BSD's use SYS_exit rather than SYS_exit_group. Update the C source
file and the expect script to support SYS_exit as an alternative to
SYS_exit_group.
- The cross-arch syscall number tests are all Linux-specific with
hardcoded syscall numbers specific to Linux kernels. Skip these
tests on non-Linux systems. FreeBSD kernels for example use the
same system call numbers on all platforms, so the test is also not
relevant on FreeBSD.
John Baldwin [Tue, 7 Mar 2023 00:55:22 +0000 (16:55 -0800)]
gdb.threads/multi-create: Double the existing stack size.
Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the
stack on FreeBSD rather than raising it causing non-main threads in
the test program to overflow their stack and crash. Double the
existing stack size rather than assuming that the initial stack size
is PTHREAD_STACK_MIN.
John Baldwin [Tue, 7 Mar 2023 00:47:03 +0000 (16:47 -0800)]
amd64-linux-tdep: Don't treat fs_base and gs_base as system registers.
These registers can be changed directly in userspace, and similar
registers to support TLS on other architectures (tpidr* on ARM and
AArch64, tp on RISC-V) are treated as general purpose registers.
John Baldwin [Tue, 7 Mar 2023 00:47:03 +0000 (16:47 -0800)]
gdb.arch/amd64-gs_base.exp: Support non-Linux.
The orig_rax pseudo-register is Linux-specific and isn't relevant to
this test. The fs_base and gs_base registers are also not treated as
system registers in other OS ABIs. This allows the test to pass on
FreeBSD.
Kévin Le Gouguec [Wed, 22 Feb 2023 12:37:06 +0000 (13:37 +0100)]
gdb/python: Fix --disable-tui build
As of 2023-02-13 "gdb/python: deallocate tui window factories at Python
shut down" (9ae4519da90), a TUI-less build fails with:
$src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’:
$src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared
621 | gdbpy_tui_window_maker::invalidate_all ();
| ^~~~~~~~~~~~~~~~~~~~~~
Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an
#ifdef guard in gdbpy_finalize_tui as well.
Tom de Vries [Mon, 6 Mar 2023 15:49:19 +0000 (16:49 +0100)]
[gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuite
Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests
the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather
than gdb.base.
Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to
gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with
recently added gdb.testsuite/gdb-caching-proc.exp.
Tom de Vries [Mon, 6 Mar 2023 15:49:19 +0000 (16:49 +0100)]
[gdb/testsuite] Allow args in gdb_caching_proc
Test-case gdb.base/morestack.exp contains:
...
require {have_compile_flag -fsplit-stack}
...
and I want to cache the result of have_compile_flag.
Currently gdb_caching_proc doesn't allow args, so I could add:
...
gdb_caching_proc have_compile_flag_fsplit_stack {
return [have_compile_flag -fsplit-stack]
}
...
and then use that proc instead, but I find this cumbersome and
maintenance-unfriendly.
Instead, allow args in a gdb_caching_proc, such that I can simply do:
...
-proc have_compile_flag { flag } {
+gdb_caching_proc have_compile_flag { flag } {
...
Note that gdb_caching_procs with args do not work with the
gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped.
Tom de Vries [Mon, 6 Mar 2023 15:49:19 +0000 (16:49 +0100)]
[gdb/testsuite] Use regular proc syntax for gdb_caching_proc
A regular tcl proc with no args looks like:
...
proc foo {} {
return 1
}
...
but a gdb_caching_proc deviates from that syntax by dropping the explicit no
args bit:
...
gdb_caching_proc foo {
return 1
}
...
Make the gdb_caching_proc use the same syntax as regular procs, such that we
have instead:
...
gdb_caching_proc foo {} {
return 1
}
...
Tom Tromey [Thu, 16 Feb 2023 17:25:23 +0000 (10:25 -0700)]
Remove exception_catchpoint::resources_needed
exception_catchpoint::resources_needed has a FIXME comment that I
think makes this method obsolete. Also, I note that similar
catchpoints, for example Ada catchpoints, don't have this method.
This patch removes the method. Regression tested on x86-64 Fedora 36.
Tom Tromey [Fri, 17 Feb 2023 17:00:01 +0000 (10:00 -0700)]
Remove two more files in gdb "distclean"
The recent work to have gdb link via libtool means that there are a
couple more generated files in the build directory that should be
removed by "distclean".
Note that gdb can't really fully implement distclean due to the desire
to put certain generated files into the distribution. Still, it can
get pretty close.
Alan Modra [Mon, 6 Mar 2023 09:59:42 +0000 (20:29 +1030)]
macho null dereference read
The main problem here was not returning -1 from canonicalize_symtab on
an error, leaving the vector of relocs only partly initialised and one
with a null sym_ptr_ptr.
* mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error,
not 0.
(bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to
undefined section sym.
Alan Modra [Mon, 6 Mar 2023 00:13:53 +0000 (10:43 +1030)]
PR30198, Assertion and segfault when linking x86_64 elf and coff
PR 30198
* coff-x86_64.c (coff_amd64_reloc): Set *error_message when
returning bfd_reloc_dangerous. Also check that __ImageBase is
defined before accessing h->u.def.
Alan Modra [Mon, 6 Mar 2023 00:13:08 +0000 (10:43 +1030)]
Downgrade objdump fatal errors to non-fatal
* objdump.c (slurp_symtab): Replace bfd_fatal calls with calls
to my_bfd_nonfatal.
(slurp_dynamic_symtab, disassemble_section): Likewise.
(disassemble_data): Replace fatal call with non_fatal call, and
set exit_status. Don't error on non-existent dynamic relocs.
Don't call bfd_fatal on bfd_canonicalize_dynamic_reloc error.
(dump_ctf, dump_section_sframe): Replace bfd_fatal calls with
calls to my_bfd_nonfatal and clean up memory.
(dump_relocs_in_section): Don't call bfd_fatal on errors.
(dump_dynamic_relocs): Likewise.
(display_any_bfd): Make archive nesting too depp non_fatal.
Alan Modra [Mon, 6 Mar 2023 00:12:51 +0000 (10:42 +1030)]
Downgrade nm fatal errors to non-fatal
Many of the fatal errors in nm ought to be recoverable. This patch
downgrades most of them. The ones that are left are most likely due
to memory allocation failures.
* nm.c (print_symdef_entry): Don't bomb with a fatal error
on a corrupted archive symbol table.
(filter_symbols): Silently omit symbols that return NULL
from bfd_minisymbol_to_symbol rather than giving a fatal
error.
(display_rel_file): Don't give a fatal error on
bfd_read_minisymbols returning an error, or on not being able
to read dynamic symbols for synth syms.
(display_archive): Downgrade bfd_openr_next_archived_file
error.
(display_file): Don't bomb on a bfd_close failure.
Alan Modra [Mon, 6 Mar 2023 00:12:36 +0000 (10:42 +1030)]
Move nm.c cached line number info to bfd usrdata
Replace the static variables used by nm to cache line number info
with a struct attached to the bfd. Cleaner, and it avoids any concern
that lineno_cache_bfd is somehow left pointing at memory for a closed
bfd and that memory is later reused for another bfd, not that I think
this is possible. Also don't bomb via bfd_fatal on errors getting
the line number info, just omit the line numbers.
* nm.c (struct lineno_cache): Rename from get_relocs_info.
Add symcount.
(lineno_cache_bfd, lineno_cache_rel_bfd): Delete.
(get_relocs): Adjust for struct rename. Don't call bfd_fatal
on errors.
(free_lineno_cache): New function.
(print_symbol): Use lineno_cache in place of statics. Don't
call bfd_fatal on errors reading symbols, just omit the line
info.
(display_archive, display_file): Call free_lineno_cache.
Alan Modra [Mon, 6 Mar 2023 00:12:22 +0000 (10:42 +1030)]
Correct objdump command line error handling
bfd_nonfatal is used when a bfd error is to be printed. That's not
the case for command line errors.
* objdump.c (nonfatal): Rename to my_bfd_nonfatal.
(main): Use non_fatal and call usage on unrecognized arg errors.
Don't set exit_status when calling usage.
Simon Marchi [Fri, 3 Mar 2023 16:37:44 +0000 (11:37 -0500)]
gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO`
When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash,
rather than bash, I get:
c&^M
Continuing.^M
(gdb) sh: 1: kill: Illegal option -S^M
^M
Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout)
This is because it uses the kill command built-in the dash shell, and
using the SIG prefix with kill does not work with dash's kill. The
difference is listed in the documentation for bash's POSIX-correct mode
[1]:
The kill builtin does not accept signal names with a ‘SIG’ prefix.
Replace SIGINT with INT in that test.
By grepping, I found two other instances (gdb.base/sigwinch-notty.exp
and gdb.threads/detach-step-over.exp). Those were not problematic on my
system though. Since they are done through remote_exec, they don't go
through the shell and therefore invoke /bin/kill. On my Arch Linux,
it's:
$ /bin/kill --version
kill from util-linux 2.38.1 (with: sigqueue, pidfd)
and on my Ubuntu:
$ /bin/kill --version
kill from procps-ng 3.3.17
These two implementations accept "-SIGINT". But according to the POSIX
spec [2], the kill utility should recognize the signal name without the
SIG prefix (if it recognizes them with the SIG prefix, it's an
extension):
-s signal_name
Specify the signal to send, using one of the symbolic names defined
in the <signal.h> header. Values of signal_name shall be recognized
in a case-independent fashion, without the SIG prefix. In addition,
the symbolic name 0 shall be recognized, representing the signal
value zero. The corresponding signal shall be sent instead of SIGTERM.
-signal_name
[XSI] [Option Start]
Equivalent to -s signal_name. [Option End]
So, just in case some /bin/kill implementation happens to not recognize
the SIG prefixes, change these two other calls to remove the SIG
prefix.
Tom Tromey [Fri, 3 Mar 2023 15:05:41 +0000 (08:05 -0700)]
Update expected results in long_long.exp
Simon pointed out that the recent patch to add half-float support to
'x/f' caused a couple of regressions in long_long.exp. This patch
fixes these by updating the expected results.
Jan Beulich [Fri, 3 Mar 2023 07:46:41 +0000 (08:46 +0100)]
x86: use swap_2_operands() in build_vex_prefix()
Open-coding part of what may eventually be needed is somewhat risky.
Let's use the function we have, taking care of all pieces of data which
may need swapping, no matter that
- right now i.flags[] and i.reloc[] aren't relevant here (yet),
- EVEX masking and embedded broadcast aren't applicable.
Jan Beulich [Fri, 3 Mar 2023 07:46:13 +0000 (08:46 +0100)]
x86: drop redundant calculation of EVEX broadcast size
In commit a5748e0d8c50 ("x86/Intel: allow MASM representation of
embedded broadcast") I replaced the calculation of i.broadcast.bytes in
check_VecOperands() not paying attention to the immediately following
call to get_broadcast_bytes() doing exactly that (again) first thing.
While commit b0c295e1b8d0 ("add --enable-default-compressed-debug-
sections-algorithm configure option") adjusted flag_compress_debug's
initializer, it didn't alter the default used when the command line
option was specified with an (optional!) argument. This rendered help
text inconsistent with actual behavior in certain configurations.
As to help text - the default reported there clearly shouldn't be
affected by a possible earlier --compress-debug-sections= option, so
flag_compress_debug can't be used when emitting usage information.
Jan Beulich [Fri, 3 Mar 2023 07:45:12 +0000 (08:45 +0100)]
x86: avoid .byte in testcases where possible
In the course of using the upcoming .insn directive to eliminate various
.byte uses in testcases I've come across these, which needlessly use
more .byte than necessary even without the availability of .insn.
Alan Modra [Fri, 3 Mar 2023 00:45:35 +0000 (11:15 +1030)]
Tidy type handling in binutils/rdcoff.c
There isn't really any good reason for code in rdcoff.c to distinguish
between "basic" types and any other type. This patch dispenses with
the array reserved for basic types and instead handles all types using
coff_get_slot, simplifying the code.
* rdcoff.c (struct coff_types, coff_slots): Merge. Delete
coff_slots.
(T_MAX): Delete.
(parse_coff_base_type): Use coff_get_slot to store baseic types.
(coff_get_slot, parse_coff_type, parse_coff_base_type),
(parse_coff_struct_type, parse_coff_enum_type),
(parse_coff_symbol, parse_coff): Pass types as coff_types**.
projects / thirdparty / binutils-gdb.git / log
