aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/break-unload-file.exp
AgeCommit message (Collapse)AuthorFilesLines
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-01-01Update year range in copyright notice of all files owned by the GDB project.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2014-06-16"$ gdb PROGRAM" vs "(gdb) file PROGRAM" difference; warn on failure to ↵Pedro Alves1-21/+50
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.
2014-06-06break-unload-file.exp: Fix typo.Pedro Alves1-1/+1
s/is not pending/is pending/ gdb/testsuite/ 2014-06-06 Pedro Alves <palves@redhat.com> * gdb.base/break-unload-file.exp: Fix typo.
2014-04-23Stale breakpoint instructions, spurious SIGTRAPS.Pedro Alves1-0/+128
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.