Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
vicuna opened this issue Aug 18, 2017 · 10 comments
Open

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

vicuna opened this issue Aug 18, 2017 · 10 comments
Assignees
Labels

Comments

@vicuna
Copy link

@vicuna vicuna commented Aug 18, 2017

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Aug 18, 2017

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
Copy link
Author

@vicuna vicuna commented Sep 30, 2017

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
Copy link
Author

@vicuna vicuna commented Sep 30, 2017

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
Copy link
Author

@vicuna vicuna commented Oct 12, 2017

Comment author: @dbuenzli

It seems the error persists in 4.06.0

See mirage/ocaml-uri#106 (comment)

@vicuna
Copy link
Author

@vicuna vicuna commented Oct 12, 2017

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
Copy link
Author

@vicuna vicuna commented Oct 12, 2017

Comment author: @xavierleroy

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

@vicuna
Copy link
Author

@vicuna vicuna commented Oct 13, 2017

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
Copy link
Author

@vicuna vicuna commented Oct 14, 2017

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
Copy link
Author

@vicuna vicuna commented Jan 12, 2018

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
Copy link
Author

@vicuna vicuna commented Jan 12, 2018

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.

@vicuna vicuna added the back-end label Mar 14, 2019
@vicuna vicuna added this to the 4.07.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
@xavierleroy xavierleroy removed this from the 4.07.0 milestone Apr 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants