This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion?
Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Nov 02, 2005 at 11:42:36PM -0800, Jim Blandy wrote:
>> The types in the debug information should not reflect the extra level
>> of indirection; the fact that they're passed by reference is just part
>> of the meaning of a Fortran function call. But the location
>> expression should encode the extra level of indirection.
>
> This seems perfectly sensible to me. But the example Wu posted earlier
> does not agree: today gfortran apparently puts out the indirections
> explicitly.
You're talking about this, where 'm' is declared as 'integer', right?
<1><da>: Abbrev Number: 7 (DW_TAG_subprogram)
DW_AT_sibling : <10f>
DW_AT_external : 1
DW_AT_name : res_
DW_AT_decl_file : 1
DW_AT_decl_line : 23
DW_AT_type : <bb>
DW_AT_low_pc : 0x804863f
DW_AT_high_pc : 0x8048655
DW_AT_frame_base : 1 byte block: 55 (DW_OP_reg5)
<2><f5>: Abbrev Number: 8 (DW_TAG_formal_parameter)
DW_AT_name : m
DW_AT_type : <10f> =====> This is a const pointer to integer
DW_AT_artificial : 1
DW_AT_location : 2 byte block: 91 8 (DW_OP_fbreg: 8)
<1><10f>: Abbrev Number: 9 (DW_TAG_const_type)
DW_AT_type : <114>
<1><114>: Abbrev Number: 10 (DW_TAG_pointer_type)
DW_AT_byte_size : 4
DW_AT_type : <bb>
<1><bb>: Abbrev Number: 6 (DW_TAG_base_type)
DW_AT_name : integer
DW_AT_byte_size : 4
DW_AT_encoding : 5 (signed)
> So it sounds like gfortran will need to be fixed.
Yep. The types in the Dwarf information should match the types as
they appear in the source language.