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

"$ 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.