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.

Sign up for GitHub

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

Jump to bottom

4.10 branch - tests/output-complete-obj fails on FreeBSD-12 (at least 12.1-RC2) #9068

Closed
hannesm opened this issue Oct 24, 2019 · 5 comments
Closed

4.10 branch - tests/output-complete-obj fails on FreeBSD-12 (at least 12.1-RC2) #9068

hannesm opened this issue Oct 24, 2019 · 5 comments

Comments

@hannesm
Copy link
Member

hannesm commented Oct 24, 2019

when I run the testsuite with the 4.10 branch on my FreeBSD machine (amd64, 12-stable which uses clang 8.0.1 (similar to 12.1RC2 http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/12.1/) -- not sure whether this is as well an issue in 12.0), I see a single failing test (output-complete-obj):

# gmake one tests/output-complete-obj
Running tests from 'tests/output-complete-obj' ...
 ... testing 'test.ml' with 1 (libunix) => passed
 ... testing 'test.ml' with 1.1 (setup-ocamlc.byte-build-env) => passed
 ... testing 'test.ml' with 1.1.1 (ocamlc.byte) => passed
 ... testing 'test.ml' with 1.1.1.1 (script) => passed
 ... testing 'test.ml' with 1.1.1.1.1 (run) => passed
 ... testing 'test.ml' with 1.2 (setup-ocamlopt.byte-build-env) => passed
 ... testing 'test.ml' with 1.2.1 (ocamlopt.byte) => failed (Compiling program test.ml.exe.o from modules  test.ml: command
/usr/home/hannes/ocaml/runtime/ocamlrun /usr/home/hannes/ocaml/ocamlopt  -I /usr/home/hannes/ocaml/runtime  -nostdlib -I /usr/home/hannes/ocaml/stdlib  -w a -output-complete-obj     -o test.ml.exe.o   test.ml 
failed with exit code 2)
 ... testing 'test.ml' with 1.2.1.1 (script) => n/a
 ... testing 'test.ml' with 1.2.1.1.1 (run) => n/a
 ... testing 'test2.ml' with 1 (hasunix) => passed
 ... testing 'test2.ml' with 1.1 (setup-ocamlc.byte-build-env) => passed
 ... testing 'test2.ml' with 1.1.1 (ocamlc.byte) => passed
 ... testing 'test2.ml' with 1.1.1.1 (run) => passed
 ... testing 'test2.ml' with 1.1.1.1.1 (check-program-output) => passed
gmake[1]: Entering directory '/usr/home/hannes/devel/mirage/ocaml/testsuite'
gmake[1]: Leaving directory '/usr/home/hannes/devel/mirage/ocaml/testsuite'

manually running the test to see the output:

output-complete-obj# /usr/home/hannes/ocaml/runtime/ocamlrun /usr/home/hannes/ocaml/ocamlopt -I /usr/home/hannes/ocaml/runtime -nostdlib -I /usr/home/hannes/ocaml/stdlib -w a -output-complete-obj -o test.ml.exe.o test.ml
ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(startup_nat_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(startup_aux_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(roots_nat_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(signals_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(fail_nat_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(signals_nat_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(misc_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(freelist_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(major_gc_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(minor_gc_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(memory_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(alloc_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(compare_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(ints_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(floats_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(str_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(io_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(extern_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(intern_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: section type mismatch for .eh_frame
>>> /usr/home/hannes/ocaml/runtime/libasmrun.a(sys_n.o):(.eh_frame): SHT_X86_64_UNWIND
>>> output section .eh_frame: SHT_PROGBITS

ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
File "caml_startup", line 1:
Error: Error during linking
@hannesm hannesm changed the title 4.10 branch - tests/output-complete-obj fails on FreeBSD-12 (at least 12.1-RC1) 4.10 branch - tests/output-complete-obj fails on FreeBSD-12 (at least 12.1-RC2) Oct 24, 2019
@bschommer
Copy link
Contributor

I encountered a similar failure when I tried version 4.09 with clang as compiler under linux.

@hannesm
Copy link
Member Author

hannesm commented Oct 24, 2019

@bschommer interesting. I use clang for both compiler and linker (i.e. no binutils ld, but clang's lld).

@bschommer
Copy link
Contributor

bschommer commented Oct 24, 2019 •
edited
Loading

@bschommer interesting. I use clang for both compiler and linker (i.e. no binutils ld, but clang's lld).

Similar setting here, we also use both clang and lld. The error message is the same one.

xavierleroy added a commit to xavierleroy/ocaml that referenced this issue Apr 10, 2020
@xavierleroy
configure: use cc as assembler for all FreeBSD platforms
67f69a7 
In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker,
but `as` is still GNU.  Moreover, Clang contains its own assembler
and does not call `as`.  Consequently, object files produced by
invoking `as` directly are slightly different from those produced by
`cc`.

This can cause obscure errors such as issue ocaml#9068: `ld -r` fails when
combining objects produced by `as` and objects produced by `cc`.

The workaround is to use `cc` as the assembler.  We already did that
for the ARM and ARM64 targets, but ocaml#9068 shows that it is necessary
for AMD64 too.  Just use `cc` as assembler for all FreeBSD targets.
xavierleroy added a commit to xavierleroy/ocaml that referenced this issue Apr 10, 2020
@xavierleroy
configure: use cc as assembler for all FreeBSD platforms
c4685df 
In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker,
but `as` is still GNU.  Moreover, Clang contains its own assembler
and does not call `as`.  Consequently, object files produced by
invoking `as` directly are slightly different from those produced by
`cc`.

This can cause obscure errors such as issue ocaml#9068: `ld -r` fails when
combining objects produced by `as` and objects produced by `cc`.

The workaround is to use `cc` as the assembler.  We already did that
for the ARM and ARM64 targets, but ocaml#9068 shows that it is necessary
for AMD64 too.  Just use `cc` as assembler for all FreeBSD targets.

Closes: ocaml#9068
@xavierleroy
Copy link
Contributor

I was able to reproduce and diagnose the problem. ocamlopt calls as to produce object files. However, on FreeBSD 12.1, as is still the GNU assembler from binutils, and it generates slightly different object files than cc, which is Clang and goes through LLVM's internal assembler, not through as.

One difference in the section where .eh_frame resides. When combining objects produced by ocamlopt/as and objects produced by cc, this difference doesn't break the linking performed by cc, but it breaks the partial linking performed by ld -r. Go figure.

The solution is to use cc as our assembler, like OCaml/FreeBSD already does for ARM targets. A PR is in preparation.

xavierleroy added a commit to xavierleroy/ocaml that referenced this issue Apr 10, 2020
@xavierleroy
configure: use cc as assembler with clang and for all FreeBSD platforms
4cab9cd 
In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker, but
`as` is still GNU binutils.  Moreover, Clang contains its own
assembler and does not call `as`.  Consequently, object files produced
by invoking `as` directly are slightly different from those produced
by `cc`.

This can cause obscure errors such as issue ocaml#9068: `ld -r` fails when
combining objects produced by `as` and objects produced by `cc`.

The workaround is to use `cc` as the assembler.  We already did that
for the ARM and ARM64 targets, but ocaml#9068 shows that it is necessary
for AMD64 too.  Just use `cc` as assembler for all FreeBSD targets.

Similar issues were reported under Linux when clang and LLD are used
instead of GCC and binutils.  We already used clang as the preprocessed
assembler in this case.  Also use clang as the assembler in this case.

Closes: ocaml#9068
@xavierleroy xavierleroy mentioned this issue Apr 10, 2020
Merged
@hannesm
Copy link
Member Author

hannesm commented Apr 10, 2020

Thanks @xavierleroy for your investigation and fix. I successfully tested #9437 -- the output-complete-obj test no longer fails on FreeBSD 12.1.

dra27 pushed a commit that referenced this issue May 5, 2020
@xavierleroy @dra27
configure: use cc as assembler with clang and for all FreeBSD platfor…
e70e8cd 
…ms (#9437)

In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker, but
`as` is still GNU binutils.  Moreover, Clang contains its own
assembler and does not call `as`.  Consequently, object files produced
by invoking `as` directly are slightly different from those produced
by `cc`.

This can cause obscure errors such as issue #9068: `ld -r` fails when
combining objects produced by `as` and objects produced by `cc`.

The workaround is to use `cc` as the assembler.  We already did that
for the ARM and ARM64 targets, but #9068 shows that it is necessary
for AMD64 too.  Just use `cc` as assembler for all FreeBSD targets.

Similar issues were reported under Linux when clang and LLD are used
instead of GCC and binutils.  We already used clang as the preprocessed
assembler in this case.  Also use clang as the assembler in this case.

Closes: #9068
(cherry picked from commit 88a1bce)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hannesm @xavierleroy @bschommer