This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug symtab/15303] New: file command modifies state even if you reply 'n' to "Load new symbol table ... ?", plus some cleanup


http://sourceware.org/bugzilla/show_bug.cgi?id=15303

             Bug #: 15303
           Summary: file command modifies state even if you reply 'n' to
                    "Load new symbol table ... ?", plus some cleanup
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dje@google.com
    Classification: Unclassified


There's a FIXME in file_command:

static void
file_command (char *arg, int from_tty)
{
  /* FIXME, if we lose on reading the symbol file, we should revert             
     the exec file, but that's rough.  */
  exec_file_command (arg, from_tty);
  symbol_file_command (arg, from_tty);
  if (deprecated_file_changed_hook)
    deprecated_file_changed_hook (arg);
}

A better way to fix this than reverting the exec file is to do the error check
before modifying any state.

Also, symbol_file_add_with_addrs_or_offsets feels like too low a level to be
asking this question:

  if ((have_full_symbols () || have_partial_symbols ())
      && mainline
      && from_tty
      && !query (_("Load new symbol table from \"%s\"? "), name))
    error (_("Not confirmed."));

Moving this question up (and into a separate routine callable from
file_command) also has the benefit of simplifying this caller:

  /* We need to clear SYMFILE_MAINLINE to avoid interractive question           
     from symfile.c:symbol_file_add_with_addrs_or_offsets.  */
  cleanup = make_cleanup_bfd_unref (abfd);
  symbol_file_add_from_bfd
    (abfd, symfile_flags & ~(SYMFILE_MAINLINE | SYMFILE_VERBOSE), NULL,
     main_objfile->flags & (OBJF_REORDERED | OBJF_SHARED
                            | OBJF_READNOW | OBJF_USERLOADED),
     main_objfile);

Also, there are a couple of places that pass SYMFILE_MAINLINE instead of
calling symbol_file_add_main* (the * is there because maybe we'll want to
rename symbol_file_add_main_1, whatever).
This leads to a bit of code duplication in follow_exec:

  if ((inf->symfile_flags & SYMFILE_NO_READ) == 0)
    set_initial_language ();

There's no comment in follow_exec that says calling symbol_file_add_main* is
the wrong thing to do - if it is, it needs to be documented.

I haven't put any thought into the other places that use SYMFILE_MAIN, those
would need to be addressed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]