> 
> 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


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.