This turns an IO bound problem into a CPU bound problem. In my testing this
speeds up icon resizing dramatically although the CPU is quickly pegged at
100% trying to redraw the Deskbar if you whip the icon size slider back and
forth with a dozen or so apps open and soon the CPU can't keep up and Deskbar
lags behind.
- The info list can in fact be NULL so we need to guard against that. This
wouldn't currently get hit though, since the cases where the list isn't
passed in are those where we only want a minimal frame anyways, so
variable/return value creation wouldn't even be attempted.
- Replace use of address + CpuState pair in Thread,
SpecificImageDebugInfo::CreateStackTrace() with a ReturnValueInfoList.
Adjust all implementing subclasses and callers accordingly.
- DwarfImageDebugInfo::CreateReturnValue() -> CreateReturnValues().
Now processes a list of return value information structures rather
than just a single one. This means we can now handle multiple return
values in a single statement. This still isn't entirely correct though,
since, e.g. for functions whose return types fit in a register we need
to either retrieve them immediately after function return, or store the
CPU state at that point in time for later use in value retrieval,
otherwise the return values will all be those of the last called function.
- In the case of position independent code, the initial call isn't to
the function we want, but rather to a PLT slot which resolves the
function's location. As such, find that slot and use it to determine
the corresponding GOT offset for the function's real location.
Still need some further refactoring of return value handling to properly
handle the case of stepping over a single line that makes multiple calls,
but this fixes the basic case at least.
- When we detect that we're stepping over a function call, also store
the CPU state at the time it occurred. This information is needed
in order to correctly reconstruct target addresses later since some
operands may be register-based.
- Add the aforementioned CPU state to CreateFrame()'s arguments and
adjust implementations and callers accordingly.
The main purpose of this patch is to prevent VFS from removing a vnode to early
what might have happened if the NFS client knew it had more than one name but
then one of them was deleted. Moreover, all discovered and still valid names
are stored what may be useful in proper file handle recovery when they are
volatile.
This patch fixes both #9558 and #9561.
It's sufficient to simply check if the gcc version is 4 or higher since
we enforce the use of the latest ported compiler for the build anyways,
and these multi-level checks would fail in their current state if gcc
moved to e.g. version 5.0.
Instead of destroying and rebuilding the application menu bar each time we
change state, create it at startup and then only update it from there on. This
means that bugs that rely on the app bar being constantly destroyed and rebuilt
will be much less likely to occur.
Unfortunatly, there is still one case where the application menu bar is being
destroyed and recreated and that is when you are switching between horizontal
and vertical mode, and that is because a menu bar cannot be altered from
B_ITEMS_IN_ROWS to B_ITEMS_IN_COLUMNS anywhere but in the constructor.
* Renamed fExpando to fExpandoMenuBar
* Updated TExpandoMenuBar to be more flexible after construction, the menu
items are built in the new BuildItems() method. Also, don't pass the BarView
object in at contruction, that can happen in AttachedToWindow(). Also, set
fDeskbarMenuWidth just once at constructor, no reason to keep setting it over and over again.
The physical memory map area was not included in the kernel virtual
address space range (it was below KERNEL_BASE). This caused problems
if an I/O operation took place on physical memory mapped there (the
bad address error seen in #9547 was occurring in lock_memory_etc()).
Changed KERNEL_BASE and KERNEL_SIZE to cover the area and add a null
area that covers all of it. Also changed X86VMTranslationMap64Bit to
handle large pages in Query(), as the physical map area uses large
pages.
* This parses the reported CPU name, and tries to translate it to a normal
and concise identifier.
* For example, it will translate "AMD FX(tm)-8320 Eight-core Processor" into
"FX™ 8320" or "Dual Core AMD Opteron(tm) Processor 275 HE" into
"Opteron™ 275 HE".
* This means we can remove AMD strings for those models for which this
function produces useful results.
