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: "Golubev I. N." <gin at mo dot msk dot ru>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 22 Apr 2002 13:18:02 -0000
- Subject: Re: gdb/493: linux inf funcall fails
- Reply-to: "Golubev I. N." <gin at mo dot msk dot ru>
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.
#8 0x080c48a0 in internal_verror (
file=0x81487e0 "../../gdb-5.1.1/gdb/infcmd.c", line=873,
fmt=0x81487cd "CALL_DUMMY_ADDRESS", ap=0x8049cb0)
at ../../gdb-5.1.1/gdb/utils.c:697
#9 0x08089231 in run_stack_dummy (addr=134519984, buffer=0xbffff040 )
at ../../gdb-5.1.1/gdb/infcmd.c:870
#10 0x08074a82 in hand_function_call (function=0x8256ed0, nargs=1,
args=0xbffff254) at ../../gdb-5.1.1/gdb/valops.c:1655
Apparently changing `CALL_DUMMY_LOCATION' requires some additional
adjustment.
Apparently most other linux'es allow executing code in stack. Then
whether system allows that is not clear from its `uname' output. So
deciding whether to do such an adjustments requires some configure-
time checks. Did it ever happen to other systems, so that existing
configuration code may be used as a source of inspiration?