Boost C++ Libraries: Ticket #9445: context asm files fail to build for x32 ABIs

olli — Sat, 30 Nov 2013 21:43:47 GMT

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 — Sat, 30 Nov 2013 22:19:43 GMT

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 — Sat, 30 Nov 2013 23:01:09 GMT

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).

Sun, 01 Dec 2013 05:29:17 GMT

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 ...

status changed; resolution set

olli — Sun, 01 Dec 2013 08:22:20 GMT

status new → closed
resolution → invalid

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

Sun, 01 Dec 2013 20:32:29 GMT

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 — Sun, 01 Dec 2013 21:37:16 GMT

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

status changed; resolution deleted

Mon, 02 Dec 2013 08:13:47 GMT

status closed → reopened
resolution invalid

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.

attachment set

Mon, 02 Dec 2013 08:14:41 GMT

attachment → boost-x32-context.patch

x32 support for context module

Mon, 02 Dec 2013 08:24:57 GMT

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 — Mon, 02 Dec 2013 08:50:49 GMT

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 — Mon, 02 Dec 2013 08:55:08 GMT

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.

Mon, 02 Dec 2013 09:18:21 GMT

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 — Mon, 02 Dec 2013 09:50:28 GMT

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

Mon, 02 Dec 2013 20:08:22 GMT

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.

status changed; resolution set

olli — Sun, 08 Dec 2013 12:12:45 GMT

status reopened → closed
resolution → fixed

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 — Mon, 09 Dec 2013 18:21:25 GMT

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@… — Fri, 26 Feb 2016 13:09:35 GMT

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 — Fri, 26 Feb 2016 16:09:16 GMT

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@… — Fri, 26 Feb 2016 18:13:55 GMT

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 — Fri, 26 Feb 2016 19:36:27 GMT

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@… — Fri, 26 Feb 2016 20:05:07 GMT

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

olli — Fri, 26 Feb 2016 21:16:50 GMT

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@… — Fri, 26 Feb 2016 22:02:46 GMT

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

olli — Sat, 27 Feb 2016 08:12:14 GMT

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@… — Sat, 27 Feb 2016 12:08:05 GMT

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 — Sat, 27 Feb 2016 20:52:32 GMT

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 — Sun, 28 Feb 2016 11:39:17 GMT

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 — Sun, 28 Feb 2016 12:05:24 GMT

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 — Sun, 28 Feb 2016 12:05:53 GMT

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@… — Mon, 29 Feb 2016 08:29:41 GMT

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 — Tue, 29 May 2018 06:48:50 GMT

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"