This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug symtab/15303] New: file command modifies state even if you reply 'n' to "Load new symbol table ... ?", plus some cleanup
- From: "dje at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 25 Mar 2013 23:32:29 +0000
- Subject: [Bug symtab/15303] New: file command modifies state even if you reply 'n' to "Load new symbol table ... ?", plus some cleanup
- Auto-submitted: auto-generated
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.