This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/493: linux inf funcall fails
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 22 Apr 2002 14:18:04 -0000
- Subject: Re: gdb/493: linux inf funcall fails
- Reply-to: Daniel Jacobowitz <drow at mvista dot com>
The following reply was made to PR gdb/493; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: "Golubev I. N." <gin@mo.msk.ru>, gdb-gnats@sources.redhat.com
Cc:
Subject: Re: gdb/493: linux inf funcall fails
Date: Mon, 22 Apr 2002 10:05:02 -0400
On Mon, Apr 22, 2002 at 01:18:02PM -0000, Golubev I. N. wrote:
> The following reply was made to PR gdb/493; it has been noted by GNATS.
>
> From: "Golubev I. N." <gin@mo.msk.ru>
> To: gdb-gnats@sources.redhat.com, gdb-prs@sources.redhat.com
> Cc:
> Subject: Re: gdb/493: linux inf funcall fails
> Date: Mon, 22 Apr 2002 13:13:23 (GMT)
>
> Repeating `uname -a' output.
>
> Linux host 2.2.19-7.1.asp #1 Tue Oct 23 10:14:04 EDT 2001 i686 unknown
>
> `j*<stack memory location>' causes SIGSEGV in target process,
> regardless of code placed in location being jumped to.
>
> It appears to me that this ASP linux forbids running instructions
> located in stack, that is, `(CALL_DUMMY_LOCATION == ON_STACK)' way of
> doing things in `hand_function_call' is unsuitable to this system.
> However, just
>
> #define CALL_DUMMY_LOCATION AT_ENTRY_POINT
>
> is not enough. It causes the following.
OK, that makes sense. There are several non-exec stack patches
floating around for GNU/Linux. Andrew, you're (much) more familiar
with call dummies than I am; is there any reason we ever need to use
ON_STACK?
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer