Re: [boost] [context review] Several Questions

Subject: Re: [boost] [context review] Several Questions
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-03-22 01:04:54

> could you please so kind to get my working  tree?

> 
> git clone git://git.gitorious.org/boost-dev/boost-dev.git
> 
> It  would help that we are using the same code basis.
> 

Ok, I can take a look on this, but see notes below.

> >>>        Building boost_context:
> >>>
> >>>       bjam toolset=gcc  context-impl=asm  architecture=x86
> >> instruction-set=native
> >>>    address-model=64 --with-context
> >>>            variant=release stage
> >> which platform i386? Into the  documention I provide  for all the platforms
> >> (arm, i386,  x86_64, mips, ppc) the bjam-options you have  to used.
> >> - for  x86 64bit: bjam toolset=gcc architecture=x86   
>instruction-set=yorksfield
> >> address-model=64  context-impl=asm
> >>
> >>>       Then I compile  example link.cpp
> >>>
> >>>      Run   it
> >>>
> >>>      It  crashes!
> >>>
> >> not in my  test
> >>
> >  Unfortunately it is not so good answer :-)
>
> ;-) I'm a little bit surprised  because it worked and I tried it on 
> several intel computers. But I've an  idea because if I use your 
> cammandline buildinglink.cpp I get an segfault  too.
> 
> g++ -g link.cpp -I /opt/boost/include/ -L /opt/boost/lib/ 
> -Wl,-rpath=/opt/boost/lib -lboost_context -lrt
> segfault at get_fcontext  ()
> 
> 
> This is because you are missing -fPIC option. On x86_64 the code  is 
> build position independent.
>

I'm not missing -fPIC option. -fPIC is used only for 
building shared object, you don't use it for executables!

I don't know why bjam adds it for executables. It is plane
wrong (harmless but wrong). No other mature build systems
like CMake or autotools does this.

In the real world users would not use bjam and would
not compile their executables with -fPIC as it is not
required.

 
> g++ -g link.cpp -I /opt/boost/include/  -L /opt/boost/lib/ 
> -Wl,-rpath=/opt/boost/lib -lboost_context -lrt  -fPIC
> -> works
> 
> I think it is better to build the examples with  bjam. That means:
> 

No, I should build libraries with bjam, but by no means,
any code I write should be build with it. :-)

> 1.) got to  <boost-root>/libs/context/examples
> 2.) compile the examples: bjam  toolset=gcc architecture=x86 
> instruction-set=native address-model=64  context-impl=asm
> 3.) test the examples in 
><boost-root>/bin.v2/libs/context/example/gcc-4.4.5/release/address-model-64/architecture-x86/context-impl-asm/instruction-set-native/link-static/
>/
> or  if Jamvile.v2 was modified to use link against shared lib  (<link>shared)
><boost-root>/bin.v2/libs/context/example/gcc-4.4.5/release/address-model-64/architecture-x86/context-impl-asm/instruction-set-native/
>/
> 
> 
> >>  Do mean why you can specify to use the context swapping provided  by  the
> >> Operating System or the assembler code (==fcontext)?
> > I  mean something like
> >
> > boost::context<>  // some  default
> > boost::ucontext<>
> >  boost::fcontext<>
> >
> > So you can have two implementations in  same code.
> >
> 
> This is a option too - my previous intention was to  hide this for the 
> user. At the time the boost-libs are compiled the user  decides if it 
> wants the fast version or the UNIX signal safe version.
> It  is also hard to provide boost:.fcontext<> for all platforms - for 
> instance on MIPS I would have to implement 4 version of fcontext 
> (because of the multiple MIPS  ABIs).
> 

You can always fall-back to ucontext if assembly version is not provided.

I think it would be very useful. Because different parts of program
may required different contexts and inability to use two of them
in same executable is quite problematic.

Artyom