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

labltk native code build problem on arm. #2734

Closed
vicuna opened this issue Mar 28, 2001 · 6 comments
Closed

labltk native code build problem on arm. #2734

vicuna opened this issue Mar 28, 2001 · 6 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Mar 28, 2001

Original bug ID: 327
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello, ...

While packaging ocaml 3.01 for debian, i received the following bug report
from the arm porters.

luther@medusa:/ocaml-3.01/otherlibs/labltk$ uname -a
Linu@ medusa 2.2.13 #334 Wed Dec 29 04:49:54 GMT 1999 armv3l unknown
luther@medusa:
/ocaml-3.01/otherlibs/labltk$ dpkg -l binutils gcc libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii binutils 2.10.91.0.2-1 The GNU assembler, linker and binary utiliti
ii gcc 2.95.3-5 The GNU C compiler.
ii libc6 2.2.2-1 GNU C Library: Shared libraries and Timezone
...
ii tcl8.0 8.0.5-5 The Tool Command Language (TCL) v8.0 - Run-T
ii tcl8.0-dev 8.0.5-5 The Tool Command Language (TCL) v8.0 - Devel
ii tcl8.2 8.2.3-5 The Tool Command Language (TCL) v8.2 - Run-T
ii tcl8.3 8.3.2-5 The Tool Command Language (TCL) v8.3 - Run-T
ii tk8.0 8.0.5-7 The Tk toolkit for TCL and X11 v8.0 - Run-Ti
ii tk8.0-dev 8.0.5-7 The Tk toolkit for TCL and X11 v8.0 - Develo
luther@medusa:~/ocaml-3.01/otherlibs/labltk$ make allopt
cd support; make opt
make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/support' make[1]: Nothing to be done for opt'.
make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/support' cd lib; make -f Makefile.gen; make opt make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make[1]: Nothing to be done for all'. make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/lib' ../../../boot/ocamlrun ../../../ocamlopt -I ../../../stdlib -labels -c -I ../sup port tk.ml /tmp/camlasm0.s: Assembler messages: /tmp/camlasm0.s:26142: Error: Invalid constant /tmp/camlasm0.s:30129: Error: Invalid constant Assembler error, input left in file /tmp/camlasm0.s make[1]: *** [tk.cmx] Error 2 make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make: *** [allopt] Error 2

Well, i don't know exactly what is happening here, as i am no arm assembly
expert, so i would like to forward this to you.

Note this is on a armv3l, which i hadded support for in the config.guess
file,s but the same problem was reported on an armv4l, which is in the ocaml
3.01 release.

The rest of the build, apart of labltk, went off without a glitch, even all of
the opt.opt stuff got built without a problem.

Friendly,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Mar 28, 2001

Comment author: administrator

Just cross posting to the debian arm list and Philip Blundell.

On Wed, Mar 28, 2001 at 10:26:25PM +0900, Jacques Garrigue wrote:

Hello, ...

While packaging ocaml 3.01 for debian, i received the following bug report
from the arm porters.
make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/lib' ../../../boot/ocamlrun ../../../ocamlopt -I ../../../stdlib -labels -c -I ../support tk.ml /tmp/camlasm0.s: Assembler messages: /tmp/camlasm0.s:26142: Error: Invalid constant /tmp/camlasm0.s:30129: Error: Invalid constant Assembler error, input left in file /tmp/camlasm0.s make[1]: *** [tk.cmx] Error 2 make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make: *** [allopt] Error 2

I didn't even know that there was an arm native port for ocaml...
Well, my first guess would be that there is ome limitation in the arm
architecture on the size of immediately loaded constants. Since large
integer constants are only generated when compiling polymorphic variants
that would explain why the problem only appears with labltk.

Having the actual camlasm0.s producing these errors would certainly help.
You can produce it by adding -S to the command line, but with tk.ml it
will be huge.

Jacques

@vicuna
Copy link
Author

vicuna commented Mar 28, 2001

Comment author: administrator

On Wed, Mar 28, 2001 at 10:26:25PM +0900, Jacques Garrigue wrote:

Hello, ...

While packaging ocaml 3.01 for debian, i received the following bug report
from the arm porters.
make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/lib' ../../../boot/ocamlrun ../../../ocamlopt -I ../../../stdlib -labels -c -I ../support tk.ml /tmp/camlasm0.s: Assembler messages: /tmp/camlasm0.s:26142: Error: Invalid constant /tmp/camlasm0.s:30129: Error: Invalid constant Assembler error, input left in file /tmp/camlasm0.s make[1]: *** [tk.cmx] Error 2 make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make: *** [allopt] Error 2

I didn't even know that there was an arm native port for ocaml...

Don't read the ocaml README file often, do you. Support was there since a long
time ago, since before they dropped m68k i think.

Well, my first guess would be that there is ome limitation in the arm
architecture on the size of immediately loaded constants. Since large
integer constants are only generated when compiling polymorphic variants
that would explain why the problem only appears with labltk.

Yes, this could be it, don't know though as i have no knowledge of the arm
architecture at all, i hope other people from the debian-arm list will be able
to respond to you a bit more here.

Having the actual camlasm0.s producing these errors would certainly help.
You can produce it by adding -S to the command line, but with tk.ml it
will be huge.

Well, i got the one from the failed compilation, the one i fot from /tmp.

Do you need it ? it is 814050 octet in size, I can mail it to you, or put it
in my anonymous ftp server at :

ftp://lambda.u-strasbg.fr/camlasm0.s

Hope this helps, it may be truncated though.

Friendly,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Mar 28, 2001

Comment author: administrator

Hello, ...

While packaging ocaml 3.01 for debian, i received the following bug report
from the arm porters.
make[1]: Entering directory /home/luther/ocaml-3.01/otherlibs/labltk/lib' ../../../boot/ocamlrun ../../../ocamlopt -I ../../../stdlib -labels -c -I ../support tk.ml /tmp/camlasm0.s: Assembler messages: /tmp/camlasm0.s:26142: Error: Invalid constant /tmp/camlasm0.s:30129: Error: Invalid constant Assembler error, input left in file /tmp/camlasm0.s make[1]: *** [tk.cmx] Error 2 make[1]: Leaving directory /home/luther/ocaml-3.01/otherlibs/labltk/lib'
make: *** [allopt] Error 2

I didn't even know that there was an arm native port for ocaml...
Well, my first guess would be that there is ome limitation in the arm
architecture on the size of immediately loaded constants. Since large
integer constants are only generated when compiling polymorphic variants
that would explain why the problem only appears with labltk.

Having the actual camlasm0.s producing these errors would certainly help.
You can produce it by adding -S to the command line, but with tk.ml it
will be huge.

Jacques

@vicuna
Copy link
Author

vicuna commented Mar 30, 2001

Comment author: administrator

I didn't even know that there was an arm native port for ocaml...

Don't read the ocaml README file often, do you. Support was there
since a long time ago, since before they dropped m68k i think.

Correct. The ARM port was done at the end of 1998.

Well, my first guess would be that there is ome limitation in the arm
architecture on the size of immediately loaded constants. Since large
integer constants are only generated when compiling polymorphic variants
that would explain why the problem only appears with labltk.

This is roughly what's happening. However, the constant in question
doesn't come from polymorphic variants, it's just a stack frame size
(1180) that cannot be expressed as an ARM immediate.

I'll try to fix this, however I no longer have access to an ARM machine
(e.g. Netwinder) to test the ARM code generator. If anyone wants to
do beta-testing, just drop me (Xavier.Leroy@inria.fr) a line.

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Mar 30, 2001

Comment author: administrator

On Fri, Mar 30, 2001 at 10:05:18AM +0200, Xavier Leroy wrote:

I didn't even know that there was an arm native port for ocaml...

Don't read the ocaml README file often, do you. Support was there
since a long time ago, since before they dropped m68k i think.

Correct. The ARM port was done at the end of 1998.

Well, my first guess would be that there is ome limitation in the arm
architecture on the size of immediately loaded constants. Since large
integer constants are only generated when compiling polymorphic variants
that would explain why the problem only appears with labltk.

This is roughly what's happening. However, the constant in question
doesn't come from polymorphic variants, it's just a stack frame size
(1180) that cannot be expressed as an ARM immediate.

I'll try to fix this, however I no longer have access to an ARM machine
(e.g. Netwinder) to test the ARM code generator. If anyone wants to
do beta-testing, just drop me (Xavier.Leroy@inria.fr) a line.

I have access to an arm box, medusa.armlinux.org, but maybe, if it would be ok
for you, i could see if the arm porter guys could provide you a login there,
don't know if they would but i can ask.

Friendly,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Apr 6, 2001

Comment author: administrator

Fixed 2001-04-03 by XL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant