old-cross-binutils/gdb/testsuite/gdb.base/sym-file-main.c
Pedro Alves 08351840ea Stale breakpoint instructions, spurious SIGTRAPS.
Without the code portion of the patch, we get these failures:

 FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue
 FAIL: gdb.base/break-unload-file.exp: always-inserted on: hbreak: continue
 FAIL: gdb.base/sym-file.exp: stale bkpts: continue to breakpoint: end here

They all looks like random SIGTRAPs:

 continue
 Continuing.

 Program received signal SIGTRAP, Trace/breakpoint trap.
 0x0000000000400541 in foo () at ../../../src/gdb/testsuite/gdb.base/break-unload-file.c:21
 21      }
 (gdb) FAIL: gdb.base/break-unload-file.exp: always-inserted on: break: continue

(This is a regression caused by the remove-symbol-file command
series.)

break-unload-file.exp is about having breakpoints inserted, and then
doing "file".  I caught this while writing a test that does "file
PROGRAM", while PROGRAM was already loaded, which internally does
"file" first, because I wanted to force a breakpoint_re_set, but the
test is more explicit in case GDB ever optimizes out that re-set.

The problem is that unloading the file with "file" ends up in
disable_breakpoints_in_freed_objfile, which marks all breakpoint
locations of the objfile as both shlib_disabled, _and_ clears the
inserted flag, without actually removing the breakpoints from the
inferior.  Now, usually, in all-stop, breakpoints will already be
removed from the inferior before the user can issue the "file"
command, but, with non-stop, or breakpoints always-inserted on mode,
breakpoints stay inserted even while the user has the prompt.  In the
latter case, then, if we let the program continue, and it executes the
address where we had previously set the breakpoint, it'll actually
execute the breakpoint instruction that we left behind...

Now, one issue is that the intent of
disable_breakpoints_in_freed_objfile is really to handle the unloading
of OBJF_USERLOADED objfiles.  These are objfiles that were added with
add-symbol-file and that are removed with remove-symbol-file.

"add-symbol-file"'s docs in the manual clearly say these commands are
used to let GDB know about dynamically loaded code:

 You would use this command when @var{filename} has been dynamically
 loaded (by some other means) into the program that is running.

Similarly, the online help says:

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

So it makes sense to, like when shared libraries are unloaded through
the generic solib machinery, mark the breakpoint locations as
shlib_disabled.  But, the "file" command is not about dynamically
loaded code, it's about the main program.  So the patch makes
disable_breakpoints_in_freed_objfile skip all objfiles but
OBJF_USERLOADED ones, thus skipping the main objfile.

Then, the reason that disable_breakpoints_in_freed_objfile was
clearing the inserted flag isn't clear, but likely to avoid breakpoint
removal errors, assuming remove-symbol-file was called after the
dynamic object was already unmapped from the inferior.  In that case,
it'd okay to simply clear the inserted flag, but not so if the user
for example does remove-symbol-file to remove the library because he
made a mistake in the library's address, and wants to re-do
add-symbol-file with the correct address.

To address all that, I propose an alternative implementation, that
handles both cases.  The patch includes changes to sym-file.exp to
cover them.

This implementation leaves the inserted flag alone, and handles
breakpoint insertion/removal failure gracefully when the locations are
in OBJF_USERLOADED objfiles, just like we handle insertion/removal
failure gracefully for locations in shared libraries.

To try to make sure we aren't patching back stale shadow memory
contents into the inferior, in case the program mapped a different
library at the same address where we had the breakpoint, without the
user having had a chance of remove-symbol-file'ing before, this adds a
new memory_validate_breakpoint function that checks if the breakpoint
instruction is still in memory.  ppc_linux_memory_remove_breakpoint
does this unconditionally for all memory breakpoints, and questions
whether memory_remove_breakpoint should be changed to do this for all
breakpoints.  Possibly yes, though I'm not certain, hence this
baby-steps patch.

Tested on x86_64 Fedora 17, native and gdbserver.

gdb/
2014-04-23  Pedro Alves  <palves@redhat.com>

	* breakpoint.c (insert_bp_location): Tolerate errors if the
	breakpoint is set in a user-loaded objfile.
	(remove_breakpoint_1): Likewise.  Also tolerate errors if the
	location is marked shlib_disabled.  If the breakpoint is set in a
	user-loaded objfile is a GDB-side memory breakpoint, validate it
	before uninsertion.  (disable_breakpoints_in_freed_objfile): Skip
	non-OBJF_USERLOADED objfiles.  Don't clear the location's inserted
	flag.
	* mem-break.c (memory_validate_breakpoint): New function.
	* objfiles.c (userloaded_objfile_contains_address_p): New
	function.
	* objfiles.h (userloaded_objfile_contains_address_p): Declare.
	* target.h (memory_validate_breakpoint): New declaration.

gdb/testsuite/
2014-04-23  Pedro Alves  <palves@redhat.com>

	* gdb.base/break-unload-file.c: New file.
	* gdb.base/break-unload-file.exp: New file.
	* gdb.base/sym-file-lib.c (baz): New function.
	* gdb.base/sym-file-loader.c (struct segment) <mapped_size>: New
	field.
	(load): Store the segment's mapped size.
	(unload): New function.
	(unload_shlib): New function.
	* gdb.base/sym-file-loader.h (unload_shlib): New declaration.
	* gdb.base/sym-file-main.c (main): Unload, and reload the library,
	set a breakpoint at baz, and call it.
	* gdb.base/sym-file.exp: New tests for stale breakpoint
	instructions.
2014-04-23 15:09:27 +01:00

93 lines
2.2 KiB
C

/* Copyright 2013-2014 Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <stdlib.h>
#include <stdio.h>
#include "sym-file-loader.h"
void
gdb_add_symbol_file (void *addr, const char *file)
{
return;
}
void
gdb_remove_symbol_file (void *addr)
{
return;
}
/* Load a shared library without relying on the standard
loader to test GDB's commands for adding and removing
symbol files at runtime. */
int
main (int argc, const char *argv[])
{
const char *file = SHLIB_NAME;
struct library *lib;
char *text_addr = NULL;
int (*pbar) () = NULL;
int (*pfoo) (int) = NULL;
int (*pbaz) () = NULL;
int i;
lib = load_shlib (file);
if (lib == NULL)
return 1;
if (get_text_addr (lib, (void **) &text_addr) != 0)
return 1;
gdb_add_symbol_file (text_addr, file);
/* Call bar from SHLIB_NAME. */
if (lookup_function (lib, "bar", (void *) &pbar) != 0)
return 1;
(*pbar) ();
/* Call foo from SHLIB_NAME. */
if (lookup_function (lib, "foo", (void *) &pfoo) != 0)
return 1;
(*pfoo) (2);
/* Unload the library, invalidating all memory breakpoints. */
unload_shlib (lib);
/* Notify GDB to remove the symbol file. Also check that GDB
doesn't complain that it can't remove breakpoints from the
unmapped library. */
gdb_remove_symbol_file (text_addr);
/* Reload the library. */
lib = load_shlib (file); /* reload lib here */
if (lib == NULL)
return 1;
if (get_text_addr (lib, (void **) &text_addr) != 0)
return 1;
gdb_add_symbol_file (text_addr, file);
if (lookup_function (lib, "baz", (void *) &pbaz) != 0)
return 1;
(*pbaz) ();
return 0; /* end here */
}