aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-11-03Import updated translations supplied by the Translation Project.Nick Clifton12-3411/+5630
bfd, binutils, gprof, opcodes: * po/fi.po: Updated Finnish translation. binutils: * po/sv.po: Updated Swedish translation. gprof: * po/hu.po: New Hungarian translation.
2014-11-03Add missing changelog entriesYao Qi1-0/+17
Some changelog entries are missing in previous commits. Add them.
2014-11-03Fixes a snafu checking the size of 20-bit immedaite values.Nick Clifton2-1/+6
* config/tc-msp430.c (msp430_srcoperand): Fix range test for 20-bit values.
2014-11-02mdebugread.c (parse_procedure): Delete unnecessary forward decl.Doug Evans2-2/+4
gdb/ChangeLog: * mdebugread.c (parse_procedure): Delete unnecessary forward decl.
2014-11-02xcoffread.c (process_linenos): Delete unnecessary code.Doug Evans2-3/+5
gdb/ChangeLog: * xcoffread.c (process_linenos): Delete unnecessary zeroing of main_subfile before returning.
2014-11-03daily updateAlan Modra1-1/+1
2014-11-02read_pieced_value do big endian processing only in case of valid gdb_regnumVictor Kamensky1-17/+20
During armv7b testing gdb.base/store.exp test was failling with 'GDB internal error' with the following message: Temporary breakpoint 1, wack_double (u= ../../binutils-gdb/gdb/regcache.c:177: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. It turns out that compiler generated DWARF with non-existent register numbers. The compiler issue is present in both little endian (armv7) and big endian (armv7b) (it is separate issue). Here is example for one of formal parameters of wack_double function: <2><792>: Abbrev Number: 10 (DW_TAG_formal_parameter) <793> DW_AT_name : u <795> DW_AT_decl_file : 1 <796> DW_AT_decl_line : 115 <797> DW_AT_type : <0x57c> <79b> DW_AT_location : 6 byte block: 6d 93 4 6c 93 4 (DW_OP_reg29 (r29); DW_OP_piece: 4; DW_OP_reg28 (r28); DW_OP_piece: 4) In both big and little endian cases gdbarch_dwarf2_reg_to_regnum returns -1 which is stored into gdb_regnum. But it causes severe problem only in big endian case because in read_pieced_value and write_pieced_value functions BFD_ENDIAN_BIG related processing happen regardless of gdb_regnum value, for example register_size function is called and in case of gdb_regnum=-1, it cause 'GDB internal error' and crash. Solution is to move BFD_ENDIAN_BIG related processing under (gdb_regnum != -1) branch of processing. gdb/ChangeLog: 2014-11-02 Victor Kamensky <victor.kamensky@linaro.org> * dwarf2loc.c (read_pieced_value): Do big endian processing only if gdb_regnum is not -1. (write_pieced_value): Ditto.
2014-11-02ARM: arm_breakpoint should be little endian form in case for arm BE8Victor Kamensky1-1/+1
tdep->arm_breakpoint, tdep->thumb_breakpoint, tdep->thumb2_breakpoint should be set le_ variants in case of arm BE8 code. Those instruciton sequences are writen to target with simple write_memory, without regarding gdbarch_byte_order_for_code. But in BE8 case even data memory is in big endian form, instructions are still in little endian form. Because of this issue there are many issues while running gdb test case in armv7b mode. For example gdb.arch/arm-disp-step.exp test fails because it gets SIGILL when displaced instrucion sequence reaches break instruction, which is in wrong byte order. Solution is to set tdep->xxx_breakpoint sequences in BE8 case (i.e when gdbarch_byte_order_for_code is BFD_ENDIAN_BIG. gdb/ChangeLog: 2014-11-02 Victor Kamensky <victor.kamensky@linaro.org> * arm-linux-tdep.c (arm_linux_init_abi): Use info.byte_order_for_code to choose endianity of breakpoint instructions snippets.
2014-11-02ARM: extract_arm_insn function need to read instrs correctly in be8 caseVictor Kamensky1-1/+1
extract_arm_insn function needs to read instructions in gdbarch_byte_order_for_code byte order, because in case armv7b, even data is big endian, instructions are still little endian. Currently function uses gdbarch_byte_order which would be big endian in armv7b case. Because of this issue pretty much all gdb.reverse/ tests are failing with 'Process record does not support instruction' message. Fix is to change gdbarch_byte_order to gdbarch_byte_order_for_code, when passed to extract_unsigned_integer that reads instruction. gdb/ChangeLog: 2014-11-02 Victor Kamensky <victor.kamensky@linaro.org> * arm-tdep.c (extract_arm_insn): Use gdbarch_byte_order_for_code to read arm instruction.
2014-11-02Match the working directory on remote hostYao Qi2-1/+13
The test in gdb.python/python.exp tests "extended-prompt" and expects working directory is printed. However, working directory on remote host doesn't have "gdb/testsuite", so the test fails on remote host like: set extended-prompt \w ^M ^M /home/yao FAIL: gdb.python/python.exp: set extended prompt working directory (timeout) This patch is to get the working directory first, and use it to match the output of "set extended-prompt \\w ". It works for remote host and non remote host. gdb/testsuite: 2014-11-02 Yao Qi <yao@codesourcery.com> * gdb.python/python.exp: Get working directory and match the output of "set extended-prompt \\w " with it.
2014-11-02daily updateAlan Modra1-1/+1
2014-10-31objfiles.h: Remove some unused macros.Doug Evans2-13/+5
gdb/ChangeLog: * objfiles.h (ALL_PSPACE_OBJFILES_SAFE): Delete, unused. (ALL_PSPACE_SYMTABS, ALL_PSPACE_PRIMARY_SYMTABS): Ditto.
2014-10-31valops.c: Fix some whitespace.Doug Evans2-6/+12
gdb/ChangeLog: * valops.c (value_cast_pointers): Fix whitespace. (typecmp, search_struct_method, value_struct_elt, find_oload_champ): Ditto.
2014-11-01Fix %lx format used with bfd_size_type mismatch in readelf.cHans-Peter Nilsson2-2/+8
* readelf.c (get_32bit_elf_symbols): Cast error parameters of bfd_size_type with the %lx format to unsigned long.
2014-11-01daily updateAlan Modra1-1/+1
2014-10-31MIPS: Add Octeon 3 supportNaveen H.S20-4/+146
binutils: 2014-10-31 Andrew Pinski <apinski@cavium.com> Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com> * readelf.c (print_mips_isa_ext): Print the value of Octeon3. gas: 2014-10-31 Andrew Pinski <apinski@cavium.com> Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com> * config/tc-mips.c (CPU_IS_OCTEON): Handle CPU_OCTEON3. (mips_cpu_info_table): Octeon3 enables virt ase. * doc/c-mips.texi: Document octeon3 as an acceptable value for -march=. gas/testsuite: 2014-10-31 Andrew Pinski <apinski@cavium.com> Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com> * gas/mips/mips.exp: Add support for Octeon3 architecture. Also add in support for running Octeon3 tests. * gas/mips/octeon3.d: New test. * gas/mips/octeon3.s: New test source. opcodes: 2014-10-31 Andrew Pinski <apinski@cavium.com> Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com> * mips-dis.c (mips_arch_choices): Add octeon3. * mips-opc.c (IOCT): Include INSN_OCTEON3. (IOCT2): Likewise. (IOCT3): New define. (IVIRT): New define. (mips_builtin_opcodes): Add dmfgc0, dmtgc0, hypcall, mfgc0, mtgc0, tlbinv, tlbinvf, tlbgr, tlbgwi, tlbginv, tlbginvf, tlbgwr, tlbgp, tlti IVIRT instructions. Extend mtm0, mtm1, mtm2, mtp0, mtp1, mtp2 instructions to take another operand for IOCT3. bfd: 2014-10-31 Andrew Pinski <apinski@cavium.com> Naveen H.S <Naveen.Hurugalawadi@caviumnetworks.com> * archures.c: Add octeon3 for mips target. * bfd-in2.h: Regenerate. * bfd/cpu-mips.c: Define I_mipsocteon3. nfo_struct): Add octeon3 support. * bfd/elfxx-mips.c: (_bfd_elf_mips_mach): Add support for octeon3. (mips_set_isa_flags): Add support for octeon3. (bfd_mips_isa_ext): Add bfd_mach_mips_octeon3. (mips_mach_extensions): Make bfd_mach_mips_octeon3 an extension of bfd_mach_mips_octeon2. (print_mips_isa_ext): Print the value of Octeon3.
2014-10-31Add forgotten changelog entry.Andrew Pinski1-0/+7
2014-10-21 Andrew Pinski <apinski@cavium.com> * config/tc-aarch64.c (aarch64_cpus): Add thunderx. * doc/c-aarch64.texi: Document that thunderx is a valid processor name.
2014-10-31Add dlang demangling support to c++filt.Iain Buclaw2-0/+5
binutils/ChangeLog: * cxxfilt.c (main): Add case for dlang_demangling style.
2014-10-31Fix an (almost) infinite loop in the tekhex parser.Nick Clifton2-0/+4
PR binutils/17512 * tekhex.c (first_phase): Check that the section range is sane.
2014-10-31Avoid allocating over-large buffers when parsing corrupt binaries.Nick Clifton5-4/+55
PR binutils/17512 * coffgen.c (_bfd_coff_get_external_symbols): Do not try to load a symbol table bigger than the file. * elf.c (bfd_elf_get_str_section): Do not try to load a string table bigger than the file. * readelf.c (process_program_headers): Avoid memory exhaustion due to corrupt values in a dynamis segment header. (get_32bit_elf_symbols): Do not attempt to read an over-large section. (get_64bit_elf_symbols): Likewise.
2014-10-31oops - changelog omitted from previous delta.Nick Clifton1-0/+15
2014-10-31In response to a public outcry the strings program now defaults to using theNick Clifton6-17/+106
--all option which displays text from anywhere in the input file(s). The default used to be --data, which only displays text from loadable data sections, but this requires the use of the BFD library. Since the BFD library almost certainly still contains buffer overrun and/or memory corruption bugs, and since the strings program is often used to examine malicious code, it was decided that the --data option option represents a possible security risk. * strings.c: Add new command line option --data to only scan the initialized, loadable data secions of binaries. Choose the default behaviour of --all or --data based upon a configure option. * doc/binutils.texi (strings): Update documentation. Include description of why the --data option might be unsafe. * configure.ac: Add new option --disable-default-strings-all which restores the old behaviour of strings using --data by default. If the option is not used make strings use --all by default. * NEWS: Mention the new behaviour of strings. * configure: Regenerate. * config.in: Regenerate.
2014-10-30Add ability to add attributes to gdb.Objfile and gdb.Progspace objects.Doug Evans9-3/+130
gdb/ChangeLog: * NEWS: Mention ability add attributes to gdb.Objfile and gdb.Progspace objects. * python/py-objfile.c (objfile_object): New member dict. (objfpy_dealloc): Py_XDECREF dict. (objfpy_initialize): Initialize dict. (objfile_getset): Add __dict__. (objfile_object_type): Set tp_dictoffset member. * python/py-progspace.c (progspace_object): New member dict. (pspy_dealloc): Py_XDECREF dict. (pspy_initialize): Initialize dict. (pspace_getset): Add __dict__. (pspace_object_type): Set tp_dictoffset member. gdb/doc/ChangeLog: * python.texi (Progspaces In Python): Document ability to add random attributes to gdb.Progspace objects. (Objfiles In Python): Document ability to add random attributes to gdb.objfile objects. gdb/testsuite/ChangeLog: * gdb.python/py-objfile.exp: Add tests for setting random attributes in objfiles. * gdb.python/py-progspace.exp: Add tests for setting random attributes in progspaces.
2014-10-31daily updateAlan Modra1-1/+1
2014-10-30Fixes a seg-fault in the ihex parser when it encounters a malformed ihex file.Nick Clifton2-1/+2
PR binutils/17512 * ihex.c (ihex_scan): Fix typo in invocation of ihex_bad_byte.
2014-10-30Closes another memory corruption, this time due to heap overrun.Nick Clifton2-2/+11
PR binutils/17512 * coffgen.c (coff_get_normalized_symtab): Prevent buffer overrun.
2014-10-30Skip tests that use cd for remote hostsLuis Machado4-0/+21
Several GDB tests change directory before compiling the test program in order to test source file names that include directories. This doesn't work on a remote host because default_target_compile in DejaGnu's target.exp copies each source file with "[remote_download host $x]" which uses "[file tail $file] to strip off the directory of each file. If the source directory is remote mounted on the host, this also leaves copied files in the source directory. A similar skip is already used in gdb.test/fullname.exp: # We rely on being able to copy things around. if { [is_remote host] } { untested "setting breakpoints by full path" return -1 } This patch causes three GDB tests that use "cd" to be skipped for a remote host. For gdb.base/fullpath-expand.exp this eliminates two failures and prevents the test from leaving files fullpath-expand.c and fullpath-expand-func.c in gdb/testsuite. For gdb.base/realname-expand.exp it eliminates two failures. For gdb.linespec/macro-relative.exp it prevents file macro-relative.c from being left in gdb/testsuite/gdb.linespec/base/two. gdb/testsuite/ * gdb.base/fullpath-expand.exp: Skip for a remote host. * gdb.base/realname-expand.exp: Likewise. * gdb.linespec/macro-relative.exp: Likewise.
2014-10-30ld/testsuite/ld-unique: Fix running unique tests on ARMWill Newton4-3/+10
The @ character is a comment character on ARM, so use % instead. Also use a wider glob for matching ARM targets to make sure the test gets run. ld/testsuite/ChangeLog: 2014-10-30 Will Newton <will.newton@linaro.org> * ld-unique/unique.exp: Use a wider glob for matching ARM targets. * ld-unique/unique.s: Use % instead of @ in .type directive. * ld-unique/unique_shared.s: Likewise.
2014-10-30Remove the artificial limit on code alignment through the use of theDr Philipp Tomsich3-46/+35
fixed part of a fragment for output generation only, which required MAX_MEM_FOR_RS_ALIGN_CODE to be large enough to hold the maximum pad. * config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define to 7. * config/tc-aarch64.c (aarch64_handle_align): Rewrite to handle large alignments with a constant fragment size of MAX_MEM_FOR_RS_ALIGN_CODE.
2014-10-30Fix error message strings so that they can be translated properly.Nick Clifton2-12/+26
* readelf.c (CHECK_ENTSIZE_VALUES): Rewrite error message so that there is a single string for translation. (dynamic_section_mips_val): Likewise.
2014-10-30Don't replace '\' with '\\' in before_prompt_hookYao Qi2-2/+6
In gdb/command/prompt.py:before_prompt_hook, the '\' in the new prompt is replaced with '\\', shown as below, > def before_prompt_hook(self, current): > if self.value is not '': > newprompt = gdb.prompt.substitute_prompt(self.value) > return newprompt.replace('\\', '\\\\') > else: > return None I don't see any explanations on this in comments nor email. As doc said, "set extended-prompt \w" substitute the current working directory, but it prints something different from what pwd or os.getcwdu() prints on mingw32 host. (gdb) python print os.getcwdu()^M \\build2-lucid-cs\yqi\yqi\arm-none-eabi (gdb) pwd^M Working directory \\build2-lucid-cs\yqi\yqi\arm-none-eabi (gdb) set extended-prompt \w \\\\build2-lucid-cs\\yqi\\yqi\\arm-none-eabi This makes me think whether the substitution in before_prompt_hook is necessary or not. This patch is to remove this substitution. Run gdb.python on x86_64-linux and arm-none-eabi on mingw32 host. No regressions. gdb: 2014-10-30 Yao Qi <yao@codesourcery.com> * python/lib/gdb/command/prompt.py (before_prompt_hook): Don't replace '\\' with '\\\\'.
2014-10-30daily updateAlan Modra1-1/+1
2014-10-29Fixes another memory corruption bug introduced by patches for PR 17512.Nick Clifton2-2/+7
* elf.c (bfd_section_from_shdr): Fix heap use after free memory leak.
2014-10-29Document the GDB 7.8.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.8.1 released.
2014-10-29Misc about gold for aarch64 backend.Han Shen5-142/+660
The patch does the following things: -- Add support for ifunc. -- Enable safe icf -- Add support for TLSLD relocations R_AARCH64_TLSLD_ADR_PAGE21, R_AARCH64_TLSLD_ADD_LO12_NC, R_AARCH64_TLSLD_MOVW_DTPREL_G1, R_AARCH64_TLSLD_MOVW_DTPREL_G0_NC. (R_AARCH64_TLSLD_MOVW_* are used by LLVM.) -- Add support for TLSLD->TLSLE relaxation. -- Add support for R_AARCH64_LD_PREL_LO19, R_AARCH64_ADR_PREL_LO21. -- Fix 2 encoding bugs in AArch64_relocate_functions::update_movnz. -- Correct TLS relocation properties in gold/aarch64-reloc.def. -- Update testsuite/icf_safe_so_test.cc, testsuite/icf_safe_test.sh. gold/ 2014-10-29 Han Shen <shenhan@google.com> Jing Yu <jingyu@google.com> * aarch64-reloc.def: Add LD_PREL_LO12, ADR_PREL_LO21, TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. Change property of TLS relocations to Symbol::TLS_REF. * aarch64.cc (Target_aarch64::do_can_check_for_function_pointers): New method. (Target_aarch64::reloc_needs_plt_for_ifunc): New method. (Target_aarch64::tls_ld_to_le): New method. (Target_aarch64::aarch64_info): Enable can_icf_inline_merge_sections for 64bit targets. (Output_data_plt_aarch64::irelative_rel_): New data member. (Output_data_plt_aarch64::add_entry): Add irelative entries to plt. (Output_data_plt_aarch64::add_local_ifunc_entry): New method. (Output_data_plt_aarch64::add_relocation): New method. (Output_data_plt_aarch64::do_write): Add gold_assert on got_irelative offset. Add got_irelative size to got size. (AArch64_relocate_functions): Typedef AArch64_valtype. Replace long type string with the new typename. (AArch64_relocate_functions::update_adr): Replace parameter x with immed. (AArch64_relocate_functions::update_movnz): Correct wrong val mask. (AArch64_relocate_functions::reloc_common): New method. (AArch64_relocate_funcsions::rela_general): Extract common part out into reloc_common method. (AArch64_relocate_functions::rela_general): Likewise. (AArch64_relocate_functions::pcrela_general): Likewise. (AArch64_relocate_functions::adr): New method. (AArch64_relocate_functions::adrp): Calculate immed before calling update_adr. (AArch64_relocate_functions::adrp): Likewise. (AArch64_relocate_functions::movnz): Cast x to SignedW type when comparing x to 0. Calculate immed from ~x when x < 0. (Target_aarch64::optimize_tls_reloc): Add new cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. (Target_aarch64::possible_function_pointer_reloc): Implement this method. (Target_aarch64::Scan::local_reloc_may_be_function_pointer): Update comment. (Target_aarch64::Scan::local): Add codes to handle STT_GNU_IFUNC symbol. Add cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. (Target_aarch64::Scan::global): Add codes to handle STT_GNU_IFUNC symbol. Add cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. (Target_aarch64::make_plt_entry): Call add_entry with two more parameters. (Target_aarch64::make_local_ifunc_plt_entry): New method. (Target_aarch64::Relocate::relocate): Add cases for LD_PREL_LO19, ADR_PREL_LO21, TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. (Target_aarch64::Relocate::relocate_tls): Add cases for TLSLD_ADR_PAGE21, TLSLD_ADD_LO12_NC, TLSLD_MOVW_DTPREL_G1, TLSLD_MOVW_DTPREL_G0_NC. * testsuite/icf_safe_so_test.cc: Correct test comment. * testsuite/icf_safe_test.sh: Add AArch64 arch.
2014-10-29This PR shows that GDB can easily trigger an assertion here, inPedro Alves2-0/+35
infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29PR 17408 - assertion failure in switch_back_to_stepped_threadPedro Alves5-121/+254
This PR shows that GDB can easily trigger an assertion here, in infrun.c: 5392 /* Did we find the stepping thread? */ 5393 if (tp->control.step_range_end) 5394 { 5395 /* Yep. There should only one though. */ 5396 gdb_assert (stepping_thread == NULL); 5397 5398 /* The event thread is handled at the top, before we 5399 enter this loop. */ 5400 gdb_assert (tp != ecs->event_thread); 5401 5402 /* If some thread other than the event thread is 5403 stepping, then scheduler locking can't be in effect, 5404 otherwise we wouldn't have resumed the current event 5405 thread in the first place. */ 5406 gdb_assert (!schedlock_applies (currently_stepping (tp))); 5407 5408 stepping_thread = tp; 5409 } Like: gdb/infrun.c:5406: internal-error: switch_back_to_stepped_thread: Assertion `!schedlock_applies (1)' failed. The way the assertion is written is assuming that with schedlock=step we'll always leave threads other than the one with the stepping range locked, while that's not true with the "next" command. With schedlock "step", other threads still run unlocked when "next" detects a function call and steps over it. Whether that makes sense or not, still, it's documented that way in the manual. If another thread hits an event that doesn't cause a stop while the nexting thread steps over a function call, we'll get here and fail the assertion. The fix is just to adjust the assertion. Even though we found the stepping thread, we'll still step-over the breakpoint that just triggered correctly. Surprisingly, gdb.threads/schedlock.exp doesn't have any test that steps over a function call. This commits fixes that. This ensures that "next" doesn't switch focus to another thread, and checks whether other threads run locked or not, depending on scheduler locking mode and command. There's a lot of duplication in that file that this ends cleaning up. There's more that could be cleaned up, but that would end up an unrelated change, best done separately. This new coverage in schedlock.exp happens to trigger the internal error in question, like so: FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (1) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (3) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (5) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (7) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next to increment (9) (GDB internal error) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: next does not change thread (switched to thread 0) FAIL: gdb.threads/schedlock.exp: schedlock=step: cmd=next: call_function=1: current thread advanced - unlocked (wrong amount) That's because we have more than one thread running the same loop, and while one thread is stepping over a function call, the other thread hits the step-resume breakpoint of the first, which needs to be stepped over, and we end up in switch_back_to_stepped_thread exactly in the problem case. I think a simpler and more directed test is also useful, to not rely on internal breakpoint magics. So this commit also adds a test that has a thread trip on a conditional breakpoint that doesn't cause a user-visible stop while another thread is stepping over a call. That currently fails like this: FAIL: gdb.threads/next-bp-other-thread.exp: schedlock=step: next over function call (GDB internal error) Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * infrun.c (switch_back_to_stepped_thread): Use currently_stepping instead of assuming a thread with a stepping range is always stepping. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR gdb/17408 * gdb.threads/schedlock.c (some_function): New function. (call_function): New global. (MAYBE_CALL_SOME_FUNCTION): New macro. (thread_function): Call it. * gdb.threads/schedlock.exp (get_args): Add description parameter, and use it instead of a global counter. Adjust all callers. (get_current_thread): Use "find current thread" for test message here rather than having all callers pass down the same string. (goto_loop): New procedure, factored out from ... (my_continue): ... this. (step_ten_loops): Change parameter from test message to command to use. Adjust. (list_count): Delete global. (check_result): New procedure, factored out from duplicate top level code. (continue tests): Wrap in with_test_prefix. (test_step): New procedure, factored out from duplicate top level code. (top level): Test "step" in combination with all scheduler-locking modes. Test "next" in combination with all scheduler-locking modes, and in combination with stepping over a function call or not. * gdb.threads/next-bp-other-thread.c: New file. * gdb.threads/next-bp-other-thread.exp: New file.
2014-10-29PR python/17372 - Python hangs when displaying help()Pedro Alves8-11/+204
This is more of a readline/terminal issue than a Python one. PR17372 is a regression in 7.8 caused by the fix for PR17072: commit 0017922d0292d8c374584f6100874580659c9973 Author: Pedro Alves <palves@redhat.com> Date: Mon Jul 14 19:55:32 2014 +0100 Background execution + pagination aborts readline/gdb gdb_readline_wrapper_line removes the handler after a line is processed. Usually, we'll end up re-displaying the prompt, and that reinstalls the handler. But if the output is coming out of handling a stop event, we don't re-display the prompt, and nothing restores the handler. So the next input wakes up the event loop and calls into readline, which aborts. ... gdb/ 2014-07-14 Pedro Alves <palves@redhat.com> PR gdb/17072 * top.c (gdb_readline_wrapper_line): Tweak comment. (gdb_readline_wrapper_cleanup): If readline is enabled, reinstall the input handler callback. The problem is that installing the input handler callback also preps the terminal, putting it in raw mode and with echo disabled, which is bad if we're going to call a command that assumes cooked/canonical mode, and echo enabled, like in the case of the PR, Python's interactive shell. Another example I came up with that doesn't depend on Python is starting a subshell with "(gdb) shell /bin/sh" from a multi-line command. Tests covering both these examples are added. The fix is to revert the original fix for PR gdb/17072, and instead restore the callback handler after processing an asynchronous target event. Furthermore, calling rl_callback_handler_install when we already have some input in readline's line buffer discards that input, which is obviously a bad thing to do while the user is typing. No specific test is added for that, because I first tried calling it even if the callback handler was still installed and that resulted in hundreds of failures in the testsuite. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR python/17372 * event-top.c (change_line_handler): Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. (callback_handler_installed): New global. (gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install) (gdb_rl_callback_handler_reinstall): New functions. (display_gdb_prompt): Call gdb_rl_callback_handler_remove and gdb_rl_callback_handler_install instead of rl_callback_handler_remove and rl_callback_handler_install. (gdb_disable_readline): Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. * event-top.h (gdb_rl_callback_handler_remove) (gdb_rl_callback_handler_install) (gdb_rl_callback_handler_reinstall): New declarations. * infrun.c (reinstall_readline_callback_handler_cleanup): New cleanup function. (fetch_inferior_event): Install it. * top.c (gdb_readline_wrapper_line) Call gdb_rl_callback_handler_remove instead of rl_callback_handler_remove. (gdb_readline_wrapper_cleanup): Don't call rl_callback_handler_install. gdb/testsuite/ 2014-10-29 Pedro Alves <palves@redhat.com> PR python/17372 * gdb.python/python.exp: Test a multi-line command that spawns interactive Python. * gdb.base/multi-line-starts-subshell.exp: New file.
2014-10-29Thix fixes an obvious coding error that led to a GDB crash on AIX or HPUX.Dennis Brueni2-1/+5
* elf.c (elfcore_write_lwpstatus): fix typo in call to memcpy
2014-10-29Updated/new translations provided by the Translations Project.Nick Clifton13-4221/+39562
2014-10-29Fix uninitialized value access when very first GDB command entered is <RET>Pedro Alves2-0/+6
While running GDB under Valgrind, I noticed that if the very first command entered is just <RET>, GDB accesses an uninitialized value: $ valgrind ./gdb -q -nx ==26790== Memcheck, a memory error detector ==26790== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26790== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==26790== Command: ./gdb -q -nx ==26790== (gdb) ==26790== Conditional jump or move depends on uninitialised value(s) ==26790== at 0x619DFC: command_line_handler (event-top.c:588) ==26790== by 0x7813D5: rl_callback_read_char (callback.c:220) ==26790== by 0x6194B4: rl_callback_read_char_wrapper (event-top.c:166) ==26790== by 0x61988A: stdin_event_handler (event-top.c:372) ==26790== by 0x61847D: handle_file_event (event-loop.c:762) ==26790== by 0x617964: process_event (event-loop.c:339) ==26790== by 0x617A2B: gdb_do_one_event (event-loop.c:403) ==26790== by 0x617A7B: start_event_loop (event-loop.c:428) ==26790== by 0x6194E6: cli_command_loop (event-top.c:181) ==26790== by 0x60F86B: current_interp_command_loop (interps.c:317) ==26790== by 0x610A34: captured_command_loop (main.c:321) ==26790== by 0x60C728: catch_errors (exceptions.c:237) ==26790== (gdb) It's this check here: /* If we just got an empty line, and that is supposed to repeat the previous command, return the value in the global buffer. */ if (repeat && p == linebuffer && *p != '\\') { The problem is that linebuffer's contents were never initialized at this point. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> * event-top.c (command_line_handler): Clear the first byte of linebuffer, when it is first allocated.
2014-10-29PR tui/16138 is about failure to initialize curses resulting in GDBPedro Alves1-0/+14
exiting instead of throwing an error. E.g.: $ TERM=foo gdb (gdb) layout asm Error opening terminal: foo. $ The problem is that we're calling initscr to initialize the screen. As mentioned in http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html: If errors occur, initscr() writes an appropriate error message to standard error and exits. ^^^^^ Instead, we should use newterm: "A program that needs an indication of error conditions, so it can continue to run in a line-oriented mode if the terminal cannot support a screen-oriented program, would also use this function." After the patch: $ TERM=foo gdb -q -nx (gdb) layout asm Cannot enable the TUI: error opening terminal [TERM=foo] (gdb) And then PR tui/17519 is about GDB not validating whether the terminal has the necessary capabilities when enabling the TUI. If one tries to enable the TUI with TERM=dumb (and e.g., from a shell within emacs), GDB ends up with a clear screen, the cursor is placed at the bottom/right corner of the screen, there's no prompt, typing shows no echo, and there's no indication of what's going on. c-x,a gets you out of the TUI, but it's completely non-obvious. After the patch, we get: $ TERM=dumb gdb -q -nx (gdb) layout asm Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] (gdb) While at it, I've moved all the tui_allowed_p validation to tui_enable, and expanded the error messages. Previously we'd get: $ gdb -q -nx -i=mi (gdb) layout asm &"layout asm\n" &"TUI mode not allowed\n" ^error,msg="TUI mode not allowed" and: $ gdb -q -nx -ex "layout asm" > foo TUI mode not allowed While now we get: $ gdb -q -nx -i=mi (gdb) layout asm &"layout asm\n" &"Cannot enable the TUI when the interpreter is 'mi'\n" ^error,msg="Cannot enable the TUI when the interpreter is 'mi'" (gdb) and: $ gdb -q -nx -ex "layout asm" > foo Cannot enable the TUI when output is not a terminal Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR tui/16138 PR tui/17519 * tui/tui-interp.c (tui_is_toplevel): Delete global. (tui_allowed_p): Delete function. * tui/tui.c: Include "interps.h". (tui_enable): Don't use tui_allowed_p. Error out here with detailed error messages if the TUI is the top level interpreter, or if output is not a terminal. Use newterm instead of initscr, and error out if initializing the terminal fails. Also error out if the terminal doesn't support cursor addressing. * tui/tui.h (tui_allowed_p): Delete declaration.
2014-10-29TUI: don't let exceptions escape while handling readline key bindingsPedro Alves2-6/+26
I noticed that with: $ TERM=dumb ./gdb -q -nx <c-x,a> Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] (gdb) The next key the user types is silently eaten. The problem is that we're throwing an exception while in a readline callback that isn't prepared for that: (top-gdb) bt #0 tui_enable () at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:388 #1 0x000000000051f47b in tui_rl_switch_mode (notused1=1, notused2=1) at /home/pedro/gdb/mygit/build/../src/gdb/tui/tui.c:101 #2 0x0000000000768d6f in _rl_dispatch_subseq (key=1, map=0xd069c0 <emacs_ctlx_keymap>, got_subseq=0) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:774 #3 0x0000000000768acb in _rl_dispatch_callback (cxt=0x1ce6190) at /home/pedro/gdb/mygit/build/../src/readline/readline.c:686 #4 0x000000000078120b in rl_callback_read_char () at /home/pedro/gdb/mygit/build/../src/readline/callback.c:170 #5 0x0000000000619445 in rl_callback_read_char_wrapper (client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:166 #6 0x000000000061981b in stdin_event_handler (error=0, client_data=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/event-top.c:372 #7 0x000000000061840e in handle_file_event (data=...) at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:762 #8 0x00000000006178f5 in process_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:339 #9 0x00000000006179bc in gdb_do_one_event () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:403 #10 0x0000000000617a0c in start_event_loop () at /home/pedro/gdb/mygit/build/../src/gdb/event-loop.c:428 Here, in _rl_dispatch_subseq: 769 770 rl_executing_keymap = map; 771 772 rl_dispatching = 1; 773 RL_SETSTATE(RL_STATE_DISPATCHING); 774 (*map[key].function)(rl_numeric_arg * rl_arg_sign, key); 775 RL_UNSETSTATE(RL_STATE_DISPATCHING); 776 rl_dispatching = 0; 777 778 /* If we have input pending, then the last command was a prefix 779 command. Don't change the state of rl_last_func. Otherwise, GDB is called from line 774, but longjmp'ing at that point leaves rl_dispatching and RL_STATE_DISPATCHING set. Fix this by wrapping tui_rl_switch_mode in a TRY_CATCH. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> * tui/tui.c (tui_rl_switch_mode): Wrap tui_enable/tui_disable in TRY_CATCH.
2014-10-29PR tui/16138, PR tui/17519, and misc failures to initialize the terminalPedro Alves3-25/+49
PR tui/16138 is about failure to initialize curses resulting in GDB exiting instead of throwing an error. E.g.: $ TERM=foo gdb (gdb) layout asm Error opening terminal: foo. $ The problem is that we're calling initscr to initialize the screen. As mentioned in http://pubs.opengroup.org/onlinepubs/7908799/xcurses/initscr.html: If errors occur, initscr() writes an appropriate error message to standard error and exits. ^^^^^ Instead, we should use newterm: "A program that needs an indication of error conditions, so it can continue to run in a line-oriented mode if the terminal cannot support a screen-oriented program, would also use this function." After the patch: $ TERM=foo gdb -q -nx (gdb) layout asm Cannot enable the TUI: error opening terminal [TERM=foo] (gdb) And then PR tui/17519 is about GDB not validating whether the terminal has the necessary capabilities when enabling the TUI. If one tries to enable the TUI with TERM=dumb (and e.g., from a shell within emacs), GDB ends up with a clear screen, the cursor is placed at the bottom/right corner of the screen, there's no prompt, typing shows no echo, and there's no indication of what's going on. c-x,a gets you out of the TUI, but it's completely non-obvious. After the patch, we get: $ TERM=dumb gdb -q -nx (gdb) layout asm Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb] (gdb) While at it, I've moved all the tui_allowed_p validation to tui_enable, and expanded the error messages. Previously we'd get: $ gdb -q -nx -i=mi (gdb) layout asm &"layout asm\n" &"TUI mode not allowed\n" ^error,msg="TUI mode not allowed" and: $ gdb -q -nx -ex "layout asm" > foo TUI mode not allowed While now we get: $ gdb -q -nx -i=mi (gdb) layout asm &"layout asm\n" &"Cannot enable the TUI when the interpreter is 'mi'\n" ^error,msg="Cannot enable the TUI when the interpreter is 'mi'" (gdb) and: $ gdb -q -nx -ex "layout asm" > foo Cannot enable the TUI when output is not a terminal Tested on x86_64 Fedora 20. gdb/ 2014-10-29 Pedro Alves <palves@redhat.com> PR tui/16138 PR tui/17519 * tui/tui-interp.c (tui_is_toplevel): Delete global. (tui_allowed_p): Delete function. * tui/tui.c: Include "interps.h". (tui_enable): Don't use tui_allowed_p. Error out here with detailed error messages if the TUI is the top level interpreter, or if output is not a terminal. Use newterm instead of initscr, and error out if initializing the terminal fails. Also error out if the terminal doesn't support cursor addressing. * tui/tui.h (tui_allowed_p): Delete declaration.
2014-10-29Prepare directory in case test_system failsYao Qi2-0/+11
In gdb.base/fileio.c, some functions may depend on others. For example, test_rename renames a file to one directory which is created in test_system. That is means, if test_system fails, test_rename fails too, which is not a good practise, IMO. In test_system, system ("mkdir -p XX") is used to create directories needed for test_rename. In this patch, we use dejagnu remote_exec proc to create these directories on host. In my gdb testing, mingw32 host and arm-none-eabi target, system ("mkdir -p XX") doesn't work properly (this issue can be addressed separately), and this patch fixes the following fails. FAIL: gdb.base/fileio.exp: Renaming a directory to a non-empty directory returns ENOTEMPTY or EEXIST FAIL: gdb.base/fileio.exp: Unlink a file FAIL: gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES gdb/testsuite: 2014-10-29 Yao Qi <yao@codesourcery.com> * gdb.base/fileio.exp: Make directories on host.
2014-10-29Close the file in fileio.exp testYao Qi2-0/+5
I see the following fail in fileio.exp on mingw32 host gdb, rename 1: ret = -1, errno = 13^M ^M Breakpoint 2, stop () at fileio.c:76^M 76 static void stop () {}^M (gdb) FAIL: gdb.base/fileio.exp: Rename a file the test fails to rename a file which is not expected. The previous test test_write doesn't close the file, so the rename fails as a result on Windows. This patch fixes it by closing file in test_write, and the fail goes away. rename 1: ret = 0, errno = 0 OK^M ^M Breakpoint 2, stop () at fileio.c:76^M 76 static void stop () {}^M (gdb) PASS: gdb.base/fileio.exp: Rename a file gdb/testsuite: 2014-10-29 Yao Qi <yao@codesourcery.com> * gdb.base/fileio.c (test_write): Close the file.
2014-10-29ARM: stricter __stack_chk_guard check during prologue analysisJoel Brobecker2-5/+10
We are trying to insert a breakpoint on line 4 for the following Ada code. 3 procedure STR is 4 XX : String (1 .. Blocks.Sz) := (others => 'X'); -- STOP 5 K : Integer; 6 begin 7 K := 13; The code generated on ARM (-march=armv7-m) starts like this: (gdb) disass str'address Dump of assembler code for function _ada_str: --# Line str.adb:3 0x08000014 <+0>: push {r4, r7, lr} 0x08000016 <+2>: sub sp, #28 0x08000018 <+4>: add r7, sp, #0 0x0800001a <+6>: mov r3, sp 0x0800001c <+8>: mov r4, r3 --# Line str.adb:4 0x0800001e <+10>: ldr r3, [pc, #84] ; (0x8000074 <_ada_str+96>) 0x08000020 <+12>: ldr r3, [r3, #0] 0x08000022 <+14>: str r3, [r7, #20] 0x08000024 <+16>: ldr r3, [r7, #20] [...] When computing the address related to str.adb:4, GDB correctly resolves it to 0x0800001e first, but then considers the next 3 instructions as being part of the prologue because it thinks they are part of stack-protector code. As a result, instead of inserting the breakpoint at line 4, it skips those instruction and consequently the rest of the instructions until the start of the next line, which his line 7. The stack-protector code is expected to start like this... ldr Rn, .Label .... .Lable: .word __stack_chk_guard ... but the implementation actually accepts a sequence where the ldr location points to an address for which there is no symbol. It only aborts if the address points to a symbol which is not __stack_chk_guard. Since the __stack_chk_guard symbol is always expected to exist when used (it lives in .dynsym), this patch fixes the issue by requiring that the ldr gets the address of the __stack_chk_guard symbol. If the address could not be resolved, then it rejects the sequence as being stack-protector code. gdb/ChangeLog: * arm-tdep.c (arm_skip_stack_protector): Return early if address loaded by first "ldr" instruction does not have a corresponding minimal symbol. Update comment. Tested on arm-eabi using AdaCore's testsuite. Tested on arm-linux-gnueabi by Yao as well.
2014-10-29Fix skipping stack protector on armYao Qi2-3/+13
This patch fixes the bug in my patch skipping stack protector https://www.sourceware.org/ml/gdb-patches/2010-12/msg00110.html In my skipping stack protector patch, I misunderstood the constant vs. immediate on instruction encodings, and treated immediate as constant by mistake. The instruction 'ldr Rd, [PC, #immed]' loads the address of __stack_chk_guard to Rd, and #immed is an offset from PC. We should get the __stack_chk_guard from *(pc + #immed). As a result of this mistake, arm_analyze_load_stack_chk_guard returns the wrong address of __stack_chk_guard, and the symbol __stack_chk_guard can't be found. However, we continue to match the following instructions when symbol isn't found, so the code still works. In other words, the code just matches the instruction pattern without checking __stack_chk_guard symbol correctly. Joel's patch <https://sourceware.org/ml/gdb-patches/2014-10/msg00605.html> makes the heuristics stricter that we stop matching instructions if symbol __stack_chk_guard isn't found. Then the bug is exposed. This patch is to correct the load address computation for ldr instruction, and it fixes some fails in gdb.mi/gdb792.exp on armv4t both arm and thumb mode. Regression tested on arm-linux-gnueabi target with {armv4t, armv7-a} x {marm, mthumb} x {-fstack-protector,-fno-stack-protector} gdb: 2014-10-29 Yao Qi <yao@codesourcery.com> * arm-tdep.c (arm_analyze_load_stack_chk_guard): Compute the loaded address correctly of ldr instruction.
2014-10-29daily updateAlan Modra1-1/+1
2014-10-28PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insnsPedro Alves8-11/+247
TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
generated by cgit v1.1 at 2024-12-22 10:43:05 +0000