As mentioned in one of the previous commits, breakpoints don't work
properly yet, and I haven't done much extensive testing yet, but the
basic functionality works.
Reused x86 arch_user_debugger.cpp, with a few minor changes to make
the code work for both 32 and 64 bit. Something isn't quite working
right, if a breakpoint is hit the kernel will hang. Other than that
everything appears to work correctly.
Fixes were needed to go with the USB stack changes. Haven't tested it
yet because I don't have a a machine with OHCI, but I doubt there
will be any problems.
With this commit, app_server now compiles and runs at boot! Nothing
particularly interesting happens, just the blue background and a mouse
pointer. Remote backends are broken and not compiled in, see #8834.
Note that it won't be possible to build this quite yet, need to get
the FreeType package uploaded.
This module provides an interface for drivers to use to perform calls
to the BIOS (only really for use by graphics drivers which need to use
the VESA BIOS). It uses the x86emu library from X.org which emulates
a real mode x86 CPU. This is necessary for x86_64 as virtual 8086 mode
no longer exists there.
* Changed IS_USER_ADDRESS to check an address using USER_BASE and
USER_SIZE, rather than just !IS_KERNEL_ADDRESS. The old check would
allow user buffers to point into the physical memory map area.
* Added an unmapped hole at the end of the bottom half of the address
space which catches buffers that cross into the uncanonical address
region. This also removes the need to check for uncanonical return
addresses in the syscall handler, it is no longer possible for the
return address to be uncanonical under normal circumstances. All
cases in which the return address might be changed by the kernel
are still handled via the IRET path.
The current behaviour of aligning to the maximum value of p_align seen
is problematic for x86_64, as the default segment alignment is 2MB.
This causes all x86_64 binaries to be padded to at least 2MB when
resources are added to them. There is no need to align to p_align in
the file itself (it's only an in-memory requirement), therefore
instead just align up to an 8-byte boundary. The current behaviour is
retained for ELF32, so this won't cause any compatibility problems
(there are no existing ELF64 BeOS/Haiku binaries to worry about).
The boot script now launches consoled instead if app_server does not
exist, so there is now an interactive Bash prompt! libbe requires ICU,
which is an optional package, so I've built the packages and they've
been uploaded to haiku-files.org (thanks umccullough).
I'm using consoled at the moment without input_server having been run,
so when it starts the input drivers will not have been loaded. Have to
retry a few times with delays so that the input devices have a chance
to appear.
Fixed the usual issues - printf format strings, uint32 instead of
addr_t, etc. One thing that isn't so nice is several places where
BList is used to store (u)int32, these require a double cast to addr_t
then void* to silence a warning on x86_64.
The elfedit tool doesn't exist with the old binutils, so configure was
failing when it tried to get the path to it. Only try to search for it
if building GCC 4.
GCC 2 built for OS X 10.7/10.8 was broken, the Haiku build would fail
with some strange errors. Forcing compilation of GCC 2 in 32-bit mode
results in a working GCC.
The USER_BASE_ANY definition exists to specify where to start searching
for B_ANY_ADDRESS allocations, but this was not being used correctly.
On x86_64, this was causing the runtime loader's heap to be allocated
at address 0 so NULL pointer accesses were not getting caught.
The cookie is used to store the base address of the area that was just
visited. On 64-bit systems, int32 is not sufficient. Therefore, changed
to ssize_t which retains compatibility on x86 while expanding to a
sufficient size on x86_64.
* Added x86_64 linker script and relocation code.
* Some 64-bit safety fixes to the heap code.
* Added runtime_loader, libroot and bash to the x86_64 image. The boot
script will be launched, but will panic shortly after because fork
is broken.
These have been pulled from glibc 2.10, the last version before a
bunch of changes were made that would have made porting more difficult.
None of this has been tested yet, it is not currently possible to do
so: I'm just trying to get libroot compiling so that I can work on the
runtime loader. I will test them when I am able to.
The interrupt and system call handlers now perform all the necessary
kernel entry/exit work, and the system call handler now handles calls
with more than 6 arguments. Debugging and system call tracing hooks
are not yet called, will be added when user debugging gets implemented.
Userland switch is implemented, as is basic system call support (using
SYSCALL/SYSRET). The system call handler is not yet complete: it doesn't
handle more than 6 arguments, and does not perform all the necessary kernel
entry/exit work (neither does the interrupt handler). However, this is
sufficient for runtime_loader to start and print some debug output.
Since the demangle debugger extension now gets loaded when booting
from an image, use it in stack traces. Can't print argument values
like on x86, however, since x86_64 uses registers to pass the first
6 arguments rather than the stack we can't easily get to them.
Added a temporary Haiku64Image file that gets included instead of
HaikuImage when building for x86_64, which I will add to as I port
stuff. Images currently only include the boot loader, kernel and
a bunch of add-ons.
Since the commpage is at a kernel address, changed 64-bit paging code
to match x86's behaviour of allowing user-accessible mappings to be
created in the kernel portion of the address space. This is also
required by some drivers.
Since this argument may be used to pass pointers, uint32 is not
correct for 64-bit. Effectively no change on 32-bit targets, both
size_t and uint32 are unsigned long there.
Using "kernel.h" was pulling in the private kernel.h header instead,
which was causing a build failure on my branch since arch_cpu.h is
C++-only there.
This adds disk drivers, intel/session partitioning systems, and ISO9660
(+ write/attribute_overlay) modules to the CD/floppy boot image targets
for x86_64. The kernel now detects and mounts the boot CD, and runs up
to attempting to start the boot script.
Mostly compilation fixes, as well as a few 64-bit safety fixes. I've
briefly looked through everything for any obvious issues and fixed
the ones I've found, and it seems like they're working properly, though
there could be some more well hidden ones that I've missed.
Uses the x86 architecture code, made fixes to printf formats and a
couple of 64-bit fixes. Only potentially intrusive change is that I've
changed PCI.h to use uint32 rather than ulong. I don't see any way
this would cause any issues, though.
Added the necessary build flags for modules, and added a module (dpc)
to the floppy image for x86_64 builds for testing purposes. The module
gets loaded correctly and its code runs without issue. Only non-trivial
addition is the different method for generating kernel.so, this is
explained in the kernel Jamfile.
Alex Smith