OCaml-uri doesn't compile on ARM with assembler error #7608

vicuna · 2017-08-18T11:23:58Z

Original bug ID: 7608
Reporter: SP
Assigned to: @xavierleroy
Status: assigned (set by @xavierleroy on 2017-10-13T13:03:53Z)
Resolution: open
Priority: normal
Severity: minor
Platform: ARM
OS: Archlinux
Target version: 4.07.0+dev/beta2/rc1/rc2
Category: back end (clambda to assembly)
Monitored by: @gasche

Bug description

I have the following compilation error with another ARM chip.

A key part seems to be this:

/tmp/camlasm480e0c.s: Assembler messages:
/tmp/camlasm480e0c.s:52: Error: value of 68249 too large for field of 2 bytes at 30
/tmp/camlasm480e0c.s:73426: Error: value of 68255 too large for field of 2 bytes at 204542

Log file cropped to relevant section:

File "lib/uri.ml", line 306, characters 33-50:
Warning 52: Code should not depend on the actual values of
this constructor's arguments. They are only for information
and may change in future versions. (See manual section 8.5)
File "lib/uri.ml", line 321, characters 27-44:
Warning 52: Code should not depend on the actual values of
this constructor's arguments. They are only for information
and may change in future versions. (See manual section 8.5)
File "lib/uri.ml", line 568, characters 17-33:
Warning 3: deprecated: String.lowercase
Use String.lowercase_ascii instead.
    ocamlopt lib/uri_top.{cmx,o}
File "_none_", line 1:
Warning 58: no cmx file was found in path for module Toploop, and its interface was not compiled with -opaque
    ocamlopt etc/uri_services.{cmx,o}
    ocamlopt lib/uri.{a,cmxa}
    ocamlopt lib/uri_top.{a,cmxa}
    ocamlopt etc/uri_services.{a,cmxa}
    ocamlopt lib/uri.cmxs
    ocamlopt lib/uri_top.cmxs
    ocamlopt etc/uri_services.cmxs
      ocamlc etc/uri_services_full.{cmo,cmt}
      ocamlc etc/uri_services_full.cma
    ocamlopt etc/uri_services_full.{cmx,o} (exit 2)
(cd _build/default && /usr/bin/ocamlopt.opt -w -40 -g -I /home/fox/.opam/system/lib/bytes -I /home/fox/.opam/system/lib/re -I /home/fox/.opam/system/lib/sexplib -I /home/fox/.opam/system/lib/sexplib/0 -I /home/fox/.opam/system/lib/stringext -I /usr/lib/ocaml -I lib -no-alias-deps -I etc -o etc/uri_services_full.cmx -c -impl etc/uri_services_full.ml)
/tmp/camlasm480e0c.s: Assembler messages:
/tmp/camlasm480e0c.s:52: Error: value of 68249 too large for field of 2 bytes at 30
/tmp/camlasm480e0c.s:73426: Error: value of 68255 too large for field of 2 bytes at 204542
/tmp/camlasm480e0c.s:148307: Error: offset out of range
/tmp/camlasm480e0c.s:188181: Error: offset out of range
/tmp/camlasm480e0c.s:148267: Error: offset out of range
/tmp/camlasm480e0c.s:148274: Error: offset out of range
/tmp/camlasm480e0c.s:148295: Error: offset out of range
/tmp/camlasm480e0c.s:148299: Error: offset out of range
/tmp/camlasm480e0c.s:148303: Error: offset out of range
/tmp/camlasm480e0c.s:148320: Error: offset out of range
/tmp/camlasm480e0c.s:188141: Error: offset out of range
/tmp/camlasm480e0c.s:188148: Error: offset out of range
/tmp/camlasm480e0c.s:188169: Error: offset out of range
/tmp/camlasm480e0c.s:188173: Error: offset out of range
/tmp/camlasm480e0c.s:188177: Error: offset out of range
/tmp/camlasm480e0c.s:188194: Error: offset out of range
File "etc/uri_services_full.ml", line 1:
Error: Assembler error, input left in file /tmp/camlasm480e0c.s

Related issue on ocaml-uri: mirage/ocaml-uri#106

Steps to reproduce

Build ocaml-uri on ARM.

The text was updated successfully, but these errors were encountered:

vicuna · 2017-08-18T13:52:00Z

Comment author: @gasche

There have been several fixes to ARM code generation in trunk (4.06.0+dev). Would it be reasonable to make sure that ocaml-uri and its various dependencies compile under the trunk to check if the problem goes away?

I know it is work (I expect the ocaml-uri people or its users to do it), but it will have to be done before the 4.06 release anyway so it will not be lost.

vicuna · 2017-09-30T19:18:27Z

Comment author: SP

Tried installing uri on 4.06.0+trunk, but there are too many dependencies which require ocaml < 4.06. Any suggestions about this?

vicuna · 2017-09-30T20:45:15Z

Comment author: @gasche

We are going to make a beta release of 4.06.0 very soon. That will be a very good time to kindly ask the maintainers of uri's dependencies to test their build under 4.06 and release working versions, so that you can test yourself. If you manage to test uri before the release, and it is still broken (I believe it should now work), we can add the issue to the list of things to fix before the release.

vicuna · 2017-10-12T15:37:14Z

Comment author: @dbuenzli

It seems the error persists in 4.06.0

See mirage/ocaml-uri#106 (comment)

vicuna · 2017-10-12T16:09:14Z

Comment author: @gasche

(I'm including here the information reported by github user 'alrev' in the downstream issue report.)

The error was reproduced on Raspberry 2 and 3, and a Cubietruck machine. (armv7l-unknown-linux-gnueabihf).

From the switch 4.06.0+beta1+default-unsafe-string, the failure can be reproduced by installing the development version of the dependencies:

opam pin add ppx_core --dev-repo
opam pin add ppx_sexp_conv --dev-repo

and then compiling the source of the project (this is the hash of the current master):

https://github.com/mirage/ocaml-uri/archive/a0846a1def8abdade6578719f7236aae9445f2d4.tar.gz

vicuna · 2017-10-12T17:50:56Z

Comment author: @xavierleroy

Any chance to have a self-contained repro case? Or just a copy of the problematic .s file?

vicuna · 2017-10-13T13:03:35Z

Comment author: @xavierleroy

At last we got a copy of the bad .s file: https://github.com/mirage/ocaml-uri/files/1381922/camlasmbaf612.s_plus_err_and_env.zip

Two overflows remain, on lines 52 and 73429, and correspond to tbh instructions (branch through table) where the branch destinations are far away and overflow the 16-bit displacements used by the tbh instruction. In turn, this comes from two huge pattern-matchings in the source code, autogenerated from a large data table.

The other "offset out of range" overflows do not occur on this version of the .s file. I think these overflows were fixed by commit 07b28ed in 4.06.

The fix I'll propose soon is to stop using the Thumb-2 tbh instruction and fall back to the classic ARM implementation of jump through table.

vicuna · 2017-10-14T10:08:59Z

Comment author: @xavierleroy

The fix I had in mind needs significant preliminary work:

Switch the ARM code emitter to "unified" syntax instead of the "legacy" syntax used today. (The fix needs the "b.w" opcode to denote a 32-bit-encoded Thumb2 unconditional branch, and this opcode is not supported by GNU as in "legacy" syntax.)
Add a "destroyed_at_switch" architectural parameter for all architectures. (Because a temporary register is needed for the Thumb version of the fix.)

I'm pushing this issue after release 4.06. In the meantime, the one package that has problems can be compiled with "ocamlopt -fno-thumb", or rewritten to avoid such huge functions.

vicuna · 2018-01-12T16:14:41Z

Comment author: @avsm

In the meantime, the one package that has problems can be compiled with "ocamlopt -fno-thumb", or rewritten to avoid such huge functions.

Uri 1.9.6 has now been released and rewritten to avoid such huge functions, so this isn't blocking us in opam land.

https://discuss.ocaml.org/t/uri-1-9-6-available-with-improved-arm-support-and-build-times/1420

vicuna · 2018-01-12T18:46:56Z

Comment author: @xavierleroy

Great, that's a happy end for this story.

In the meantime I looked into changing the ARM Thumb code generator to avoid the issue. It's less work than I thought (the "unified" syntax is already used!) but the TBH-free code is measurably slower. How much this performance degradation matters is not clear to me yet. I'll try to make better measurements and submit the whole thing as a GPR.

github-actions · 2021-04-21T04:27:19Z

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

vicuna added the back-end label Mar 14, 2019

vicuna added this to the 4.07.0 milestone Mar 14, 2019

vicuna assigned xavierleroy Mar 14, 2019

vicuna added the bug label Mar 20, 2019

xavierleroy removed this from the 4.07.0 milestone Apr 15, 2020

github-actions bot added the Stale label Apr 21, 2021

github-actions bot closed this as completed May 21, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OCaml-uri doesn't compile on ARM with assembler error #7608

OCaml-uri doesn't compile on ARM with assembler error #7608

vicuna commented Aug 18, 2017

vicuna commented Aug 18, 2017

vicuna commented Sep 30, 2017

vicuna commented Sep 30, 2017

vicuna commented Oct 12, 2017

vicuna commented Oct 12, 2017

vicuna commented Oct 12, 2017

vicuna commented Oct 13, 2017

vicuna commented Oct 14, 2017

vicuna commented Jan 12, 2018

vicuna commented Jan 12, 2018

github-actions bot commented Apr 21, 2021