context asm files fail to build for x32 ABIs

[Mike Frysinger <vapier@…>]

building boost on x32 systems does:

Performing configuration checks

    - 32-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes
...

Component configuration:

    - atomic                   : building
    - chrono                   : building
    - context                  : not building
...

but it still tries to build the context code anyways and fails:

"x86_64-pc-linux-gnux32-g++" -x assembler-with-cpp -finline-functions \
 -Wno-inline -Wall -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 \
 -DBOOST_CONTEXT_SOURCE -DNDEBUG -I"." -c -o \
  "bin.v2/libs/context/build/gcc-4.8/gentoorelease/pch-off/threading-multi/asm/jump_i386_sysv_elf_gas.o" \
 "libs/context/src/asm/jump_i386_sysv_elf_gas.S"

libs/context/src/asm/jump_i386_sysv_elf_gas.S: Assembler messages:
libs/context/src/asm/jump_i386_sysv_elf_gas.S:71: Error: operand type mismatch for `jmp'

this is because it's trying to build the i386 code instead of the x86_64 code

[olli]

You try to compile 32bit version of boost.context on a 64bit Linux as you see in the output: Performing configuration checks

• 32-bit : yes
• x86 : yes

The compiler your system chooses is "x86_64-pc-linux-gnux32-g++". And it seams that it tries to use 64bit GNUas instead of the 32bit GNUas which results in errors because jump_i386_sysv_elf_gas.S was chosen. You should check your environment if you expect to get 64bit code compiled but bjam selects 32bit. If you look at the test results at http://www.boost.org/development/tests/release/developer/context.html the tests pass.

[anonymous]

olli: x32 is an experimental architecture, separate from x86 and x86-64. See "X32_ABI" article in Wikipedia.

(Trying to include URL results in "Submission rejected as potential spam (External links in post found)".)

[olli]

Replying to anonymous:

olli: x32 is an experimental architecture, separate from x86 and x86-64. See "X32_ABI" article in Wikipedia.

OK, if its is not i386 (32bit SYSV ABI) then it is not supported (yet).

[Mike Frysinger <vapier@…>]

ok, but there doesn't seem to be a way to do a build w/out it. even though my summary said "context: not building", it still tried to build it.

as a quick hack, i changed the i386 file to include the x86_64 one when x86_64 is defined. it compiled. but i don't know if it works as i don't have a test case handy ...

[olli]

to disable building boost.context you have to apply --without-context --without-coroutine to bjam command line (because boost.coroutine depends on boost.context)

[Mike Frysinger <vapier@…>]

why was this closed as invalid ? other x32 bugs posted were (eventually) addressed. i've also posted a way forward here. if you don't want to fix the x32 bug, then wait for someone else to do so.

independently, the build system sounds broken if its display doesn't match reality.

[olli]

Replying to Mike Frysinger <vapier@…>:

why was this closed as invalid ? other x32 bugs posted were (eventually) addressed. i've also posted a way forward here. if you don't want to fix the x32 bug, then wait for someone else to do so.

because as you said, x32 is experimental and including x86_64 mnemonics into a i386 dedicated file is a dirty hack. a vaild fix would be providing assembler code for jump_fcontext/make_fcontext for x32/ABI.

independently, the build system sounds broken if its display doesn't match reality.

then add an bug for the build system, please

[Mike Frysinger <vapier@…>]

i never said x32 was experimental. it was released more than a year ago and is in shipping versions of packages (gcc/glibc/binutils/boost/etc...). closing bugs as invalid does not help anything.

i managed to get the test to run and even the existing x86_64 asm does not work. looking at bit more, it seems it's due to the asm encoding the sizes/offsets of the fields. it's not hard to fix.

[Mike Frysinger <vapier@…>]

x32 support for context module

[Mike Frysinger <vapier@…>]

there might be a cleaner way to handle the x86_64/x32 differences (mov vs movq), but this one passes the testcase included in the context subdir

[olli]

x32 has no priority - I'm dealign with ARM on iOS and Windows I can't provide implementations for each valid combination of architecture + ABI + OS + compiler-suite out there. So if x32 is important for you, you could provide an implementation? I've definitely not the time.

[olli]

Replying to Mike Frysinger <vapier@…>:

i never said x32 was experimental.

see comment 2:

-> olli: x32 is an experimental architecture, separate from x86 and x86-64.

[Mike Frysinger <vapier@…>]

Replying to olli:

So if x32 is important for you, you could provide an implementation?

i did -- see the attachment

Replying to olli:

Replying to Mike Frysinger <vapier@…>:

i never said x32 was experimental.

see comment 2:

-> olli: x32 is an experimental architecture, separate from x86 and x86-64.

and see the author. that isn't me. i'm not responsible for random things other people say.

[olli]

Replying to Mike Frysinger <vapier@…>:

Replying to olli:

So if x32 is important for you, you could provide an implementation?

i did -- see the attachment

it is not an acceptable patch because you patch a file which is intended for x86_64/SYSV ABI (as the name indicates jump_x86_64_sysv_elf_gas.S)

• required is an implementation for jump_fcontext/make_fcontext specialized for architecture + ABI + binary-format + assembler-tool
• entry in build/Jamfile.v2 for selecting the correct implementation

[Mike Frysinger <vapier@…>]

i've posted working assembly code for x32. what you speak of now is purely build issues. i've never written Jamfiles before, nor do i understand how boost puts things together when it comes to api/abi selection. seems like it makes more sense to have someone (e.g. you) who is an expert in the build system to do the build pieces.

[olli]

I believe your patch is not correct - after reading the x32 ABI it is clear that it uses the same calling conventions like SYSV/x86_64 (only pointers are 32bit instead of 64bit).

branch develop, commit f183534baa2d38cdca80787dffd112796a5bdd2f contains support for x32

[olli]

fix requires to apply abi=x32 at bjam commandline because boost.build has no idea about the ABI used on the platform and x32 is not the default ABI on x86_64/POSIX

[steve@…]

I'm working on Gentoo x32, as Mike was previously. We've been applying his hack for x32 support with boost for the last couple of years, it doesn't work any more, and that brought me here. I see in comment 15 correct support landed in the develop branch, but I've checked out the current git repository and it doesn't seem to exist at all!

[olli]

Replying to steve@…:

I'm working on Gentoo x32, as Mike was previously. We've been applying his hack for x32 support with boost for the last couple of years, it doesn't work any more, and that brought me here. I see in comment 15 correct support landed in the develop branch, but I've checked out the current git repository and it doesn't seem to exist at all!

The API has been changed - you could try the experimental support for X32 on branch develop (you need to specify b2-property abi=x32 at b2 cmdline)

[steve@…]

I've pull the git source as I mentioned but couldn't find the commit where it landed, and greping the source didn't reveal anything related to x32.

I've only tried building 1.58 so far, with abi=x32. That obviously didn't work. So I've been trying to reimplement the same behaviour with abi=x32.

I'll try the develop branch before I do any more work on this, but since I can find no reference to x32 I'd be surprised if it makes a difference!

[olli]

Replying to steve@…:

I've pull the git source as I mentioned but couldn't find the commit where it landed, and greping the source didn't reveal anything related to x32.

I've only tried building 1.58 so far, with abi=x32. That obviously didn't work. So I've been trying to reimplement the same behaviour with abi=x32.

I'll try the develop branch before I do any more work on this, but since I can find no reference to x32 I'd be surprised if it makes a difference!

search for commit-id 9f2584ea81d9f2d663fa7704fcaa87f06783662d in branch develop

[steve@…]

git show origin/develop 9f2584ea81d9f2d663fa7704fcaa87f06783662d fatal: bad object 9f2584ea81d9f2d663fa7704fcaa87f06783662d

[olli]

Replying to steve@…:

git show origin/develop 9f2584ea81d9f2d663fa7704fcaa87f06783662d fatal: bad object 9f2584ea81d9f2d663fa7704fcaa87f06783662d

​https://github.com/boostorg/context/commit/9f2584ea81d9f2d663fa7704fcaa87f06783662d works seams your local repo is broken

[steve@…]

Ah, I wasn't looking at the context submodule! I was in the main boost repository. Sorry for my confusion.

[olli]

Replying to steve@…:

Ah, I wasn't looking at the context submodule! I was in the main boost repository. Sorry for my confusion.

no problem, but could you tell me if it is working (keep in mind that the API of fcontext has been changed)

[steve@…]

Before I get started, and unless this has changed in the develop branch, I wonder if there's some way to turn off the automatic -march and -m[32|64] selection? I have been trying to understand how this all works, but it doesn't make sense to me why the build system should override the default or user specified settings.

This is similar to the LTO issue (I need to provide more data for), but of course much more critical since -m32 results in building for the IA32 ISA instead of x32!

[anonymous]

I've tried building boost from the develop branch. Pretty much as I expected:

gcc.jam sets -m32 if a 32bit platform is detected. This isn't appropriate for x32, since as I mentioned previously -m32 specifies IA32. -mx32 is used for x32. Or simply no -m since it's the toolchain default. [Why does boost set it anyway? Virtually every other project obeys whatever ABI is set by compiler/cflags, and detects the properties based upon the compiler output]

boost-build adds -march=i686 to the cflags for building on 32bit x86 platform, this is incompatible with x32 since x32 is an x86-64 variant ABI. It fails with "error: CPU you selected does not support x86-64 instruction set" [As above, why does boost set -march? The only time a specific -march is necessary to allow use of flags such as -mavx is when that instruction set flag is not allowed for the configured -march, if there's no -march, the compiler produces code for the default and or generic configured target (x86-64 on amd64/em64t), then all -m instruction extension flags are allowed.]

I'll see if I can remove the -march/ABI overrides and get it to build...

[anonymous]

With my changes, I'm now able to build boost-1.58 again, I back-ported the x32 patch and it seems to have built fine. I have tried the develop branch from git, but I'm hitting a probably unrelated problem:

./boost/python/slice.hpp:122:36: error: ‘distance’ is not a member of ‘boost::detail’

[olli]

Replying to anonymous:

With my changes, I'm now able to build boost-1.58 again, I back-ported the x32 patch and it seems to have built fine. I have tried the develop branch from git, but I'm hitting a probably unrelated problem:

./boost/python/slice.hpp:122:36: error: ‘distance’ is not a member of ‘boost::detail’

no idea - seams unrelated to boost.context

[olli]

Replying to anonymous:

I've tried building boost from the develop branch. Pretty much as I expected:

gcc.jam sets -m32 if a 32bit platform is detected. This isn't appropriate for x32, since as I mentioned previously -m32 specifies IA32. -mx32 is used for x32. Or simply no -m since it's the toolchain default. [Why does boost set it anyway? Virtually every other project obeys whatever ABI is set by compiler/cflags, and detects the properties based upon the compiler output]

boost-build adds -march=i686 to the cflags for building on 32bit x86 platform, this is incompatible with x32 since x32 is an x86-64 variant ABI. It fails with "error: CPU you selected does not support x86-64 instruction set" [As above, why does boost set -march? The only time a specific -march is necessary to allow use of flags such as -mavx is when that instruction set flag is not allowed for the configured -march, if there's no -march, the compiler produces code for the default and or generic configured target (x86-64 on amd64/em64t), then all -m instruction extension flags are allowed.]

I'll see if I can remove the -march/ABI overrides and get it to build...

you could try address-model=64 on b2 cmdline

[steve@…]

Replying to olli:

Replying to anonymous:

I've tried building boost from the develop branch. Pretty much as I expected:

gcc.jam sets -m32 if a 32bit platform is detected. This isn't appropriate for x32, since as I mentioned previously -m32 specifies IA32. -mx32 is used for x32. Or simply no -m since it's the toolchain default. [Why does boost set it anyway? Virtually every other project obeys whatever ABI is set by compiler/cflags, and detects the properties based upon the compiler output]

boost-build adds -march=i686 to the cflags for building on 32bit x86 platform, this is incompatible with x32 since x32 is an x86-64 variant ABI. It fails with "error: CPU you selected does not support x86-64 instruction set" [As above, why does boost set -march? The only time a specific -march is necessary to allow use of flags such as -mavx is when that instruction set flag is not allowed for the configured -march, if there's no -march, the compiler produces code for the default and or generic configured target (x86-64 on amd64/em64t), then all -m instruction extension flags are allowed.]

I'll see if I can remove the -march/ABI overrides and get it to build...

you could try address-model=64 on b2 cmdline

The problem is, it's neither -m32 or -m64, which address-model selects in gcc.jam:

if $(model) = 32 {

option = -m32 ;

} else if $(model) = 64 {

option = -m64 ;

}

The correct flag for x32 is -mx32, or the toolchain default on an x32 system. I still don't really understand why boost-build is setting these flags at all, perhaps it's something we'll just have to live with patching in our eclass? So for now, that's what I've done, along with removing the -march flags, so that our C(XX)FLAGS can provide them. [which is the Gentoo way]

This has allowed me emerge a multilib (x32-abi, ia32, amd64) boost while respecting the global CFLAGS.

[anonymous]

Is there a way to hidden the assembler file in the exported symbols of libboost_context.so?

In my env, readelf --wide --symbols /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0

42: 0000000000000000 0 FILE LOCAL DEFAULT ABS /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/asm/make_x86_64_sysv_elf_gas.o

I don't want the make_x86_64_sysv_elf_gas.o line exist in the output of "readelf --wide --symbols /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0"