zs01+@ANDREW.CMU.EDU (Zalman Stern) (09/09/89)
There is a bug in the add-file command where it modifies the global
variable first_object_file_end to point to the end of the first .o file
in the added file. I believe this is wrong because first_object_file_end
is used to allow gdb to ignore wierdness having to do with crt0.o (for
example, I think it decides where to stop climbing the stack in a stack
trace by noticing when the return address on the stack is in crt0.o). In
the case of add-file, this makes gdb think that most of your program is
crt0.o and things behave very badly. My understanding of this is not the
greatest, but I think the problem can be fixed by nuking anything having
to do with num_object_files in read_addl_syms in dbxread.c . An untested
diff for version 3.1.2 gdb's dbxread.c follows.
Sincerely,
Zalman Stern
Internet: zs01+@andrew.cmu.edu Usenet: I'm soooo confused...
Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890
*** dbxread.c Wed Mar 22 18:02:39 1989
--- dbxread.c.new Fri Sep 8 18:09:15 1989
***************
*** 2974,2980 ****
register char *namestring;
register struct symbol *sym, *prev;
int hash;
- int num_object_files = 0;
#ifdef N_BINCL
subfile_stack = 0;
--- 2974,2979 ----
***************
*** 3024,3031 ****
&& (!strcmp (namestring + strlen (namestring) - 2, ".o"))
|| ! strcmp (namestring, "-l", 2))
{
- if (num_object_files++ == 1)
- first_object_file_end = bufp->n_value;
if (last_source_file)
end_symtab (bufp->n_value);
}
--- 3023,3028 ----