Graviton has a GICv3 with a modified GICv2m (!) for MSIs. Instead of
sending messages to a fixed address with the SPI as data, the Graviton's
GICv2m uses a different address for each vector with "don't care" as data.
reading PCI_ID_REG. pci_enumerate_bus was incorrectly reading PCI_BHLC_REG
first, which surprisingly has worked for the past 16 years. Unfortunately,
this undefined behavior does the wrong thing on Amazon's Annapurna Labs
PCIe host controller.
address size is 16 bits, regardless of the actual operating mode. With
this special map there can be two registers referenced at once, and
also disp16-only.
Implement this special behavior, and add associated tests. While here
simplify a few things.
With this in place, the Windows 95 installer initializes correctly.
Part of PR/54611.
have been converted to GCC_NO_FORMAT_TRUNCATION rather than
GCC_NO_STRINGOP_TRUNCATION which is what happened. This might unbreak
the build (olr at least get it further).
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
This is a torture, but on purpose to catch LWP_CREATED and LWP_EXITED bugs.
The threads do nothing other than calling sched_yield() in a loop.
MAXLWP is now defined to 2048 on all ports.
This change effects the following tests:
- trace_thread_nolwpevents
- trace_thread_lwpexit
- trace_thread_lwpcreate
- trace_thread_lwpcreate_and_exit
For the PTRACE_LWP_EXIT event, the eventswitch() call is triggered from
lwp_exit(). In the case of setting the program status to PS_WEXIT, do not
try to demise in place, by calling lwp_exit() as it causes panic.
In this scenario bail out from the function and resume the lwp_exit()
procedure.
In case of sigswitchin away in issignal() and continuing the execution on
PT_CONTINUE (or equivalent call), there is a time window when another
thread could cause the process state to be changed to PS_STOPPING.
In the current logic, a thread would receive signal 0 (no-signal) and exit
from issignal(), returning to userland and never finishing the process of
stopping all LWPs. This causes hangs waitpid() waiting for SIGCHLD and
the callout polling for the state of the process in an infinite loop.
Instead of prompting for a returned signal from a debugger, repeat the
issignal() loop, this will cause checking the PS_STOPPING flag again and
sigswitching away in the scenario of stopping the process.
Make the function static as it is now local to kern_sig.c.
Rename the 'relock' argument to 'proc_lock_held' as it is more verbose.
This was suggested by mjg@freebsd. While there this flips the users between
true<->false.
Add additional KASSERT(9) calls here to validate whethe proc_lock is used
accordingly.
