On Sat, Nov 24, 2018 at 12:24:59PM +0000, Stuart Henderson wrote:
> On 2018/11/24 13:20, Otto Moerbeek wrote:
> > On Sat, Nov 24, 2018 at 12:01:48PM +0000, Stuart Henderson wrote:
> >
> > > On 2018/11/24 09:45, Landry Breuil wrote:
> > > > On Sat, Nov 24, 2018 at 07:54:36AM +0100, Otto Moerbeek wrote:
> > > > > On Wed, Nov 21, 2018 at 01:19:27PM +0100, Otto Moerbeek wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am playing with boost contexts which is configured out by the
> > > > > > current port.
> > > > > > I am able to make execution_context and fcontext work on amd64. The
> > > > > > first
> > > > > > using a simple test program and the second using a non-trival
> > > > > > program.
> > > > > >
> > > > > > The only actual change in boost itself is to use a mmap(...
> > > > > > MMAP_STACK ...) for stack allocation. So I like to enable the
> > > > > > disabled parts. They are not extensivly tested and some other parts
> > > > > > might need a patch too (there are several classes creating stacks).
> > > > > >
> > > > > > At the moment I just like to know if I am taking the right approach
> > > > > > port-wise. So, any comments or advise?
> > > > >
> > > > > Total silence.... remember I'm a total ports newbie, I really could
> > > > > use some guidance here. Is this the right approach for a port having
> > > > > arch specific features and plist?
> > > >
> > > > That is the right approach in general, but for a leaf port. Here, lots
> > > > of other ports depend on boost, and stuff might pick up those new libs
> > > > on amd64 (or updates/new ports start relying on them), and then the same
> > > > stuff start breaking in subtle ways on other archs (few ppl cares
> > > > about).
> > >
> > > Yes exactly this... The approach would need to be :
> > >
> > > build dependent ports (130-odd, many large/slow)
> > >
> > > run "check-lib-depends" on the produced packages, see if the new libraries
> > > are picked up
> > >
> > > if so, add arch-dependent bits to add the relevant libraries to WANTLIB
> > >
> > > (and as they're not extensively tested, alert people to the ports which
> > > have picked this up and request further testing of these)
> > >
> > > Additionally we need to watch imports/updates of ports using boost in the
> > > future to see if they start using these libraries otherwise builds will
> > > break (it's not so bad if it's amd64-only, but if all the "fast" arches
> > > gain support, we typically don't discover breakage in this form until
> > > it's time for release builds when it's too late to fix).
> > >
> > > So the question is "is it worth it". Could be - this is a path to running
> > > some software (pdns-recursor comes to mind) which otherwise won't run on
> > > OpenBSD because we never got support for the ucontext.h functions ..
> > >
> >
> > pdns-recursor is the cause I'm looking into this. ucontext is not only
> > deprecated but actually removed by posix, I do not want to go that
> > road. So boost's fcontext remains and it is working properly on amd64
> > at least.
> >
> > I could maybe go a more conservative approach and only enable boosts's
> > context lib. That's all I need, and the scope of potential breakage
> > will be more limited.
> >
> > But first next step is building and basic tests on i386 and sparc64.
>
> If you get i386 working, once we're done with LLD test builds on
> i386, I can help with bulk builds and WANTLIB checks there.
>
Hmm, i386 builds but my trivial test program core dumps in
jump_fcontext(). It looks like the stack context created by
make_fcontext() isn't right on OpenBSD (or handled incorrectly by
jump_fcontext()). Pondering now wether to spend time on this. Both
functions are written in assemby and I never learnt i386 assembly.
-Otto
