This is the mail archive of the gdb-patches@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] |
How about this? Up front questions: What's the reason for passing from_tty=0 to symbol_file_add_main from captured_main? What do folks think about having gdb print an extra line when starting up? i.e. adding: Reading symbols from /home/dje/src/hello.x64...done. Or, when no debugging symbols are found: Reading symbols from /home/dje/src/hello.x64...(no debugging symbols found) ...done. [gdb would previously print "(not debugging symbols found)"] This patch passes !batch for from_tty to symbol_file_add_main from captured_main. This is done so that the code in symbol_file_add_with_addrs_or_offsets doesn't have to test (flags & SYMFILE_MAINLINE): this is to handle the example of running make and getting lots of "no debugging symbols found" warnings [the high order bit being: if from_tty == 0, does it matter whether or not the file is the main executable when printing "no debugging symbols found"?] This partially reverts my patch of 2008-07-10 that added the option "set print symbol-loading". In its place I changed symbol-loading to symbol-loading-warnings and made it only apply when from_tty == 0. And I set the default to "off". If from_tty == 1, the request is from the user directly (more or less), and the user more likely wants to know if no debugging symbols are found. Plus if from_tty == 1, the user is already getting the text "Reading ..." so why test the "set print ..." option? Also note that if the main executable has debug info, the user will (currently) never see "no debugging symbols found" warnings for shared libs - thus any change in gdb's behaviour due to what we choose for the default value of this option only affects the case of debugging executables without debugging info. This patch removes the bogusness of whether one sees "no debugging symbols found" for shared libs depends on whether the main executable is stripped and on the order the shared libs are loaded: the patch tests the objfile being loaded rather than calling have_partial_symbols/have_full_symbols. This patch also includes the name of the file without debugging symbols in the "no debugging symbols found" message. Thoughts (especially about my first two questions) ? 2009-06-18 Doug Evans <dje@google.com> * objfiles.h (objfile_has_partial_symbols): Declare. (objfile_has_full_symbols): Declare. * objfiles.c (objfile_has_partial_symbols): New function. (have_partial_symbols): Use it. (objfile_has_full_symbols): New function. (have_full_symbols): Use it. * main.c (captured_main): Pass !batch for from_tty when calling symbol_file_add_main. * solib.c (solib_read_symbols): Back out patch of 2008-07-10. * symfile.c (print_symbol_loading_warnings): Renamed from print_symbol_loading, initialize to 0 instead of 1. (symbol_file_add_with_addrs_or_offsets): Back out patch of 2008-07-10. Print "no debugging symbols found" only if from_tty || info_verbose || print_symbol_loading_warnings, and include the file name if not already printed. (reread_symbols): Test file being loaded for whether it has symbols, not all files. (__initialize_symfile): Update name of `set print symbol-loading-warnings'. * NEWS: Update name of `set print symbol-loading-warnings'. * doc/gdb.texinfo: Update name of `set print symbol-loading-warnings'.
Attachment:
gdb-090618-symfile-6.patch.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |