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.
The goal is to do hybrid builds in a single jam (instead of calling a
sub-jam to build parts with the secondary tool chain). This changeset
adds support to configure to prepare multiple tool chains.
configure:
* Merge option --build-cross-tools-gcc4 into --build-cross-tools. The
option does now always require a packaging architecture parameter,
i.e. x86_gcc2 for the legacy tool chain.
* Multiple occurrences of the --build-cross-tools and
--cross-tools-prefix options are allowed. The first one specifies the
primary tool chain, the subsequent ones the secondary tool chains.
* All architecture dependent jam variables are now suffixed with the
name of the packaging architecture. The new HAIKU_PACKAGING_ARCHS
contains the packaging architectures for the prepared tool chains. The
first element is for the primary tool chain.
* No longer generate a separate libgccObjects file. Just put the
respective variable into BuildConfig as well.
build_cross_tools[_gcc4]:
* Replace the <haiku output dir> parameter by a <install dir>
parameter. This allows to create different cross-tools directories.
They are simply suffixed by the packaging architecture.
Jamrules:
* For the moment map the variables for the primary tool chain to the
respective suffix-less variables, so that everything still works as
before.
The next step is to actually support the secondary tool chains in the
jam build system. This will require quite a bit more butchering, though.
* before adding a child to a parent entry, we need to check if the
parent already contains that child, as otherwise duplicate children
with identical names would be added, which in turn messes up the
handling of the entries that are to be extracted
Although syscalls are done through SYSCALL and therefore don't actually
have an interrupt number, set it to 99 (the syscall vector on 32-bit)
in the iframe so that a syscall frame can be identified. Also added
vector/error_code to x86_64_debug_cpu_state for Debugger to use, not
sure why I didn't put them there in the first place.
* The client should enter state REBINDING only when RENEWING times
out.
* When in RENEWING or REBINDING state do not give up retrying
unless the lease expires.
* Fix bug sending 2^n DHCP requests at n-th lease renewal.
* Use timeout values and renewal/rebinding times suggested by the
RFC.
* Use different XIDs in subsequent transactions.
This is a GNU extension for identifying the case of a template parameter
that is itself a template. We don't currently make use of it, but this
allows us to parse/skip it correctly.
With this change, webcore is loadable/debuggable on x86-64 when built
with -gdwarf-4, with the caveat that ~3-4GB of RAM are currently required.
