🚀 go-pugleaf

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