Subject: port-alpha/24218: gdb (still) does not work on alpha
To: None <>
From: None <>
List: netbsd-bugs
Date: 01/24/2004 20:58:58
>Number:         24218
>Category:       port-alpha
>Synopsis:       gdb stack trace doesn't work always on alpha
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-alpha-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 24 19:44:01 UTC 2004
>Originator:     Arto Huusko
>Release:        NetBSD 1.6ZF
System: NetBSD 1.6ZF NetBSD 1.6ZF (MAAILMA) #2: Mon Dec 1 21:44:24 EET 2003 arto@lady:/data/netbsd/current/alpha/obj/sys/arch/alpha/compile/MAAILMA alpha
Architecture: alpha
Machine: alpha
	When trying to get stack trace, for example from a core dump,
	gdb often reports this:

(gdb) where
#0  dNewDynString () at dynstr.c:30
warning: Hit heuristic-fence-post without finding
warning: enclosing function for address 0x8300000082000000
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable).  In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.

	However, the executable and associated static libraries are all
	compiled (and linked) with -g.

	Other similar symptom is that only first (or some of the first)
	frame is shown, for example:

(gdb) where
#0  helloapp_main (cmd=1, msg=0x1ffffe7e8, o=1, arg1=0x0, arg2=0)
    at helloapp.c:59

	Where there should be 4 or 5 frames more.

	And I see also this:

(gdb) where
#0  dNewDynString () at dynstr.c:30
Cannot access memory at address 0xfffffffffffffffd

	gdb itself does work always the same way, but light changes to the
	program produce different results.

	Not sure. I have tried to construct a trivial test case, but
	failed. For each trivial example I tried, gdb stack trace works