I've had some success building ocaml with USE=ocamlopt on an gentoo armv5 system (open-rd). I've reported the bugs that previously prevented this upstream, and thought I would bring my findings to the attention of the gentoo devs, who may wish to unmask ocaml-3.12.0 and remove the masking of the ocamlopt flag from /usr/portage/profiles/arch/arm/use.mask I wanted an ocamlopt build of mldonkey in order to run mldonkey on my home router - without ocamlopt, it was too slow. The problem that I reported upstream is that vanilla linux kernels (and gentoo-sources) kernels do not deliver a SIGBUS on misaligned memory accesses on arm unless configured to do so by writing to /proc/cpu/alignment. Nevertheless, on arm systems, misaligned accesses are not possible, and will result in garbage. Beta versions of ocaml 3.12 (and all ealier versions) try to detect whether misaligned accesses are possible on a system by provoking a SIGBUS at configure time. On an unconfigured arm linux system, this results in ocaml incorrectly configuring itself to compile code that performs misaligned accesses. The solution I took was to "echo 4>/proc/cpu/alignment" *before* emerging ocaml (after unmasking ocaml 0.12.0_beta1 and unmasking the ocamlopt USE flag). This causes linux to send SIGBUS, as is normal on other architectures that are alignment sensitive. After ocaml is emerged, the /proc/cpu/alignment setting does not matter. I also advised the maintainers of ocaml to change the method by which they detect alignment sensitivity. (Which they may have done in 0.12.0 - I have not had a chance to check). I also removed the line: # Fails to build on arm if >O0 is used use arm && replace-flags "-O?" -O0 from the ocaml ebuild without problems. I suspect that the problem this was intended to solve is related to the alignment issues, and perhaps to older gcc versions. I suggest: 1. That it is desirable to unmask ocaml-0.12.0 and USE=ocamlopt, and remove the filtering of the -O2 flag. Performance of ocaml apps on arm is very poor without these. ocamlopt will not work on arm with versions of ocaml <3.12 (for reasons having to do with floating point instructions and gnueabi), so getting 3.12 unmasked is a prequisite for unmasking USE=ocamlopt. 2. That gentoo-sources be patched to default to delivering SIGBUS to processes that perform misaligned accesses on arm. (Making the behaviour of the linux kernel on arm like that on e.g. sparc). This would make it easier to detect problems like this. 3. That if that's not feasible, then ocaml be patched to ensure that it correctly detects the impossibility of misaligned accesses on arm. (It may be that a patch is not necessary on 0.12.0 - as I mentioned above, I was working with a beta version, and have not had a chance to look at the latest release). If such a patch would like likely to lead to the unmasking of ocaml-0.12.0 I would be happy to contribute one.
(In reply to comment #0) > I also removed the line: > > # Fails to build on arm if >O0 is used > use arm && replace-flags "-O?" -O0 This was added without any bug for reference, the arm team can clean this (and I may drop it randomly when I want to cleanup ebuilds when bumping them). > 1. That it is desirable to unmask ocaml-0.12.0 and USE=ocamlopt, and remove the > filtering of the -O2 flag. Performance of ocaml apps on arm is very poor > without these. ocamlopt will not work on arm with versions of ocaml <3.12 (for > reasons having to do with floating point instructions and gnueabi), so getting > 3.12 unmasked is a prequisite for unmasking USE=ocamlopt. ocamlopt can be unmasked for ocaml-3.12 only and, when it goes stable, globally. > 2. That gentoo-sources be patched to default to delivering SIGBUS to processes > that perform misaligned accesses on arm. (Making the behaviour of the linux > kernel on arm like that on e.g. sparc). This would make it easier to detect > problems like this. Not sure if its a good idea; aren't there some arm boxes where unaligned accesses are allowed but very slow ? > 3. That if that's not feasible, then ocaml be patched to ensure that it > correctly detects the impossibility of misaligned accesses on arm. (It may be > that a patch is not necessary on 0.12.0 - as I mentioned above, I was working > with a beta version, and have not had a chance to look at the latest release). > If such a patch would like likely to lead to the unmasking of ocaml-0.12.0 I > would be happy to contribute one. Please try with 3.12.0; if it doesn't work, please report it upstream and add a link here. If there is no way to detect alignment, maybe adding a configure option to force said alignment can be added.
Sorry about the delay. I can report that ocaml 3.12.0 builds correctly and is able to correctly build other apps with USE=ocamlopt; no tinkering with /proc/cpu/alignment is needed. Also, the line of the ocaml-3.12.0 ebuild that forces -O0 on arm is not needed, and harms performance. ocaml builds correctly without this line. Suggest that: 1. this line be removed from the ebuild; 2. USE=ocamlopt be unmasked on arm w/ ocaml-3.12.0. I also suggest that ocaml-3.12.0 be stablised on arm soon after these changes are made if possible. Without ocamlopt, ml programmes are in some cases unusably slow.
Confirmed Josh's proposal. I would +1 for this. The mask and ebuild changes are done by armin76 in Apr 2010 with ocaml-3.11. It seems that the problem on arm is fixed since 3.12. > 19 Apr 2010; Raúl Porcel <armin76@gentoo.org> ocaml-3.10.2.ebuild, > ocaml-3.11.2.ebuild: > Force -O0 on arm
i'll have a look
ping. @armin76, let me just apply it if you don't have time, it is tested afterall.
(In reply to comment #5) > ping. @armin76, let me just apply it if you don't have time, it is tested > afterall. go ahead
done. RCS file: /var/cvsroot/gentoo-x86/profiles/arch/arm/ChangeLog,v retrieving revision 1.155 diff -r1.155 ChangeLog 4a5,7 > 15 May 2012; Benda Xu <heroxbd@gentoo.org> use.mask: > unmask ocamlopt on arm, as per bug 340607. Thanks to Josh Parsons + 15 May 2012; Benda Xu <heroxbd@gentoo.org> ocaml-3.12.1.ebuild: + on arm, use user -O flags instead of hard coding -O0, as per bug 340607. + Thanks to Josh Parsons for investigating the issue.
