Re: [Boost-users] [Context] Building 32-bit Context?

Subject: Re: [Boost-users] [Context] Building 32-bit Context?
From: Nat Linden (nat_at_[hidden])
Date: 2012-09-21 10:06:04

On Thu, Sep 20, 2012 at 4:52 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]> wrote:

> Am 20.09.2012 22:23, schrieb Nat Linden:

>> I need to build a 32-bit Context library even on a 64-bit build
>> machine. Is this possible?

> yes - it should, unfortunately 1.51.0 contains an error for 32bit Mac OSX.
> Could you try the trunk or release branch from svn (32bit and 64bit)?

I checked out the Subversion trunk. This command:

./b2 toolset=darwin address-model=32 architecture=x86 variant=release
link=static stage

produces these errors:

Jamfile</Users/nat/boost-trunk/libs/context/build>.gas
bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/make_i386_sysv_macho_gas.o
libs/context/src/asm/make_i386_sysv_macho_gas.S:38:suffix or operands
invalid for `push'
libs/context/src/asm/make_i386_sysv_macho_gas.S:62:suffix or operands
invalid for `pop'
libs/context/src/asm/make_i386_sysv_macho_gas.S:68:suffix or operands
invalid for `pop'

    as -o "bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/make_i386_sysv_macho_gas.o"
"libs/context/src/asm/make_i386_sysv_macho_gas.S"

Jamfile</Users/nat/boost-trunk/libs/context/build>.gas
bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/jump_i386_sysv_macho_gas.o
libs/context/src/asm/jump_i386_sysv_macho_gas.S:70:suffix or operands
invalid for `jmp'

    as -o "bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/jump_i386_sysv_macho_gas.o"
"libs/context/src/asm/jump_i386_sysv_macho_gas.S"

My colleague found that if we execute the above 'as' commands, adding
'-arch i386', they each succeed:
as -arch i386 -o
"bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/make_i386_sysv_macho_gas.o"
"libs/context/src/asm/make_i386_sysv_macho_gas.S"
as -arch i386 -o
"bin.v2/libs/context/build/darwin-4.2.1/release/address-model-32/architecture-x86/link-static/threading-multi/asm/jump_i386_sysv_macho_gas.o"
"libs/context/src/asm/jump_i386_sysv_macho_gas.S"

So perhaps there's a Jamfile error somewhere.

Once those 'as' commands have succeeded, repeating the above './b2'
command succeeds as well, producing stage/lib/libboost_context.a.

With that library, I can compile and link the exit.cpp example.
However, it produces a segmentation fault:

cd libs/context/example
g++ -I ../../.. -L ../../../stage/lib -arch i386 -m32 -o exitprog
exit.cpp -lboost_context && ./exitprog
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return
/bin/bash: line 1:  3034 Segmentation fault: 11  ./exitprog

The name of the function in which the fault occurs is suggestive:

gdb exitprog
GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries ... done

(gdb) run
Starting program: /Users/nat/boost-trunk/libs/context/example/exitprog
Reading symbols for shared libraries ++......................... done
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
0x9afb9820 in misaligned_stack_error_ ()
(gdb) where
#0  0x9afb9820 in misaligned_stack_error_ ()
#1  0xac435d70 in std::wclog ()
(gdb)

Is there something we could/should be doing to avoid
"misaligned_stack_error_()" ?