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