------- Comment #22 from ubizjak at gmail dot com 2009-08-31 16:56 ------- Digging deeper, it smells like a linker error, at least on alpha (please note that I used -static for final linking to ease debugging a bit):
FDE that corresponds to _ZN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEEEC2ERKSJ_ is defined as: $LSFDE1017: .4byte $LEFDE1017-$LASFDE1017 $LASFDE1017: .4byte $LASFDE1017-$Lframe1 .4byte $LFB5855-. .4byte $LFE5855-$LFB5855 .uleb128 0x4 >> .4byte $LLSDA5855-. .byte 0x4 .4byte $LCFI1142-$LFB5855 .byte 0xe .uleb128 0x40 .byte 0x4 and corresponding LSDA: $LLSDA5855: .byte 0xff .byte 0x9b .uleb128 $LLSDATT5855-$LLSDATTD5855 $LLSDATTD5855: .byte 0x1 .uleb128 $LLSDACSE5855-$LLSDACSB5855 $LLSDACSB5855: .uleb128 $LEHB373-$LFB5855 .uleb128 $LEHE373-$LEHB373 .uleb128 $L2169-$LFB5855 .uleb128 0x0 Now, liker links LSDA into FDE as: (gdb) x/32cx fde 0x12019e770: 0x34 0x00 0x00 0x00 0xf4 0x1a 0x00 0x00 0x12019e778: 0xc8 0x11 0xe7 0xff 0x88 0x02 0x00 0x00 0x12019e780: 0x04 0x84 0xcc 0x01 0x00 0x50 0x0e 0x40 0x12019e788: 0x58 0x8e 0x02 0x8b 0x05 0x89 0x07 0x58 So, linker puts 0x0001cc84 at PC 0x12019e781. Adding both together (as marked by ">>" above), we get 0x1201bb405. This value is wrong, LSDA is located at 0x1201bb3f4 (see comment #21). So, linker is perhaps creating address, relative to start of FDE instead of current address. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058