Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004795OCamlOCaml generalpublic2009-05-19 13:462011-05-29 12:19
Reporterpaolo 
Assigned Toxleroy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version3.12.0+dev 
Summary0004795: -fPIC error with x86_64
Descriptionocamlc and ocamlopt fail to compile to dynamic libraries on linux x86_64.
Reproducible as follows:

$ echo "let x = 5" > lib.ml
$ ocamlc -output-obj -o lib.so lib.ml
/usr/bin/ld: /usr/lib/ocaml/libcamlrun.a(stacks.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib/ocaml/libcamlrun.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
File "lib.ml", line 1, characters 0-1:
Error: Error while building custom runtime system
TagsNo tags attached.
Attached Files? file icon amd64-pic.S [^] (13,976 bytes) 2010-02-16 23:43
? file icon amd64-pic.v2.S [^] (14,321 bytes) 2010-02-17 21:54

- Relationships

-  Notes
(0005018)
zinid (reporter)
2009-07-11 07:17
edited on: 2009-07-11 07:18

 The bug still exists even if compile libasmrun with -fPIC flag set:

$ ./configure -cc "gcc -fPIC" -aspp "gcc -fPIC -c"

$ /home/xram/ocaml/bin/ocamlopt -output-obj -o lib.so lib.ml
/usr/bin/ld: /home/xram/ocaml/lib/ocaml/libasmrun.a(amd64.o): relocation R_X86_64_PC32 against `caml_last_return_address' can not be used when making a shared object; recompile with -fPIC
...

It seems like asmrun/amd64.S doesn't produce position-independent code.
(0005244)
paul_stravers (reporter)
2010-02-16 23:48

 I have uploaded amd64-pic.S which is a drop-in replacement for amd64.S. The new assembly file creates position independent code if you define the macro EMIT_PIC=1. With EMIT_PIC=0 it behaves exactly like the stock amd64.S that comes with ocaml-3.11.1. So there is no need for Xavier to worry about performance. Only if you actually need PIC you take the performance hit.
(0005247)
xleroy (administrator)
2010-02-17 17:46

 Thanks for the replacement amd64.S. Much appreciated.

You're definitely on the right track, but I noticed a potential
problem in the caml_call_gc and caml_alloc* functions: the code
generator assumes they preserve all registers except %rax, but you're
using %r11 as a scratch register... For caml_call_gc, it should be
possible to move the series of "pushq" ahead of the STORE_VARs. For
caml_alloc*, some more footwork is needed to free a scratch register.

If you have ideas, please do let me know; otherwise, I'll try to
finish this before the 3.12.0 release.
(0005248)
paul_stravers (reporter)
2010-02-17 22:04

 I addressed the %r11 issue in the amd64-pic.v2.S that I just attached to this issue.

I tried this new amd64.S (EMIT_PIC=1) by regressing through some 120,000 lines of ocaml code that I have here, and regression passes. Actually, it also passed yesterday when register %r11 was still clobbered on some occasions, I guess I was lucky then ...
(0005275)
xleroy (administrator)
2010-03-29 14:18

 Thanks for the second version of the patch. I merged it in the development sources, to be released as 3.12.0. I made a tiny simplification in caml_allocN, and also used "#if __PIC__" instead of "#if EMIT_PIC", so that assembling with "gcc -c -fPIC" selects the PIC version. Let me know if you see a problem with that.
(0005313)
frisch (developer)
2010-04-15 15:15

 I still cannot succeed to link code generated by ocamlopt in a shared library under Linux x86_64.

I'm using the amd64.S from the trunk (after looking at 0004795) and take care to compile everything with -fPIC. I get this error:

/usr/bin/ld: /home/afrisch/branches/v4/mlfi/mlfi-ins/lib/libasmrun.a(amd64.o): relocation R_X86_64_PC32 against symbol `caml_alloc1' can not be used when making a shared object; recompile with -fPIC


Any help will be appreciated!
(0005341)
xleroy (administrator)
2010-04-19 10:49

 To my surprise, the assembler does not resolve a "jmp" to a global symbol defined in the same file, leaving an absolute reference to the symbol instead of putting a relative displacement :-( One learns something new every day. I just commited a fix to asmrun/amd64.S. The relocs look good and gcc -shared no longer complains.

- Issue History
Date Modified Username Field Change
2009-05-19 13:46 paolo New Issue
2009-05-20 14:10 doligez Status new => assigned
2009-05-20 14:10 doligez Assigned To => xleroy
2009-07-11 07:17 zinid Note Added: 0005018
2009-07-11 07:18 zinid Note Edited: 0005018
2010-02-16 23:43 paul_stravers File Added: amd64-pic.S
2010-02-16 23:48 paul_stravers Note Added: 0005244
2010-02-17 17:46 xleroy Note Added: 0005247
2010-02-17 21:54 paul_stravers File Added: amd64-pic.v2.S
2010-02-17 22:04 paul_stravers Note Added: 0005248
2010-03-29 14:18 xleroy Note Added: 0005275
2010-03-29 14:18 xleroy Status assigned => resolved
2010-03-29 14:18 xleroy Resolution open => fixed
2010-03-29 14:18 xleroy Fixed in Version => 3.12.0+dev
2010-04-15 15:15 frisch Note Added: 0005313
2010-04-15 15:15 frisch Status resolved => feedback
2010-04-15 15:15 frisch Resolution fixed => reopened
2010-04-19 10:49 xleroy Note Added: 0005341
2010-04-19 10:49 xleroy Status feedback => resolved
2010-04-19 10:49 xleroy Resolution reopened => fixed
2011-05-29 12:19 xleroy Status resolved => closed

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker