Re: [B2-devel] [Patch] Fix for memory allocation errors on Leopard

[Alexei S. <ale...@gm...>]

Committed. Thanks.

-Alexei

On Sun, Aug 16, 2009 at 7:21 PM, Michael Schmitt<msb2ssdev@me> wrote:
> Attached is a patch to SheepShaver to fix memory allocation problems when OS
> X 10.5 is the host. It also relaxes the 512 MB RAM limit on OS X hosts.
>
>
>
>
>
> Problem
> -------
> Some users have been unable to run SheepShaver on OS X 10.5 (Leopard) hosts.
> The symptom is error "ERROR: Cannot map RAM: File already exists".
>
> SheepShaver allocates RAM at fixed addresses. If it is running in "Real"
> addressing mode, and can't allocate at address 0, then it was hard-coded to
> allocate the RAM area at 0x20000000. The ROM area as allocated at
> 0x40800000.
>
> The normal configuration is for SheepShaver to run under SDL, which is a
> Cocoa wrapper. By the time SheepShaver does its memory allocations, the
> Cocoa application has already started. The result is the SheepShaver memory
> address space already contains libraries, fonts, Input Managers, and IOKit
> areas.
>
> On Leopard hosts these areas can land on the same addresses SheepShaver
> needs, so SheepShaver's memory allocation fails.
>
>
> Solution
> --------
> The approach is to change SheepShaver (on Unix & OS X hosts) to allocate the
> RAM area anywhere it can find the space, rather than at a fixed address.
>
> This could result in the RAM allocated higher than the ROM area, which
> causes a crash. To prevent this from occurring, the RAM and ROM areas are
> allocated contiguously.
>
> Previously the ROM starting address was a constant ROM_BASE, which was used
> throughout the source files. The ROM start address is now a variable
> ROMBase. ROMBase is allocated and set by main_*.cpp just like RAMBase.
>
> A side-effect of this change is that it lifts the 512 MB RAM limit for OS X
> hosts. The limit was because the fixed RAM and ROM addresses were such that
> the RAM could only be 512 MB before it overlapped the ROM area.
>
>
> Impact
> ------
> The change to make ROMBase a variable is throughout all hosts & addressing
> modes.
>
> The RAM and ROM areas will only shift when run on Unix & OS X hosts,
> otherwise the same fixed allocation address is used as before.
>
> This change is limited to "Real" addressing mode. Unlike Basilisk II,
> SheepShaver *pre-calculates* the offset for "Direct" addressing mode; the
> offset is compiled into the program. If the RAM address were allowed to
> shift, it could result in the RAM area wrapping around address 0.
>
>
> Changes to main_unix.cpp
> ------------------------
> 1. Real addressing mode no longer defines a RAM_BASE constant.
>
> 2. The base address of the Mac ROM (ROMBase) is defined and exported by this
> program.
>
> 3. Memory management helper vm_mac_acquire is renamed to
> vm_mac_acquire_fixed. Added a new memory management helper vm_mac_acquire,
> which allocates memory at any address.
>
> 4. Changed and rearranged the allocation of RAM and ROM areas.
>
> Before it worked like this:
>
>   - Allocate ROM area
>   - If can, attempt to allocate RAM at address zero
>   - If RAM not allocated at 0, allocate at fixed address
>
> We still want to try allocating the RAM at zero, and if using DIRECT
> addressing we're still going to use the fixed addresses. So we don't know
> where the ROM should be until after we do the RAM. The new logic is:
>
>   - If can, attempt to allocate RAM at address zero
>   - If RAM not allocated at 0
>       if REAL addressing
>          allocate RAM and ROM together. The ROM address is aligned to a 1 MB
> boundary
>       else (direct addressing)
>          allocate RAM at fixed address
>   - If ROM hasn't been allocated yet, allocate at fixed address
>
> 5. Calculate ROMBase and ROMBaseHost based on where the ROM was loaded.
>
> 6. There is a crash if the RAM is allocated too high. To try and catch this,
> check if it was allocated higher than the kernel data address.
>
> 7. Change subsequent code from using constant ROM_BASE to variable ROMBase.
>
>
> Changes to Other Programs
> -------------------------
> emul_op.cpp, main.cpp, name_registery.cpp, rom_patches.cpp,
> rsrc_patches.cpp, emul_ppc.cpp, sheepshaver_glue.cpp, ppc-translate-cpp:
> Change from constant ROM_BASE to variable ROMBase.
>
> ppc_asm.S: It was setting register to a hard-coded literal address:
> 0x40b0d000. Changed to set it to ROMBase + 0x30d000.
>
> ppc_asm.tmpl: It defined a macro ASM_LO16 but it assumed that the macro
> would always be used with operands that included a register specification.
> This is not true. Moved the register specification from the macro to the
> macro invocations.
>
> main_beos.cpp, main_windows.cpp: Since the subprograms are all expecting a
> variable ROMBase, all the main_*.cpp pgrams have to define and export it.
> The ROM_BASE constant is moved here for consistency. The mains for beos and
> windows just allocate the ROM at the same fixed address as before, set
> ROMBaseHost and ROMBase to that address, and then use ROMBase for the
> subsequent code.
>
> cpu_emulation.h: removed ROM_BASE constant. This value is moved to the
> main_*.cpp modules, to be consistent with RAM_BASE.
>
> user_strings_unix.cpp, user_strings_unix.h: Added new error messages related
> to errors that occur when the RAM and ROM are allocated anywhere.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>