This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/1724: call in inferior fails for 64-bit PowerPC
- From: dsl at sources dot redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 30 Jul 2004 16:17:57 -0000
- Subject: gdb/1724: call in inferior fails for 64-bit PowerPC
- Reply-to: dsl at sources dot redhat dot com
>Number: 1724
>Category: gdb
>Synopsis: call in inferior fails for 64-bit PowerPC
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jul 30 16:18:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: dsl@sources.redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
SUSE LINUX Enterprise Server 9 (ppc)
GDB configured using CFLAGS=-m64 for 64 bit debug..
>Description:
GDB can't figure out the address of malloc correctly, in expression evaluation, and so calls some wrong address resulting in seg fault:
(gdb) b main
Breakpoint 1 at 0x100005a8: file foo.c, line 2.
(gdb) r
Starting program: /home/david/foo_gcc_64
Breakpoint 1, main () at foo.c:2
2 malloc(4);
(gdb) p malloc(40)
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000080 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (at 0x80) will be abandoned.
Curiously, adding a breakpoint at malloc works fine. If you use the address of the breakpoint to get the address of malloc and then call that, it seems to work.
>How-To-Repeat:
gcc -m64 foo.c -g -o foo_64
where foo.c is:
int main() {
malloc(4);
printf("%d %d\n", sizeof(int), sizeof(void*));
}
run gdb.
b main
r
p malloc(4)
gets a seg fault.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: