- 24 Feb, 2016 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 7.11.
-
GDB Administrator authored
-
- 23 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 22 Feb, 2016 2 commits
-
-
Jan Kratochvil authored
After building GDB --with-python=/usr/bin/python3 and for example stripping ./gdb and running: ./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb. py" ./gdb I get: Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal] File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91 print "Warning: Cannot find enum type_flag_value type." ^ SyntaxError: Missing parentheses in call to 'print' (top-gdb) q gdb/ChangeLog 2016-02-22 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.
-
GDB Administrator authored
-
- 21 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 20 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 19 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 18 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 17 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 16 Feb, 2016 3 commits
-
-
Don Breazeal authored
This patch fixes an internal error that occurs in gdb.threads/forking-threads-plus-breakpoint.exp: /blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 3170.3170 In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170 because it had been overwritten in inferior_appeared, called as follows: inferior_appeared remote_add_inferior remote_notice_new_inferior remote_update_thread_list The cause of the problem was the following sequence of events: * GDB knows only about the main thread * the first fork event is reported to GDB, saved as pending_event * qXfer:threads:read gets the threads from the remote. remove_new_fork_children id's the fork child from the pending event and removes it from the list reported to GDB. All the rest of the threads, including the fork parent, are added to the GDB thread list. * GDB stops all the threads. All the stop events are pushed onto the stop reply queue behind the pending fork event. The fork waitstatus is saved in the fork parent thread's pending status field thread_info.suspend. * remote_wait_ns calls queued_stop_reply and process_stop_reply to remove the fork event from the front of the stop reply queue and save event information in the thread_info structure for the fork parent thread. Unfortunately, none of the information saved in this way is the fork-specific information. * A subsequent qXfer:threads:read packet gets the thread list including the fork parent and fork child. remove_new_fork_children checks the thread list to see if there is a fork parent, doesn't find one, checks the stop reply queue for a pending fork event, doesn't find one, and allows the fork child thread to be reported to GDB before the fork event has been handled. remote_update_thread_list calls remote_notice_new_thread and overwrites the current (main) thread in inferior_appeared. So the fork event has been reported out of target_wait but it was left pending on the infrun side (infrun.c:save_waitstatus). IOW, the fork event hasn't been processed by handle_inferior_event yet, so it hasn't made it to tp->pending_follow yet. The fix is to check thread_info.suspend along with the thread_info.pending_follow in remote.c:remove_new_fork_children, to prevent premature reporting of the fork child thread creation. gdb/ChangeLog: PR remote/19496 * remote.c (remove_new_fork_children): Check for pending fork status in thread_info.suspend. gdb/testsuite/ChangeLog: PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (do_test): Remove kfail for PR remote/19496. -
Yao Qi authored
I see the following error in testing aarch64 GDB debugging arm program. (gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2 continue Continuing. ================================================================= ==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0 #0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M #1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M #2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M #3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M #4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M #5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M #6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M #7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M #8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M #9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M #10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M #11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M #12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M #13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M #14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M #15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M #16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M #17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2) looks we should discard cleanup if function arm_linux_software_single_step returns early, or create cleanup when it is needed. gdb: 2016-02-16 Yao Qi <yao.qi@linaro.org> * arm-linux-tdep.c (arm_linux_software_single_step): Assign 'old_chain' later. -
GDB Administrator authored
-
- 15 Feb, 2016 4 commits
-
-
Jan Kratochvil authored
The testfile has not ran because: gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration] standard (); ^ gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration] stack_align_ecx (); ^ gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration] stack_align_edx (); ^ gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration] stack_align_eax (); ^ gdb/testsuite/ChangeLog 2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/i386-prologue.c: Add missing prototypes.
-
Jan Kratochvil authored
Since commit 2151ccc5 Author: Simon Marchi <simon.marchi@ericsson.com> Date: Mon Feb 8 14:02:36 2016 -0500 Always organize test artifacts in a directory hierarchy these testfiles could not build. gdb/testsuite/ChangeLog 2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.arch/i386-gnu-cfi.exp: Use standard_output_file. * gdb.arch/i386-prologue.exp: Likewise. * gdb.arch/i386-size.exp: Likewise.
-
Simon Marchi authored
Fix the core file path to use the standard output directory. gdb/testsuite/ChangeLog: * i386-biarch-core.exp: Define corefile using standard_output_file.
-
GDB Administrator authored
-
- 14 Feb, 2016 3 commits
-
-
Jan Kratochvil authored
gcc-4.9.2-6.fc21.x86_64 -> gcc-5.3.1-2.fc23.x86_64 -PASS: gdb.fortran/vla-ptype.exp: ptype pvla not initialized +FAIL: gdb.fortran/vla-ptype.exp: ptype pvla not initialized -PASS: gdb.fortran/vla-history.exp: print vla1 allocated +FAIL: gdb.fortran/vla-history.exp: print vla1 allocated -PASS: gdb.fortran/vla-history.exp: print $2 +FAIL: gdb.fortran/vla-history.exp: print $2 -PASS: gdb.fortran/vla-value.exp: print undefined pvla +FAIL: gdb.fortran/vla-value.exp: print undefined pvla -PASS: gdb.fortran/vla-value.exp: print non-associated &pvla +FAIL: gdb.fortran/vla-value.exp: print non-associated &pvla -PASS: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8) +FAIL: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8) These issues get fixed (or removed if no longer applicable) by attached patch. It is based on Googled: http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5 When a pointer is declared its status is undefined, and cannot be safely queried with the associated intrinsic. -> nullify(VARNAME) + https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786 ALLOCATE is not supposed to initialize the array. -> Remove checks like an initial print is: \\( *0, *0, *0...\\) These regressions remain: -PASS: gdb.fortran/library-module.exp: print var_i in lib +FAIL: gdb.fortran/library-module.exp: print var_i in lib -PASS: gdb.fortran/library-module.exp: print var_i in main +FAIL: gdb.fortran/library-module.exp: print var_i in main I believe it is more a GDB bug (in a code contributed by me), filed: gdb.fortran/library-module.exp false regression on GCC upgrade https://sourceware.org/bugzilla/show_bug.cgi?id=19635 gdb/testsuite/ChangeLog 2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com> Fix compatibility with recent gfortran-5.3.1. * gdb.fortran/vla-history.exp (print vla1 allocated) (print vla2 allocated, print $2, print $3): Remove (print $4): Rename to ... (print $2): ... here. (print $9): Rename to ... (print $5): ... here. (print $10): Rename to ... (print $6): ... here. * gdb.fortran/vla.f90: Add pvla initialization.
-
Jan Kratochvil authored
> +static int max_value_size = 65536; /* 64k bytes */ FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array) FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger print array2 value requires 296352 bytes, which is more than max-value-size (gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array) gdb/testsuite/ChangeLog 2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024): New test. * gdb.fortran/vla-value-sub.exp: Likewise.
-
GDB Administrator authored
-
- 13 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 12 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 11 Feb, 2016 1 commit
-
-
GDB Administrator authored
-
- 10 Feb, 2016 10 commits
-
-
Yao Qi authored
We have function regcache_raw_read_unsigned defined in both GDB and GDBserver, so that it is used in common like this, ULONGEST value; status = regcache_raw_read_unsigned (regcache, regnum, &value); 'value' is correctly set in GDB side, but may not be correctly set in GDBserver, because &value is passed in regcache_raw_read_unsigned but collect_register may only set part of the whole variable. In my test, I see the top half of 'value' is garbage. This patch fixes this problem by clearing *VAL before calling collect_register. gdb/gdbserver: 2016-02-10 Yao Qi <yao.qi@linaro.org> * regcache.c (regcache_raw_read_unsigned): Clear *VAL.
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Replace -cvs suffix by -git suffix. -
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 7.10.90.DATE-cvs.
-
Joel Brobecker authored
gdb/ChangeLog: GDB 7.10.90 released.
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 7.10.90.
-
Joel Brobecker authored
gdb/ChangeLog: * NEWS: Change "Changes since GDB version 7.10" into "Changes in GDB version 7.11". -
Joel Brobecker authored
bfd/ChangeLog: * development.sh (development): Set to false.
-
Joel Brobecker authored
Now that the GDB 7.11 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 7.11 branch created (9ef9e6a6): * version.in: Bump version to 7.10.90.DATE-git.
-
Keith Seitz authored
One of the last checks update_breakpoints_after_exec does while looping over the list of breakpoints is check that the breakpoint has a valid location spec. It uses event_location_empty_p to check if the location spec is "empty", and if it is, the breakpoint is deleted. momentary_breakpoint types rely on setting the breakpoint structure's location spec to NULL, thereby causing an update to delete the breakpoint. However, event_location_empty_p assumed that locations were never NULL. As a result, GDB would crash dereferencing a NULL pointer whenever update_breakpoints_after_exec would encounter a momentary_breakpoint. This patch creates a new wrapper/helper function which tests that the given breakpoint's location spec is non-NULL and if it is not "empty" or "unspecified." gdb/ChangeLog PR breakpoints/19546 * breakpoint.c (breakpoint_event_location_empty_p): New function. (update_breakpoints_after_exec, bkpt_re_set): Use this new function instead of event_location_empty_p. gdb/testsuite/ChangeLog PR breakpoints/19546 * gdb.base/infcall-exec.c: New file. * gdb.base/infcall-exec2.c: New file. * gdb.base/infcall-exec.exp: New file.
-
GDB Administrator authored
-
- 09 Feb, 2016 7 commits
-
-
Keith Seitz authored
MI is currently using string_to_event_location to enable the use of legacy linespecs, but using this function (until this patchset) had the (as yet unnoticed) side effect of allowing both MI and CLI representation for explicit locations. This patch simply changes MI to use the same legacy linespec functions that the python and guile interpreters use. This eliminates the CLI syntax for explicit locations (in MI). gdb/ChangeLog * mi/mi-cmd-break.c (mi_cmd_break_insert_1): Use string_to_event_location_basic instead of string_to_event_location.
-
Keith Seitz authored
This patch, analogous to the previous python patch, implements proper legacy linespec support in guile code using the newly introduced string_to_event_location_basic. gdb/ChangeLog * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Skip leading whitespace and use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog * gdb.guile/scm-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address.
-
Keith Seitz authored
Now that "legacy" linespecs benefit from consolidated support in string_to_event_location_basic, python's Breakpoint command should use this function to turn strings into event locations. As a result, this patch fixes python/19506. Before: (gdb) python gdb.Breakpoint("*main") Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Function "*main" not defined. Error while executing Python code. After: (gdb) python gdb.Breakpoint("*main") Breakpoint 1 at 0x4005fb: file ../../../src/gdb/testsuite/gdb.python/py-breakpoint.c, line 32. gdb/ChangeLog PR python/19506 * python/py-breakpoint.c (bppy_init): Use string_to_event_location_basic instead of new_linespec_location. gdb/testsuite/ChangeLog PR python/19506 * gdb.python/py-breakpoint.exp (test_bkpt_address): New procedure. (toplevel): Call test_bkpt_address. -
Keith Seitz authored
This patch refactors string_to_event_location, breaking it into two separate functions: 1) string_to_event_location_basic A "basic" string parser that implements support for "legacy" linespecs (linespec, address, and probe locations). This function is intended to be used by any UI wishing/needing to support this legacy behavior. 2) string_to_event_location This is now intended as a CLI-only function which adds explicit location parsing in a CLI-appropriate manner (in the form of traditional option/value pairs). Together these patches serve to simplify string-to-event location parsing for all existing non-CLI interfaces (MI, guile, and python). gdb/ChangeLog * location.c (string_to_explicit_location): Note that "-p" is reserved for probe locations and return NULL for any input that starts with that. (string_to_event_location): Move "legacy" linespec code to ... (string_to_event_location_basic): ... here. * location.h (string_to_event_location): Update comment. (string_to_event_location_basic): New function.
-
Nick Clifton authored
include * opcode/metag.h (metag_scondtab): Mark as possibly unused. * opcode/nds32.h (nds32_r45map): Likewise. (nds32_r54map): Likewise. * opcode/visium.h (gen_reg_table): Likewise. (fp_reg_table, cc_table, opcode_table): Likewise. bfd * oasys.c (oasys_archive_p): Fix indentation. * elf32-nds32.c (nds32_elf_relax_section): Use an unsigned constant for left shifting.
-
Simon Marchi authored
Using AC_OUTPUT with arguments has been deprecated for some time in autoconf, even in version 2.64, which we are using. This change should not affect functionality. I also removed the "exit 0"'s, they shouldn't be necessary. gdb/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. Remove "exit 0" at the end. * configure: Regenerate. gdb/testsuite/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate. gdb/gdbserver/ChangeLog: * configure.ac: Use AC_CONFIG_FILES instead of passing arguments to AC_OUTPUT. * configure: Regenerate.
-
Pedro Alves authored
PR19548 shows that we still have problems related to 13fd3ff3: [PR17431: following execs with "breakpoint always-inserted on"] https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html The problem this time is that we currently update the global location list and try to insert breakpoint locations after re-setting _each_ breakpoint in turn. Say: - We have _more_ than one breakpoint set. Let's assume 2. - There's a breakpoint with a pre-exec address that ends up being an unmapped address after the exec. - That breakpoint is NOT the first in the breakpoint list. Then when handling an exec, and we re-set the first breakpoint in the breakpoint list, we mistakently try to install the old pre-exec / un-re-set locations of the other breakpoint, which fails: (gdb) continue Continuing. process 28295 is executing new program: (...)/execl-update-breakpoints2 Error in re-setting breakpoint 1: Warning: Cannot insert breakpoint 2. Cannot access memory at address 0x1000764 Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34 34 len = strlen (argv[0]); (gdb) Fix this by deferring the global location list update till after all breakpoints are re-set. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * breakpoint.c (create_overlay_event_breakpoint): Don't update global location list here. (create_longjmp_master_breakpoint) (create_std_terminate_master_breakpoint) (create_exception_master_breakpoint, create_jit_event_breakpoint) (update_breakpoint_locations): (breakpoint_re_set): Update global location list after all breakpoints are re-set. gdb/testsuite/ChangeLog: 2016-02-09 Pedro Alves <palves@redhat.com> PR breakpoints/19548 * gdb.base/execl-update-breakpoints.c (some_function): New function. (main): Call it. * gdb.base/execl-update-breakpoints.exp: Add a second breakpoint. Tighten expected GDB output.
-