The Be Book [1] states that these are supposed to be C functions,
but the comment (see diff) said they were deprecated, and the fact
that they were in a .cpp file (and I checked with "nm") made them
C++ functions.
I can't recall any applications failing to start because these
symbols were unresolved, so we might be able to just remove them...
[1]: https://www.haiku-os.org/legacy-docs/bebook/BFilePanel_Overview.html
"git blame" indicates they've been here since Tracker was imported
into the tree, and a single paragraph explaining their existence
just states they are more efficient/faster than the ones in BString
due to running simple checks before calling str*cmp.
If there is (still) such a performance problem in our BString, we should
fix it there and not use hacky workarounds. I didn't notice any difference
in speed when using Tracker with this patch; however, I'm on a reasonably
fast machine.
- Factor out RegistersView's SIMD output formatting functions into
UiUtils helpers. Adjust RegistersView accordingly.
- Adjust DebugReportGenerator to detect SIMD registers and format
them appropriately for report output using the aforementioned
helpers.
RegisterTableModel:
- Add member for preferred SIMD unit format, and use it to decide
what to divide up such registers as, rather than hardcoding 16 bit integer.
RegistersView:
- When right clicking on an SIMD register, display a format context menu
allowing the user to decide what packed unit format to interpret the register
data as, and adjust table model accordingly.
DebuggerInterface,Architecture{X86,X8664}:
- Add hook function for retrieving a feature flag mask for the target CPU,
and corresponding implementation in Architecture-specific classes.
ArchitectureX86:
- Read CPU features on init, and use them to restrict the exposed set of
registers such that the MMX and SSE registers will only be visible
if the target CPU actually supports the respective instructions.
- If an SIMD register is detected, retrieve its value and format
it as an array of 16-bit hex values. This will be extended to
allow other format choices in a future commit.
ArchitectureX86{-64}:
- Implement helper functions for adding floating point and SIMD registers.
- Add st0-st7 and mm0-mm7 to the list of exposed x86{-64} registers,
along with their DWARF unwind mappings.
- Add xmm0-xmm7 for x86, and xmm0-xmm15 for x86-64.
CpuStateX86{-64}:
- Implement helper functions for setting/retrieving floating point and SIMD
register values.
- Fill in values for st*, mm* and xmm* from debug_cpu_state.
Since zip has been outsourced, it's possible to loose it when
upgrading, in which case ZOM went busylooping without noticing the
thread actually never started.
At least now it says "failed to create the archive".
Maybe it should try to install zip?
If it was already determined that the memory is within the kernel
stack, a simple memcpy is enough.
This allows capturing kernel stack traces in situations where a fault
handler cannot be installed (i.e. where one is already installed).
When extracting/inserting report items there might not be a full uint32
available in the report anymore. Only copy as many bytes as are actually
needed by the report item and guaranteed to be present in the report.
Twice the size was copied due to a missed adjustment in hrev31839,
reading past the key state array. This didn't cause any corruption
because the overwritten state wasn't used anymore later on and the
write didn't overrun. It could cause a crash however if the read went
past the allocated area.
On close a flag is set in the cookie of this user of a protocol handler
and the device cancels its pending transfer. This wakes up any possible
listeners. When the closed flag is set, an error code is returned from
_ReadReport() which causes the retry loop to be left. Handlers listening
on the same device which were not closed just retry the transfer.
This ensures that closing a device will cause pending control requests
to complete with a sensible error code.
Augustin Cavalier