Control: reassign -1 g++-4.9 4.9.1-16 Control: affects -1 cbmc > This also occurs with arb: > https://buildd.debian.org/fetch.cgi?pkg=arb&arch=i386&ver=6.0.2-1&stamp=1412337993&file=log > > > It seems to be a bug in binutils[1]. > > I'd say a change in binutils exposed a bug somewhere in the toolchain. > > Here's the commit which added the check and the message: > > https://www.sourceware.org/ml/binutils/2014-09/msg00094.html > > Here's Alan's answer to me asking what I can do to repair this: > https://www.sourceware.org/ml/binutils/2014-09/msg00175.html >
As the recent update to binutils provides a lot more helpful output on this issue, I've followed Alan's advice. A couple of things appear to be noteworthy. The failing commands for CBMC are: cbmc-4.9/src/util# make ld -r -o util.a arith_tools.o base_type.o cmdline.o config.o symbol_table.o expr.o expr_util.o i2string.o irep.o language.o lispexpr.o lispirep.o location.o message.o language_file.o mp_arith.o namespace.o parseoptions.o rename.o replace_expr.o threeval.o typecheck.o graph.o type.o cnf_simplify.o pointer_predicates.o merge_irep.o bitvector.o parser.o map_util.o replace_symbol.o actuals.o get_module.o string_hash.o string_container.o identifier.o rational.o options.o c_misc.o simplify_expr.o dstring.o find_symbols.o rational_tools.o ui_message.o simplify_utils.o time_stopping.o symbol.o irep_hash_container.o cout_message.o type_eq.o guard.o array_name.o message_stream.o substitute.o decision_procedure.o union_find.o xml.o xml_irep.o xml_expr.o std_types.o std_code.o format_constant.o find_macros.o ref_expr_set.o std_expr.o irep_serialization.o fixedbv.o rename_symbol.o ieee_float.o signal_catcher.o pointer_offset_size.o bv_arithmetic.o tempdir.o tempfile.o timer.o unicode.o irep_ids.o byte_operators.o string2int.o file_util.o memory_info.o pipe_stream.o irep_hash.o g++ -o ieee_float_test ieee_float_test.o util.a ../big-int/bigint.o ../big-int/bigint-func.o /usr/bin/ld: .eh_frame_hdr table[769] FDE at 00000000080d3738 overlaps table[770] FDE at 00000000080d46c4. [...] /usr/bin/ld: .eh_frame_hdr table[988] FDE at 00000000080de20c overlaps table[989] FDE at 00000000080e3698. collect2: error: ld returned 1 exit status Makefile:61: recipe for target 'ieee_float_test' failed make: *** [ieee_float_test] Error 1 1. Replacing util.a in the call to g++ by its constituting set of object files makes the build succeed: cbmc-4.9/src/util# g++ -o ieee_float_test ieee_float_test.o arith_tools.o base_type.o cmdline.o config.o symbol_table.o expr.o expr_util.o i2string.o irep.o language.o lispexpr.o lispirep.o location.o message.o language_file.o mp_arith.o namespace.o parseoptions.o rename.o replace_expr.o threeval.o typecheck.o graph.o type.o cnf_simplify.o pointer_predicates.o merge_irep.o bitvector.o parser.o map_util.o replace_symbol.o actuals.o get_module.o string_hash.o string_container.o identifier.o rational.o options.o c_misc.o simplify_expr.o dstring.o find_symbols.o rational_tools.o ui_message.o simplify_utils.o time_stopping.o symbol.o irep_hash_container.o cout_message.o type_eq.o guard.o array_name.o message_stream.o substitute.o decision_procedure.o union_find.o xml.o xml_irep.o xml_expr.o std_types.o std_code.o format_constant.o find_macros.o ref_expr_set.o std_expr.o irep_serialization.o fixedbv.o rename_symbol.o ieee_float.o signal_catcher.o pointer_offset_size.o bv_arithmetic.o tempdir.o tempfile.o timer.o unicode.o irep_ids.o byte_operators.o string2int.o file_util.o memory_info.o pipe_stream.o irep_hash.o ../big-int/bigint.o ../big-int/bigint-func.o cbmc-4.9/src/util# 2. (I had tried the above to further simplify debugging when dumping the map file as suggested by Alan.) So I had to look at two map files built using -Wl,-Map,... - one for the above g++ call, and one for the earlier ld building util.a. Adding up the offsets it seems that there are clashes in a number of object files, but base_type.o is one of them. Here's the result of readelf -wf base_type.o | grep FDE: 00000018 0000002c 0000001c FDE cie=00000000 pc=00000000..00000035 00000048 0000001c 0000004c FDE cie=00000000 pc=00000035..00000051 00000068 0000001c 0000006c FDE cie=00000000 pc=00000051..0000006d 00000088 0000001c 0000008c FDE cie=00000000 pc=0000006d..00000089 000000a8 0000001c 000000ac FDE cie=00000000 pc=00000089..000000a5 000000c8 0000001c 000000cc FDE cie=00000000 pc=000000a6..000000bf 000000e8 0000001c 000000ec FDE cie=00000000 pc=000000c0..000000d9 00000108 0000001c 0000010c FDE cie=00000000 pc=000000da..000000f6 00000128 0000006c 0000012c FDE cie=00000000 pc=00000000..000000d5 000001b8 00000034 00000024 FDE cie=00000198 pc=00000000..00000091 000001f0 00000030 0000005c FDE cie=00000198 pc=00000000..00000073 00000224 00000050 00000228 FDE cie=00000000 pc=00000000..0000017a 00000278 00000050 0000027c FDE cie=00000000 pc=00000000..000001e8 000002cc 00000034 000002d0 FDE cie=00000000 pc=00000000..00000034 00000304 000000d8 00000308 FDE cie=00000000 pc=00000000..00000258 000003e0 0000003c 000003e4 FDE cie=00000000 pc=00000000..00000045 00000420 0000003c 00000424 FDE cie=00000000 pc=00000000..00000055 00000460 0000003c 00000464 FDE cie=00000000 pc=00000000..00000053 000004a0 00000034 0000030c FDE cie=00000198 pc=00000260..00000387 000004d8 00000070 000004dc FDE cie=00000000 pc=00000000..000000f0 0000054c 00000034 00000550 FDE cie=00000000 pc=00000000..00000034 00000584 00000074 00000588 FDE cie=00000000 pc=00000000..0000017a 000005fc 00000034 00000468 FDE cie=00000198 pc=00000390..00000633 00000634 00000030 000004a0 FDE cie=00000198 pc=00000640..000006bb 00000668 00000080 0000066c FDE cie=00000000 pc=000006c0..000007a6 000006ec 00000070 000006f0 FDE cie=00000000 pc=00000000..00000100 00000760 00000034 000005cc FDE cie=00000198 pc=000007b0..000011ca 00000798 00000034 00000604 FDE cie=00000198 pc=000011d0..000012f7 Just in case, base_type.o is built as follows: g++ -c -MMD -MP -DSTL_HASH_TR1 -Wall -O2 -I .. -o base_type.o base_type.cpp My understanding of the output of readelf is limited, but from https://sourceware.org/bugzilla/show_bug.cgi?id=17447#c3 I gather that the pc= bits are address ranges that are not supposed to overlap. Yet here there seem to be multiple (and strange) overlaps: 1) The first five have a 1-byte overlap, whereas the later ones start at the next byte only. 2) The range pc=00000000..0000017a exists twice. 3) There are multiple entries starting at 00000000. Best, Michael
pgp0WkELNCSk4.pgp
Description: PGP signature
