"$ gdb PROGRAM" vs "(gdb) file PROGRAM" difference; warn on failure to remove breakpoint.

Turns out there's a difference between loading the program with "gdb
PROGRAM", vs loading it with "(gdb) file PROGRAM".  The latter results
in the objfile ending up with OBJF_USERLOADED set, while not with the
former.  (That difference seems bogus, but still that's not the point
of this patch.  We can revisit that afterwards.)

The new code that suppresses breakpoint removal errors for
add-symbol-file objects ends up being too greedy:

      /* In some cases, we might not be able to remove a breakpoint in
         a shared library that has already been removed, but we have
         not yet processed the shlib unload event.  Similarly for an
         unloaded add-symbol-file object - the user might not yet have
         had the chance to remove-symbol-file it.  shlib_disabled will
         be set if the library/object has already been removed, but
         the breakpoint hasn't been uninserted yet, e.g., after
         "nosharedlibrary" or "remove-symbol-file" with breakpoints
         always-inserted mode.  */
      if (val
          && (bl->loc_type == bp_loc_software_breakpoint
              && (bl->shlib_disabled
                  || solib_name_from_address (bl->pspace, bl->address)
                  || userloaded_objfile_contains_address_p (bl->pspace,
                                                            bl->address))))
        val = 0;

as it turns out that OBJF_USERLOADED can be set for objfiles loaded by
some other means not add-symbol-file.  In this case, symbol-file (or
"file", which is really just "exec-file"+"symbol-file").

Recall that add-symbol-file is documented as:

 (gdb) help add-symbol-file
 Load symbols from FILE, assuming FILE has been dynamically loaded.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And it's the "dynamically loaded" aspect that the breakpoint.c code
cares about.  So make add-symbol-file set OBJF_SHARED on its objfiles
too, and tweak the breakpoint.c code to look for OBJF_SHARED instead
of OBJF_USERLOADED.

This restores back the missing breakpoint removal warning when we let
sss-bp-on-user-bp-2.exp run on native GNU/Linux
(https://sourceware.org/ml/gdb-patches/2014-06/msg00335.html):

 (gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
 stepi_del_break
 warning: Error removing breakpoint 3
 (gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: stepi_del_break

I say "restores" because this was GDB's behavior in 7.7 and earlier.

And, likewise, "file" with no arguments only started turning
breakpoints set in the main executable to "<pending>" with the
remote-symbol-file patch (63644780).  The old behavior is now
restored, and we break-unload-file.exp test now exercizes both "gdb;
file PROGRAM" and "gdb PROGRAM".

gdb/
2014-06-16  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (insert_bp_location, remove_breakpoint_1): Adjust.
	(disable_breakpoints_in_freed_objfile): Skip objfiles that don't
	have OBJF_SHARED set.
	* objfiles.c (userloaded_objfile_contains_address_p): Rename to...
	(shared_objfile_contains_address_p): ... this.  Check OBJF_SHARED
	instead of OBJF_USERLOADED.
	* objfiles.h (OBJF_SHARED): Update comment.
	(userloaded_objfile_contains_address_p): Rename to ...
	(shared_objfile_contains_address_p): ... this, and update
	comments.
	* symfile.c (add_symbol_file_command): Also set OBJF_SHARED in the
	new objfile.
	(remove_symbol_file_command): Skip objfiles that don't have
	OBJF_SHARED set.

gdb/testsuite/
2014-06-16  Pedro Alves  <palves@redhat.com>

	* gdb.base/break-main-file-remove-fail.c: New file.
	* gdb.base/break-main-file-remove-fail.exp: New file.
	* gdb.base/break-unload-file.exp: Use build_executable instead of
	prepare_for_testing.
	(test_break): New parameter "initial_load".  Handle it.
	(top level): Add initial_load cmdline/file axis.

1 files changed, 7 insertions, 11 deletions

diff --git a/gdb/objfiles.h b/gdb/objfiles.h
index 6684278abf..57a94e1409 100644
--- a/gdb/objfiles.h
+++ b/gdb/objfiles.h
@@ -427,12 +427,9 @@ struct objfile
 #define OBJF_REORDERED	(1 << 0)	/* Functions are reordered */
 
 /* Distinguish between an objfile for a shared library and a "vanilla"
-   objfile.  (If not set, the objfile may still actually be a solib.
-   This can happen if the user created the objfile by using the
-   add-symbol-file command.  GDB doesn't in that situation actually
-   check whether the file is a solib.  Rather, the target's
-   implementation of the solib interface is responsible for setting
-   this flag when noticing solibs used by an inferior.)  */
+   objfile.  This may come from a target's implementation of the solib
+   interface, from add-symbol-file, or any other mechanism that loads
+   dynamic objects.  */
 
 #define OBJF_SHARED     (1 << 1)	/* From a shared library */
 
@@ -515,12 +512,11 @@ extern void objfiles_changed (void);
 
 extern int is_addr_in_objfile (CORE_ADDR addr, const struct objfile *objfile);
 
-/* Return true if ADDRESS maps into one of the sections of the
-   userloaded ("add-symbol-file") objfiles of PSPACE and false
-   otherwise.  */
+/* Return true if ADDRESS maps into one of the sections of a
+   OBJF_SHARED objfile of PSPACE and false otherwise.  */
 
-extern int userloaded_objfile_contains_address_p (struct program_space *pspace,
-						  CORE_ADDR address);
+extern int shared_objfile_contains_address_p (struct program_space *pspace,
+					      CORE_ADDR address);
 
 /* This operation deletes all objfile entries that represent solibs that
    weren't explicitly loaded by the user, via e.g., the add-symbol-file