NetBSD Problem Report #24218

Received: (qmail 26032 invoked by uid 605); 24 Jan 2004 19:43:09 -0000
Message-Id: <20040124185858.1E3FBA6@maailma.yok.utu.fi>
Date: Sat, 24 Jan 2004 20:58:58 +0200 (EET)
From: armihu@utu.fi
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: arto.huusko@pp2.inet.fi
To: gnats-bugs@gnats.netbsd.org
Subject: gdb (still) does not work on alpha
X-Send-Pr-Version: 3.95

>Number:         24218
>Category:       toolchain
>Synopsis:       gdb stack trace doesn't work always on alpha
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kamil
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 24 19:44:01 +0000 2004
>Closed-Date:    Fri Nov 20 10:21:40 +0000 2020
>Last-Modified:  Fri Nov 20 10:21:40 +0000 2020
>Originator:     Arto Huusko
>Release:        NetBSD 1.6ZF
>Organization:

>Environment:


System: NetBSD maailma.yok.utu.fi 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
>Description:
	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.
(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.

>How-To-Repeat:
	Not sure. I have tried to construct a trivial test case, but
	failed. For each trivial example I tried, gdb stack trace works
	correctly.
>Fix:
	Unknown.
>Release-Note:
>Audit-Trail:

From: Arto Huusko <armihu@utu.fi>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: port-alpha/24218
Date: Wed, 28 Jan 2004 13:56:48 +0200

 	OK, here is a trivial test case.

 int
 testi()
 {
      char *p = 0;

      return *p;
 }

 int
 main(int argc, char **argv)
 {
      return testi();
 }

 	Compile the code with "gcc testi.c -g -O2 -o testi",
 	run it, and examine core dump. For me, gdb says:

 maailma:/home/arto % gdb testi testi.core
 GNU gdb 5.3nb1
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "alpha--netbsd"...
 Core was generated by `testi'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /usr/libexec/ld.elf_so...done.
 Loaded symbols for /usr/libexec/ld.elf_so
 Reading symbols from /usr/lib/libc.so.12...done.
 Loaded symbols for /usr/lib/libc.so.12
 #0  testi () at testi.c:6
 6               return *p;
 (gdb) where
 #0  testi () at testi.c:6
 #1  0x0000000120000808 in __start ()
 Cannot access memory at address 0xfffffffffffffffd
 (gdb) q

 	The -O2 is important here, without it gdb shows the stack trace
 	correctly.

From: Arto Huusko <armihu@utu.fi>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: port-alpha/24218
Date: Tue, 10 Feb 2004 16:36:55 +0200

 	A wild guess, but could this have anything to do with

 http://gcc.gnu.org/ml/gcc/2004-01/msg01643.html

 	Briefly, STACK_BOUNDARY is 64, but ABI says it should
 	be 128.

From: Arto Huusko <arto.huusko@utu.fi>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: port-alpha/24218
Date: Sun, 16 May 2004 14:54:42 +0300

 	I'll just point out that this problem still exists in 2.0E.
Responsible-Changed-From-To: port-alpha-maintainer->nathanw
Responsible-Changed-By: nathanw@netbsd.org
Responsible-Changed-When: Tue, 30 Nov 2004 00:56:56 +0000
Responsible-Changed-Why:
I'll take this one.


State-Changed-From-To: open->suspended
State-Changed-By: nathanw@netbsd.org
State-Changed-When: Tue, 30 Nov 2004 00:56:56 +0000
State-Changed-Why:
The problem is a major internal GDB issue, and we're not going to
resolve it here.


From: "Nathan J. Williams" <nathanw@wasabisystems.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-alpha/24218
Date: 29 Nov 2004 19:55:24 -0500

 It's worth pointing out that in the -O2 case, gcc performs tail-call
 optimization on the call from main() to testi(); that is, it turns it
 into a jump.

 With gcc -g -O2:

 0000000120000b80 <main>: 
    120000b80:   02 00 bb 27     ldah    gp,2(t12)
    120000b84:   b0 82 bd 23     lda     gp,-32080(gp)
    120000b88:   f9 ff ff c3     br      120000b70 <testi>
    120000b8c:   00 00 fe 2f     unop    

 so at runtime, there really isn't any sense of "I was in main() in the
 previous frame".

 The detection of hitting the end-of-the-world should probably be
 better, but this is a general GDB problem on various platforms; for a
 recent example, see:

 http://sources.redhat.com/ml/gdb/2004-11/msg00020.html

 A slightly different test shows that intermediate functions which are
 tail calls are elided from the stack, but it's only when main() makes
 the tail-call that problems occur.

 I'm going to suspend this bug, and call it the GDB project's
 problem. If you have an example that isn't a tail-call from main(),
 please open a new PR.

         - Nathan


From: Arto Huusko <arto.huusko@utu.fi>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/24218
Date: Tue, 30 Nov 2004 20:57:37 +0200 (EET)

 	Well, the example below should have no tail calls.
 	However, when it is compiled with
 	"gcc -O2 -g -Wall test.c -o test" and run, gdb stack
 	trace is missing main(). The trace shows test() and
 	test2() and that's it.

 #include <stdio.h>

 int
 test(void)
 {
 	char *p = 0;

 	return *p;
 }

 int
 test2(void)
 {
 	return 1 + test();
 }

 int
 main(int argc, char **argv)
 {
 	int x;

 	x = test2();

 	printf("x = %d\n", x);

 	return x + 1;
 }

 	But it's ok with me if this is moved to gdb people.

From: Arto Huusko <arto.huusko@utu.fi>
To: "Nathan J. Williams" <nathanw@wasabisystems.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/24218
Date: Tue, 30 Nov 2004 22:51:40 +0200 (EET)

 On Tue, 30 Nov 2004, Nathan J. Williams wrote:

 > Odd, that's not what I see. Can you post a trace of exactly what you
 > get?

 	Well this is strange. The behaviour changes depending on
 	whether the program is run under gdb or not. Is the core
 	file broken?

 maailma.yok.utu.fi:/local/home/arto % gcc -g -O2 -Wall test.c -o test
 maailma.yok.utu.fi:/local/home/arto % ./test
 Memory fault (core dumped)
 maailma.yok.utu.fi:/local/home/arto % gdb test test.core
 GNU gdb 5.3nb1
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "alpha--netbsd"...
 Core was generated by `test'.
 Program terminated with signal 11, Segmentation fault.
 Reading symbols from /usr/libexec/ld.elf_so...done.
 Loaded symbols for /usr/libexec/ld.elf_so
 Reading symbols from /usr/lib/libc.so.12...done.
 Loaded symbols for /usr/lib/libc.so.12
 #0  test () at test.c:8
 8               return *p;
 (gdb) where
 #0  test () at test.c:8
 #1  0x0000000120000ae4 in test2 () at test.c:14
 (gdb) q
 maailma.yok.utu.fi:/local/home/arto % gdb test
 GNU gdb 5.3nb1
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "alpha--netbsd"...
 (gdb) run
 Starting program: /local/home/arto/test

 Program received signal SIGSEGV, Segmentation fault.
 test () at test.c:8
 8               return *p;
 (gdb) where
 #0  test () at test.c:8
 #1  0x0000000120000ae4 in test2 () at test.c:14
 #2  0x0000000120000b18 in main (argc=1, argv=0x1ffffec48) at test.c:22
 (gdb) q
 The program is running.  Exit anyway? (y or n) y
 maailma.yok.utu.fi:/local/home/arto % exit

Responsible-Changed-From-To: nathanw->toolchain-manager
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 08 Mar 2010 09:32:24 +0000
Responsible-Changed-Why:
nathanw -> observer
(also I switched category from bin to toolchain)


State-Changed-From-To: suspended->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 08 Mar 2010 09:32:24 +0000
State-Changed-Why:
Does this still happen nowadays?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 08 Mar 2010 09:35:09 +0000
State-Changed-Why:
feedback bounced


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 08 Mar 2010 09:35:37 +0000
State-Changed-Why:
update submitter address and try again: does this still happen?


From: Arto Huusko <arto.huusko@pp2.inet.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/24218
Date: Wed, 05 May 2010 23:49:54 +0300

 I'm sorry, but I don't have alpha hardware anymore, so I can't test
 this.

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 06 May 2010 08:10:02 +0000
State-Changed-Why:
Submitter can't test. I know there are people with alphas around; can one of
them give this a try?


Responsible-Changed-From-To: toolchain-manager->kamil
Responsible-Changed-By: kamil@NetBSD.org
Responsible-Changed-When: Sat, 07 Oct 2017 15:50:23 +0200
Responsible-Changed-Why:
Take.


State-Changed-From-To: open->closed
State-Changed-By: kamil@NetBSD.org
State-Changed-When: Fri, 20 Nov 2020 11:21:40 +0100
State-Changed-Why:
The reporter has no longer hardware to test, at least since 2010.


>Unformatted:

Home	PR Database Search