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