Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000327OCamlOCaml generalpublic2001-03-28 13:122001-04-06 15:27
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000327: labltk native code build problem on arm.
DescriptionHello, ...

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

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000551)
administrator (administrator)
2001-03-28 16:19

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

(0000552)
administrator (administrator)
2001-03-28 16:26

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

(0000553)
administrator (administrator)
2001-03-28 22:26

> 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

(0000554)
administrator (administrator)
2001-03-30 10:05

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

(0000555)
administrator (administrator)
2001-03-30 11:42

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

(0000556)
administrator (administrator)
2001-04-06 15:27

Fixed 2001-04-03 by XL.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker