src/add-ons/translators/wonderbrush/WonderBrushView.cpp: In constructor 'WonderBrushView::WonderBrushView(const BRect&, const char*, uint32, uint32, TranslatorSettings*)':
src/add-ons/translators/wonderbrush/WonderBrushView.cpp:58:8: warning: variable 'xbold' set but not used [-Wunused-but-set-variable]
src/add-ons/translators/wonderbrush/WonderBrushView.cpp:58:15: warning: variable 'ybold' set but not used [-Wunused-but-set-variable]
src/add-ons/translators/wonderbrush/WonderBrushView.cpp:64:8: warning: variable 'yplain' set but not used [-Wunused-but-set-variable]
Unlike the header or field members, the 'what' field is always a 32-bit
integer, rather than being arch-dependent. This would cause us to bail
out early without ever trying to process/resolve children.
ResolvePICFunctionAddress() needs to restore the CPUState object back
to how it was when it was originally passed in. Fixes various issues
that would occur as a result.
- Add Architecture::ResolvePICFunctionAddress() and pull out the
previous code in DwarfImageDebugInfo into the x86-specific
implemementation.
- PIC handling works a bit differently on x86-64 than it does on x86
since x86-64 is likely to use RIP-relative addressing. Implement
ArchitectureX8664::ResolvePICFunctionAddress() accordingly.
Define HAVE_ARPA_INET_H for the wget build. Otherwise, e.g. inet_ntoa
would get an implicit declaration with a return type of int, leading to
the returned character pointer getting truncated on x86-64, and
consequently random crashes.
* Added methods to fill the package list view, creating PackageRows
from PackageInfos, various TODOs.
* Some additions in the info classes, UserRating needs language.
Take into account the operand and offset size as needed, otherwise
we'd potentially use the wrong value for our calculations.
Gets return values somewhat working on x86-64, though in some cases
looking up a PLT slot's destination fails, for as yet undetermined
reasons.
If the subroutine address in question required us to in a different
image, that lookup would overwrite our pointer to the starting image.
If said lookup then also failed, a crash would occur when performing
operations to look up the next return value, since the image pointer
would then be NULL.
DisassemblerX8664::GetNextInstructionInfo() was mistakenly truncating the
instruction address due to a copy-and-paste bug when it was initially
spawned off DisassemblerX86. This would result in the temporary breakpoints
for skipping over function calls never getting set properly, leading to us
stepping into the PLT on a step over.
Completely non-functional. Should be replaced by something visually
more unified. The selected package's title and icon should be always
visible above the three sections, and the sections should not be
tabs but something more subtle.
BColumnListView derived class with code-duplication from
DriveSetup that should be refactored eventually (BIconStringColumn
and BColumn implementation to show it). Does nothing except create
some columns.
devfs_io() can't fall back to calling vfs_synchronous_io(), if the
device driver doesn't support handling requests asynchronously. The
presence of the io() hook leads the VFS (do_iterative_fd_io()) to
believe that asynchronous handling is supported and set a
finished-callback on the request which calls the io() hook to start the
next chunk. Thus, instead of iterating through the request in a loop
the iteration happens recursively. For sufficiently fragmented requests
the stack may overflow (ticket #9900).
* Introduce a new vnode operation supports_operation(). It can be called
by the VFS to determine whether a present hook is actually currently
supported for a given vnode.
* devfs: implement the new hook and remove the fallback handling in
devfs_io().
* vfs_request_io.cpp: use the new hook to determine whether the io()
hook is really supported.
This is for the most part a direct copy of the equivalent x86 function
with adjustments to deal with the difference in address sizes and
registers. This gets architectural (aka unassisted) backtraces working
on x86-64, assuming the code in question has been built with frame pointers
enabled.
Thanks to Alex Smith for his assistance in implementing the
function prologue and syscall iframe detection.
