Not sure why but GCC 2 seems to be ignoring the extern "C" in smp.h when
compiling smp_boot_other_cpus() resulting in undefined references. Fixed
by putting extern "C" on the definition too.
Currently all debugger commands assume 32-bit pointers when formatting their
output. This means that on x86_64 the output is incorrectly formatted. Fixed
this by adding a B_PRINTF_POINTER_WIDTH definition (16 on 64-bit, 8 on
32-bit), and using this to correctly format the output. Not all commands have
been fixed yet, but all VM, slab, VFS, team, thread and image commands should
be correct.
- When binary searching functions in the source entry list,
comparing by name and location alone isn't sufficient, since
templates will match those for different instances, Fixes a crash on
exit where the wrong function would get removed from the list, while
the one we actually wanted to remove was still in the list, but then
had its source code cleared. This would later crash the comparison
function due to not being able to get its source location.
- When an image was unloaded, its corresponding image info was never
removed from TeamDebugInfo's list, leading to the latter containing
a deleted object, resulting in various random crashes.
- When attempting to unwind the call frame, we now search for the appropriate
FDE in both .debug_frame and .eh_frame. This mirrors gdb's behavior and
works around the ever-changing whims of the gcc developers as to which
section the requisite FDE/CIE resides in.
No major changes to the kernel: just compiled in arch_smp.cpp and fixed the
IDT load in arch_cpu_init_percpu to use the correct limit for x86_64 (uses
sizeof(interrupt_descriptor)). In the boot loader, changed smp_boot_other_cpus
to construct a temporary GDT and get the page directory address from CR3, as
what's in kernel_args will be 64-bit stuff and will not work to switch the
CPUs into 32-bit mode in the trampoline code. Refactored 64-bit kernel entry
code to not use the stack after disabling paging, as the secondary CPUs are
given a 32-bit virtual stack address by the SMP trampoline code which will
no longer work.
This matches layout in ACPICA and keeps a cleaner boundry between
Haiku and ACPICA code. The only haiku specific file in ACPICA is
achaiku.h and it will hopefully be included upstream soon.
Merging will be simpler as we can just replace acpica contents and
fix Jamfile and build errors in our code.
- The buffer that the debugger used to retrieve messages from
the debug port was slightly too small for the largest of the message
data structs (currently 1100 bytes), causing some types of debug events
to get truncated. This resulted in image creation/deletion events being
received with a truncated image_info struct, which would result in several
fields being returned with random values, most notably the text/data base
and size fields. Consequently, searching those images for an address within
them would fail, leading to #8709. It's possible but not yet confirmed
that this bug is also responsible for #8710, need to test further.
- The version of instantiate_object() that returns the image id from which
the object was reinstantiated was not correctly returning it in all
circumstances, only if it had to find/load the add-on itself. This caused
problems for BShelf since the latter relies on that image id in order to
determine what image to unload when replicants are removed. To remedy this,
introduce an additional version of find_instantiation_func() that returns
the image id in which the instantiation function was found, and make use
of it in instantiate_object() in order to also be able to return the image
id in that case.
* Use gcc and g++ rather than cc and c++, as the latter now point to
clang with recent Xcode versions and compilation of the host tools
fail for various reasons with it.
* Replace the case-sensitive filesystem check with a more basic one,
as diskutil no longer supports the behaviour of getting info for the
volume that any path is on.
* Updated ReadMe with a correct list of prerequisites for OS X.
* GCC 2 builds are still broken due to a strange error that only
occurs with a GCC 2 built on OS X 10.7
Several build features (including a future patch for WebKit)
are enabled only if a respective optional package is added.
Prior to this, none of those build features could be activated
in a sub-jam process.
A proper page fault handler was required for areas that were not locked
into the kernel address space. This enables the boot process to get
up to the point of trying to find the boot volume.
* Thread creation and switching is working fine, however threads do not yet
get interrupted because I've not implemented hardware interrupt handling
yet (I'll do that next).
* I've made some changes to struct iframe: I've removed the e/r prefixes
from the member names for both 32/64, so now they're just named ip, ax,
bp, etc. This makes it easier to write code that works with both 32/64
without having to deal with different iframe member names.
This has been done by adding typedefs in elf_common.h to the correct ELF
structures for the architecture, and changing all Elf32_* uses to those
types. I don't know whether image loading works as I cannot test it yet,
there may be some 64-bit safety issues around. However, symbol lookup for
the kernel is working correctly.
This was an interesting bug to find. Was getting spurious triple faults
in the slab allocator. The problem was that the boot paging setup code
was mapping all page tables it created into the virtual address space,
but in the kernel no areas were being created to cover them, so during
arch_vm_init_end() the pages for them ended up being freed and then
overwritten later on. Fixed by unmapping page tables after populating
them in long_mmu_init().
* mmu_get_virtual_mapping() should check that the page directory entry is
present rather than assuming there's a page table there. This was resulting
in some invalid mappings being created in the 64-bit virtual address space.
* arch_vm_init_end() should clear from KERNEL_LOAD_BASE to virtual_end, not
from KERNEL_BASE. On x86_64 this was causing it to loop through ~512GB of
address space, which obviously was taking quite a while.
* Uses 64-bit multiplication, special handling for CPUs clocked < 1 GHz
in system_time_nsecs() not required like on x86.
* Tested against a straight conversion of the x86 version, noticably
faster with a large number of system_time() calls.
