Bug 23472

If a program is compiled with -ggdb, gdb sometimes loses track of local
variables' addresses and/or contents.

Fix: 

Wish I knew :(  A friend wasted hours today in a gdb session, thinking
his program was passing a value of 100 as 134 millions..  and at the same
time marvelling at the program's perfectly fine output :(
How-To-Repeat: 
Consider the following program:

#include <stdio.h>
#include <unistd.h>

#define BUFLEN	100

int
readstring(char *s, int len) {

  printf("readstring(%p, %d) called, s='%s'\n", s, len, s);
  return 0;
}

int
main(void) {
  char str[BUFLEN] = "string";

  printf("in main: str=%p, sizeof(str)=%d, str='%s'\n", str, sizeof(str), str);
  readstring(str, sizeof(str));
  return 0;
}

..and the following Makefile:

CFLAGS	= -g3 -ggdb

all:	zettest

clean:
	rm -f zettest

Following is the transcript of a gdb session.

Script started on Mon Dec 11 17:48:52 2000
[roam@ringwraith ~/c/misc/zettest]$ gdb zettest
GNU gdb 4.18
Copyright 1998 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 "i386-unknown-freebsd"...
(gdb) br main
Breakpoint 1 at 0x8048572: file zettest.c, line 15.
(gdb) r
Starting program: /usr/home/roam/lang/c/misc/zettest/zettest 

Breakpoint 1, main () at zettest.c:15
15	  char str[BUFLEN] = "string";
(gdb) n
17	  printf("in main: str=%p, sizeof(str)=%d, str='%s'\n", str, sizeof(str), str);
(gdb) 
in main: str=0xbfbff904, sizeof(str)=100, str='string'
             ^^^^^^^^^^ real address          ^^^^^^^^ real contents
18	  readstring(str, sizeof(str));
(gdb) print (void *) str
$1 = (void *) 0xbfbff88c
              ^^^^^^^^^^ something's fishy..
(gdb) print &str[0]
$2 = 0xbfbff88c ""
(gdb) s
readstring (s=0xbfbff968 "´ù¿¿\211\204\004\b\001", len=134514114)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ uhm  ^^^^^^^^^ excuse me?!
    at zettest.c:9
9	  printf("readstring(%p, %d) called, s='%s'\n", s, len, s);
(gdb) n
readstring(0xbfbff904, 100) called, s='string'
           ^^^^^^^^^^  ^^^             ^^^^^^ everyhing's just fine
10	  return 0;
(gdb) c
Continuing.

Program exited normally.
(gdb) quit
[roam@ringwraith ~/c/misc/zettest]$ exit
exit

Script done on Mon Dec 11 17:49:15 2000


Well, so.. the program executed correctly, the addresses and values
as printed by the printf() in readstring() were perfectly OK.  Just gdb
showed something wrong - in a program compiled with additional info
for the purpose of debugging with gdb :)

Here's the 'ident gdb' output..

/usr/bin/gdb:
     $FreeBSD: src/lib/libc/i386/string/strrchr.S,v 1.5 1999/08/27 23:59:35 peter Exp $
     $FreeBSD: src/lib/libc/i386/string/strncmp.S,v 1.6 1999/08/27 23:59:35 peter Exp $
     $FreeBSD: src/lib/libc/i386/string/index.S,v 1.5 1999/08/27 23:59:30 peter Exp $
     $FreeBSD: src/lib/libc/i386/string/strcpy.S,v 1.5 1999/08/27 23:59:34 peter Exp $
     $FreeBSD: src/lib/libc/i386/string/strcmp.S,v 1.5 1999/08/27 23:59:33 peter Exp $
     $FreeBSD: src/lib/libc/i386/string/memchr.S,v 1.8 1999/08/27 23:59:31 peter Exp $
     $NetBSD: bcopy.S,v 1.6 1996/11/12 00:50:06 jtc Exp $
     $FreeBSD: src/lib/libc/i386/string/memset.S,v 1.5 1999/08/27 23:59:32 peter Exp $
     $NetBSD: bcopy.S,v 1.6 1996/11/12 00:50:06 jtc Exp $
     $FreeBSD: src/lib/libc/i386/sys/brk.S,v 1.7 1999/08/27 23:59:38 peter Exp $
     $FreeBSD: src/lib/libc/i386/sys/sbrk.S,v 1.7 1999/08/27 23:59:44 peter Exp $
     $FreeBSD: src/lib/libc/i386/sys/cerror.S,v 1.10 1999/08/27 23:59:38 peter Exp $
     $FreeBSD: src/lib/libc/gen/err.c,v 1.6 1999/08/27 23:58:33 peter Exp $
     $FreeBSD: src/lib/libc/i386/gen/isinf.c,v 1.6 1999/08/27 23:59:21 peter Exp $
     $FreeBSD: src/lib/libc/stdio/asprintf.c,v 1.6 1999/08/28 00:00:55 peter Exp $


I do not know which FreeBSD releases are affected by this - I only have
very recent 4.2-STABLE and -current machines :(  And freefall was updated
to a very-very recent 4.2-STABLE just hours before I needed to test :)