NetBSD Problem Report #8156

Received: (qmail 8151 invoked from network); 6 Aug 1999 15:38:29 -0000
Message-Id: <199908061538.BAA29711@merlin.reed.wattle.id.au>
Date: Sat, 7 Aug 1999 01:38:08 +1000 (EST)
From: darrenr@pobox.com
Reply-To: darrenr@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: gdb step/next doesn't work on arm32
X-Send-Pr-Version: 3.95

>Number:         8156
>Category:       port-arm
>Synopsis:       step/next in gdb do not work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    skrll
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 06 08:50:00 +0000 1999
>Closed-Date:    
>Last-Modified:  Sun May 01 06:09:52 +0000 2016
>Originator:     Darren Reed
>Release:        1.4
>Organization:

>Environment:
System: NetBSD merlin.reed.wattle.id.au 1.4 NetBSD 1.4 (MERLIN) #7: Mon Jul 5 17:11:16 EST 1999 darrenr@merlin.reed.wattle.id.au:/usr/src/sys/arch/arm32/compile/MERLIN arm32


>Description:
	use of step/next is broken with gdb on the arm32 port.
>How-To-Repeat:
	use gdb to debug a program, using step/next.  at random it will
appear to not step/next but actually continue executing the rest of the
program.
>Fix:

>Release-Note:
>Audit-Trail:

From: Richard Earnshaw <rearnsha@arm.com>
To: darrenr@pobox.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: port-arm32/8156: gdb step/next doesn't work on arm32 
Date: Fri, 06 Aug 1999 18:18:50 +0100

 This is essentially a duplicate of bin/7565 (which contains the relevant 
 patch, but has not yet been attended to).  There are still problems after 
 this, but at least single stepping seems to work.

 Tod, any chance you could fix this?

 Richard.


From: Darren Reed <darrenr@reed.wattle.id.au>
To: richard.earnshaw@arm.com
Cc: darrenr@pobox.com, gnats-bugs@gnats.netbsd.org, richard.earnshaw@arm.com,
        tv@pobox.com
Subject: Re: port-arm32/8156: gdb step/next doesn't work on arm32
Date: Sun, 29 Aug 1999 18:57:03 +1000 (EST)

 In some email I received from Richard Earnshaw, sie wrote:
 > This is essentially a duplicate of bin/7565 (which contains the relevant 
 > patch, but has not yet been attended to).  There are still problems after 
 > this, but at least single stepping seems to work.
 > 
 > Tod, any chance you could fix this?

 has there been any progress on this ?  gdb-4.18 has the changes in
 bin/7565.  It would be real nice for NetBSD to get up to date here.
 This patch *should* have been in 1.4.1

From: Darren Reed <darrenr@reed.wattle.id.au>
(From PR8408)
I tested the patch in bin/7565 with the gdb source from 1.4 and it does
not fix the problem:


# /usr/src/gnu/usr.bin/gdb/gdb arm-unknown-netbsd1.4/nsyslogd 
...
This GDB was configured as "arm--netbsd"...
(gdb) break main
Breakpoint 1 at 0x1303c: file main.c, line 614.
(gdb) run -dvf trivial
Starting program: /home/darrenr/src/nsyslogd/arm-unknown-netbsd1.4/nsyslogd -dvf trivial


Breakpoint 1, main (argc=3, argv=0xefbfd6ec) at main.c:614
614             int killflag = 0, reloadflag = 0;
(gdb) step
621             tzset();
(gdb) 
622             if (!(progname = strrchr(argv[0], '/')))
(gdb) 
625                     progname++;
(gdb) 
627             bzero((char *)&act, sizeof(act));
(gdb) 
Reading configuration from trivial
error opening logfile /dev/klog: Device busy
bind failed: Address already in use
...


Or at least doing a "make includes" in usr/src/gnu and "make" in the
usr/src/gnu/usr.bin/gdb directory did not generate a `fixed' gdb.


Has anyone else tested the patch in bin/7565 and had it work for them ?


Darren

(From PR 8409)
I'm not sure this is directly related.  I've noticed several problems with 
trying to use gdb, and it seems there are in fact a whole host of 
unresolved issues.


1) Stepping over/into shared library stubs seems to be broken (and always 
has been).  Does your particular problem go away if you link -static (no 
shared libs)?


2) There still seem to be some vm problems related to debugging.  On more 
than one occasion I've had gdb report that it has failed to set a 
breakpoint or reports a memory location as being invalid at a perfectly 
legitimate address; it seems that if a page, once mapped in, gets mapped 
out again for some reason then accesses to it via the ptrace call can (but 
don't always) fail; repeating the command will often succeed (but this 
doesn't apply to setting breakpoints -- gdb remembers that there have been 
failures and just gives up).


3) Gdb is still not very good at understanding function prologues when 
code is compiled -O2; best fix for this is to compile no higher than -O 
when debugging, or to just accept that stack back-traces just won't work.


4) The gdb "call" command has been broken again -- I fixed this for the 
previous version of gdb, but then the conventions were all changed again 
and the netbsd port code just hasn't caught up.


5) gcc should be configured to pass -X to the linker to tell it to discard 
symbols starting with 'L' (these are internal code symbols and have 
nothing to do with user-land.  The official egcs/gcc sources do this; I 
don't know why it isn't done in the NetBSD in-tree copy.


I think 2) is probably another symptom of PR 7122 (Breakpoints lost under 
heavy swapping), but I can't be sure.


I've virtually given up on the in-tree version of gdb.  In fact I've 
down-loaded the cygnus development code and started a new port of that; it 
is already much more functional (though it still fails many tests), and 2) 
& 5) are still going to be problems.


Richard.

(From PR 8410)
darrenr@reed.wattle.id.au said:
> Or at least doing a "make includes" in usr/src/gnu and "make" in the
> usr/src/gnu/usr.bin/gdb directory did not generate a `fixed' gdb. 


Dependencies on target-specific header files are not a strong point of gnu 
make systems.  I would recommend that you do a "make clean" in 
usr/src/gnu/usr.bin/gdb and then to a fresh build/install.


Richard.

(From PR8411)
In some email I received from Richard Earnshaw, sie wrote:
[...]
> 1) Stepping over/into shared library stubs seems to be broken (and always 
> has been).  Does your particular problem go away if you link -static (no 
> shared libs)?


No.


Darren

State-Changed-From-To: open->feedback 
State-Changed-By: is 
State-Changed-When: Fri Sep 10 05:58:38 PDT 1999 
State-Changed-Why:  
Does the patch of PR 7565 make gdb work for you, or do you observe a 
different problem? 

-is 
State-Changed-From-To: feedback->open 
State-Changed-By: is 
State-Changed-When: Tue Sep 14 06:42:35 PDT 1999 
State-Changed-Why:  
The victim claims that the fix from #7156 does not help in his case. 
This must be a different problem. 
Responsible-Changed-From-To: port-arm32-maintainer->port-arm-maintainer 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Mon Aug 5 17:47:46 PDT 2002 
Responsible-Changed-Why:  
The arm32 port has disappeared. 
Responsible-Changed-From-To: port-arm-maintainer->skrll
Responsible-Changed-By: chris@narn.netbsd.org
Responsible-Changed-When: Sun, 20 Jan 2008 14:08:55 +0000
Responsible-Changed-Why:
Nick said he'd take a look at it.


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 31 Dec 2011 22:14:27 +0000
State-Changed-Why:
Did gdb7 help this?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 18 Oct 2015 09:17:56 +0000
State-Changed-Why:
feedback mail bounced


State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 18 Oct 2015 09:18:47 +0000
State-Changed-Why:
try again with better address:

Did gdb7 help this?


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 01 May 2016 06:09:52 +0000
State-Changed-Why:
judging by PR 38185, it is not fixed.


>Unformatted:

Home	PR Database Search