[lldb] Add a packet-test-delay setting for testing slow connections (#195440)
[lldb] Add a packet-test-delay setting for testing slow connections
Sending/receiving packets to/from a non-host devices adds latency to
the gdb-remote communication that induces substantial slowdown into the
debugging experience.
This patch adds an artificial delay before sending a packet to
simulate this latency without requiring an emulated/physical device.
The test checks only checks that there is a delay when this setting is
activated, but not that there is no delay when the setting is not
activated. The reason for this is that this negative test would either
require a large delay (which further slows down the test suite) or be
prone to accidential failures on overloaded test bots.
There is also the question whether we should have dynamic delays that
depend on the number of transferred bytes. From talking to Felipe it
[10 lines not shown]
snd_hda: Reassign duplicate HDMI/DP pin sequences instead of disabling
Some firmware (e.g. Apple EFI on Sandy Bridge Mac hardware) programs all
HDMI/DP output pins in an association with identical sequence numbers.
The existing code disables the entire association on the first
duplicate, leaving HDMI/DP audio non-functional.
For digital output pins (HDMI/DP) with seq=0 duplicates, search for the
next free sequence slot and reassign the duplicate rather than
disabling.
The seq=0 restriction targets the known Apple firmware pattern; any
other duplicate sequence is more likely a genuine firmware error and the
association is still disabled.
Update first after reassignment so that hpredir is not left pointing at
a stale sequence. Non-digital and input associations retain the existing
disable behaviour.
[4 lines not shown]
[NFC] Clarify behavior of ownership_holds in docs (#197933)
I misunderstood the behavior of the attribute `ownership_holds` based on
the claim that "using held memory is assumed to be legitimate".
To avoid similar misunderstandings in the future, I'm adding an extra
sentence to the documentation.
(This question came up during the discussion of #196798)
[libc][cmake] Don't assume CPU features in cross builds (#198308)
Assuming all CPU features are available during cross builds will be
incorrect in some cases, such as armv8.0-a where FullFP16 is not
available and therefore FP16 instructions will not be understood.
Looking at the file history, the feature detection code previously
relied on try_run instead of try_compile, which might explain why it
couldn't be used in cross builds as cross built binaries wouldn't be
executable. But now the tests are compile only, they can work for cross
builds too, which would be better than assuming features.
[AArch64][GlobalISel] Add sign bits for G_FCMEQ (#198314)
This adds basic num-sign-bits for G_FCMEQ, G_FCMGE and G_FCMGT, which
all produce either all-ones or all-zeros in each vector lane. This
function apparently goes in AArch64ISelLowering.
