Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion?

Mark Kettenis
2005-11-02T15:51:41Z

> X-From_: gdb-return-22951-m.m.kettenis=alumnus.utwente.nl@sourceware.org Wed Nov 2 03:39:44 2005
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.org
> Date: Wed, 2 Nov 2005 10:43:03 +0800 (CST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-MailScanner-From: gdb-return-22951-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on
> elgar.sibelius.xs4all.nl
> X-Spam-Level:
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed
> version=3.0.4
>
> Hi all,
>
> I had found the reason why gdb will drop into SEGV when evaluating the
> fortran function calls. In g77 (gfortran might be the same), when we try
> to call FUNC_NAME (ARGS), the ARGS is passed as the pointer to the real
> parameters.
>
> While we issue "print FUNC_NAME (ARGS), these ARGS are passed as the
> original types. So fortran code can't handle that and SEGV occurs.
> Considering this special argument-passing mechanism, do we have any
> workaround for it in gdb's evaluation code? Create a dummy memory address
> for the arguments and pass that address instead? or any others?
>
> Your comments are highly appreciated. Thanks a lot.

What you describe sounds very similar to what
gdbarch_stabs_argument_has_addr is all about. Currently these are
only used on SPARC, and only for stabs.

One could argue that the debug information generated by g77 is wrong,
because it doesn't reflect the actual implementation of FUNC_NAME. Or
perhaps GDB symbol reading code causes problems. Can you post a
concrete example of a function call that goes wrong, and add a bit of
explanation about the types involved for those of us who are not very
familiar with Fortran?

Thanks,

Mark