aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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.
2014-10-28Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handlerPedro Alves3-13/+97
I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28More fixes for corrupt binaries crashing the binutils.Nick Clifton3-3/+30
PR binutils/17512 * elf.c (bfd_section_from_shdr): Allocate and free the recursion detection table on a per-bfd basis. * peXXigen.c (pe_print_edata): Handle binaries with a truncated export table.
2014-10-28gdb.base/sigstep.exp: cleanup and make it easier to extendPedro Alves2-276/+291
Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28update bug numbers (GNATS -> Bugzilla) in a few signal related testsPedro Alves5-14/+22
This makes it easier to find the bugs in Bugzilla. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigaltstack.exp: Update to use Bugzilla bug numbers instead of GNATS numbers. * gdb.base/sigbpt.exp: Likewise. * gdb.base/siginfo.exp: Likewise. * gdb.base/sigstep.exp: Likewise.
2014-10-28Workaround remote targets that report an empty list to qfThreadInfoPedro Alves2-3/+40
In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra shows a target that was broken by the recent update_thread_list optimization: (gdb) target remote qa8-centos32-cs:10514 ... (gdb) continue Continuing. Cannot execute this command without a live selected thread. (gdb) The error means that the current thread is in "exited" state when the continue command is processed. The root of the problem was found here: > Sending packet: $Hg0#df...Packet received: ... > Sending packet: $?#3f...Packet received: S00 > Sending packet: $qfThreadInfo#bb...Packet received: l > Sending packet: $Hc-1#09...Packet received: > Sending packet: $qC#b4...Packet received: unset This target doesn't really support threads (no thread indication in stop reply packets; no support for qC), but then supports qfThreadInfo, and returns an empty thread list to GDB. See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for why the target does that. As remote_update_thread_list deletes threads from GDB's list that are not found in the thread list that the target reports, the result is that GDB deletes the "fake" main thread that GDB added itself. (As that thread is currently selected, it is marked "exited" instead of being deleted straight away.) This commit avoids deleting the main thread in this scenario. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * remote.c (remote_thread_alive): New, factored out from ... (remote_thread_alive): ... this. (remote_update_thread_list): Bail out before deleting threads if the target returned an empty list, and, the current thread has a magic/fake ptid.
2014-10-28This patch fixes a flaw in the SREC parser which could cause a stack overflowNick Clifton4-4/+11
and potential secuiryt breach. PR binutils/17510 * srec.c (srec_bad_byte): Increase size of buf to allow for negative values. (srec_scan): Use an unsigned char buffer to hold header bytes.
2014-10-28daily updateAlan Modra1-1/+1
2014-10-27stepi/nexti: skip signal handler if "handle nostop" signal arrivesPedro Alves7-19/+141
I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27This fixes more seg-faults in tools like "strings" and "objdump" whenNick Clifton3-67/+150
presented with corrupt binaries. PR binutils/17512 * elf.c (bfd_section_from_shdr): Detect and warn about ELF binaries with a group of sections linked by the string table indicies. * peXXigen.c (pe_print_edata): Detect out of range rvas and entry counts for the Export Address table, Name Pointer table and Ordinal table.
2014-10-27Fix a seg-fault in strings and other binutuils when parsing a corrupt PENick Clifton2-0/+16
executable with an invalid value in the NumberOfRvaAndSizes field of the AOUT header. PR binutils/17512 * peXXigen.c (_bfd_XXi_swap_aouthdr_in): Handle corrupt binaries with an invalid value for NumberOfRvaAndSizes.
2014-10-27This patch closes a potential security hole in applications that useNick Clifton2-4/+36
the bfd library to parse binaries containing maliciously corrupt section group headers. PR binutils/17510 * elf.c (setup_group): Improve handling of corrupt group sections.
2014-10-27Fix trace file fails on powerpc64Yao Qi2-0/+9
I see the following fails on powerpc64-linux, (gdb) target tfile tfile-basic.tf^M warning: Uploaded tracepoint 1 has no source location, using raw address^M Tracepoint 1 at 0x10012358^M Created tracepoint 1 for target's tracepoint 1 at 0x10012358.^M (gdb) PASS: gdb.trace/tfile.exp: target tfile tfile-basic.tf info trace^M Num Type Disp Enb Address What^M 1 tracepoint keep y 0x0000000010012358 <write_basic_trace_file>^M installed on target^M (gdb) FAIL: gdb.trace/tfile.exp: info tracepoints on trace file -target-select tfile tfile-basic.tf^M =thread-group-started,id="i1",pid="1"^M =thread-created,id="1",group-id="i1"^M &"warning: Uploaded tracepoint 1 has no source location, using raw address\n"^M =breakpoint-created,bkpt={number="1",type="tracepoint",disp="keep",enabled="y", addr="0x0000000010012358",at="<write_basic_trace_file>",thread-groups=["i1"], times="0",installed="y",original-location="*0x10012358"}^M ~"Created tracepoint 1 for target's tracepoint 1 at 0x10012358.\n"^M ^connected^M (gdb) ^M FAIL: gdb.trace/mi-traceframe-changed.exp: tfile: select trace file These fails are caused by writing function descriptor address into trace file instead of function address. This patch is to teach tfile.c to write function address on powerpc64 target. With this patch applied, fails in tfile.exp and mi-traceframe-changed.exp are fixed. Is it OK? gdb/testsuite: 2014-10-27 Yao Qi <yao@codesourcery.com> * gdb.trace/tfile.c (adjust_function_address) [__powerpc64__ && _CALL_ELF != 2]: Get function address from function descriptor.
2014-10-27Fix ARM machine state testcase failuresLuis Machado2-188/+143
When running GDB's reverse debugging testsuite against a few ARM multilibs, i noticed failures in the machinestate* testcases. Further investigation showed that push and pop instruction encodings A1 and A2 were not being handled properly, thus we missed saving important contents from registers and memory. When going backwards, such contents were not restored and thus we ended up with a corrupted state that did not correspond to the real values we had at a particular point in time. Attached is a patch that fixes around 36 failures for both gdb.reverse/machinestate.exp and gdb.reverse/machinestate-precsave.exp testcases, making them fully pass. This is for both armv7 and armv4. I still see failures for armv4 thumb though, so it needs a bit more investigation. I see no regressions due to this patch for armv7, armv7 thumb, armv4 and armv4 thumb. gdb/ChangeLog: * arm-tdep.c (INSN_S_L_BIT_NUM): Document. (arm_record_ld_st_imm_offset): Reimplement to cover all load/store cases for ARM opcode 010. (arm_record_ld_st_multiple): Reimplement to cover all load/store cases for ARM opcode 100.
2014-10-26symtab.c (lookup_symbol_aux_local): Fix typo in comment.Doug Evans2-1/+5
gdb/ChangeLog: * symtab.c (lookup_symbol_aux_local): Fix typo in comment.
2014-10-27daily updateAlan Modra1-1/+1
2014-10-26Rename parameter "kind" to "block_index" in quick lookup functions.Doug Evans3-12/+22
gdb/ChangeLog: * symfile.h (struct quick_symbol_functions) <lookup_symbol>: Rename parameter "kind" to "block_index". * symtab.c (error_in_psymtab_expansion): Rename parameter "kind" to "block_index". (lookup_symbol_aux_quick, basic_lookup_transparent_type_quick): Ditto.
2014-10-26* block.h (ALL_BLOCK_SYMBOLS): Fix comment.Doug Evans2-2/+6
gdb/ChangeLog: * block.h (ALL_BLOCK_SYMBOLS): Fix comment.
2014-10-26block.c (allocate_block): Use OBSTACK_ZALLOC instead of obstack_alloc.Doug Evans2-8/+6
gdb/ChangeLog: * block.c (allocate_block): Use OBSTACK_ZALLOC instead of obstack_alloc.
2014-10-26Move block_found decl to symtab.h.Doug Evans3-5/+9
gdb/ChangeLog: * parser-defs.h (block_found): Move decl from here ... * symtab.h (block_found): ... to here.
2014-10-26Clean up some function comments in symtab.[ch].Doug Evans3-57/+90
gdb/ChangeLog: * symtab.h (struct field_of_this_result): Fix typo in comment. (lookup_symbol_in_language): Move function comment here. (lookup_symbol): Improve function comment. (basic_lookup_symbol_nonlocal): Ditto. (lookup_symbol_static, lookup_symbol_global): Ditto. (lookup_symbol_aux_block): Ditto. (lookup_language_this): Add function comment. (lookup_static_symbol_aux): Explicitly mark as extern. Improve function comment. (lookup_block_symbol): Improve function comment. (lookup_struct): Fix capitalization in function comment. (lookup_transparent_type): Add function comment. (lookup_global_symbol_from_objfile): Explicitly mark as extern. Improve function comment. (lookup_objfile_from_block): Add function comment. * symtab.c (lookup_symbol_in_language): Update function comment. (lookup_symbol, lookup_language_this): Ditto. (lookup_static_symbol_aux, lookup_objfile_from_block): Ditto. (lookup_symbol_aux_block, lookup_global_symbol_from_objfile): Ditto. (basic_lookup_symbol_nonlocal): Ditto. (lookup_symbol_static, lookup_symbol_global): Ditto. (lookup_transparent_type, lookup_block_symbol): Ditto.
2014-10-25symtab.c: forward decl cleanupDoug Evans2-12/+9
gdb/ChangeLog: * symtab.c (types_info): Delete forward decl. (functions_info, variables_info, sources_info): Ditto. (_initialize_symtab): Rewrite forward decl to use initialize_file_ftype.
2014-10-25symtab.c (lookup_symbol_aux_quick): Set block_found upon success.Doug Evans2-0/+5
gdb/ChangeLog: * symtab.c (lookup_symbol_aux_quick): Set block_found upon success.
2014-10-25Remove second (nested) copy of local var child_die.Doug Evans2-2/+8
gdb/ChangeLog: * dwarf2read.c (process_structure_scope): Remove second (nested) copy of local var child_die.
2014-10-26daily updateAlan Modra1-1/+1
2014-10-25daily updateAlan Modra1-1/+1
2014-10-24Follow-fork message printing improvementsDon Breazeal5-32/+68
This commit modifies the code that prints attach and detach messages related to following fork and vfork. The changes include using target_terminal_ours_for_output instead of target_terminal_ours, printing "vfork" instead of "fork" for all vfork-related messages, and using _() for the format strings of all of the messages. We also add a "detach" message for when a fork parent is detached. Previously in this case the only message was notification of attaching to the child. We still do not print any messages when following the parent and detaching the child (the default). The rationale for this is that from the user's perspective the new child was never attached. Note that all of these messages are only printed when 'verbose' is set or when debugging is turned on. The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were modified to check for the new message. Tested on x64 Ubuntu Lucid, native only. gdb/ChangeLog: * infrun.c (follow_fork_inferior): Update fork message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, to print "vfork" instead of "fork" for vforks, and to add a detach message. (handle_vfork_child_exec_or_exit): Update message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, and to fix some formatting. gdb/testsuite/ChangeLog: * gdb.base/foll-fork.exp (test_follow_fork, catch_fork_child_follow): Check for updated fork messages emitted from infrun.c. * gdb.base/foll-vfork.exp (vfork_parent_follow_through_step, vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp, vfork_and_exec_child_follow_through_step): Check for updated vfork messages emitted from infrun.c.
2014-10-24Remove Vax Ultrix and VAX BSD supportPedro Alves16-141/+36
Built and tested on x86_64 Fedora 20, with --enable-targets=all. gdb/ 2014-10-24 Pedro Alves <palves@redhat.com> * Makefile.in (ALLDEPFILES): Remove vax-nat.c. * NEWS (Removed targets): Add VAX BSD and VAX Ultrix. * config/vax/vax.mh: Delete. * configure.host: Move vax-*-bsd* and vax-*-ultrix* to the obsolete configurations section. * configure.tgt (vax-*-*): Don't mention 4.2BSD nor Ultrix. * vax-nat.c: Delete file. gdb/testsuite/ 2014-10-24 Pedro Alves <palves@redhat.com> * gdb.base/corefile.exp: Remove references to ultrix. * gdb.base/interrupt.exp: Likewise. * gdb.base/whatis.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.threads/manythreads.exp: Likewise. * gdb.threads/print-threads.exp: Likewise. * gdb.threads/pthreads.exp:: Likewise. * gdb.threads/schedlock.exp: Likewise.
2014-10-24NEWS: Clarify removed targetsPedro Alves2-3/+7
gdb/ 2014-10-24 Pedro Alves <palves@redhat.com> * NEWS (Removed targets): Add OS/arch column.
2014-10-24Guard a call to TYPE_TARGET_TYPE in gnuv3_pass_by_reference.Siva Chandra5-5/+51
gdb/ChangeLog: * gnu-v3-abi.c (gnuv3_pass_by_reference): Call TYPE_TARGET_TYPE on the arg type of a constructor only if it is of reference type. gdb/testsuite/ChangeLog: * gdb.cp/non-trivial-retval.cc: Add a test case. * gdb.cp/non-trivial-retval.exp: Add a test.
2014-10-24[AArch64] Cortex-A53 erratum 835769 linker workaroundJiong Wang11-8/+829
2014-10-22 Tejas Belagod <tejas.belagod@arm.com> bfd/ * bfd-in.h (bfd_elf64_aarch64_set_options): Add a parameter. * bfd-in2.h (bfd_elf64_aarch64_set_options): Likewise. * elfnn-aarch64.c (aarch64_erratum_835769_stub): New. (elf_aarch64_stub_type): Add new type aarch64_stub_erratum_835769_veneer. (elf_aarch64_stub_hash_entry): New fields for erratum 835769. (aarch64_erratum_835769_fix): New data struct to record erratum 835769. (elf_aarch64_link_hash_table: Global flags for 835769. (aarch64_build_one_stub): Add case for 835769. (aarch64_size_one_stub): Likewise. (aarch64_mem_op_p, aarch64_mlxl_p, aarch64_erratum_sequence,erratum_835769_scan): New. Decode and scan functions for erratum 835769. (elf_aarch64_create_or_find_stub_sec): New. (elfNN_aarch64_size_stubs): Look for erratum 835769 and record them. (bfd_elfNN_aarch64_set_options: Set global flag for 835769. (erratum_835769_branch_to_stub_data, make_branch_to_erratum_835769_stub):New. Connect up all the erratum stubs to occurances by branches. (elfNN_aarch64_write_section): New hook. (aarch64_map_one_stub): Output erratum stub symbol. (elfNN_aarch64_size_dynamic_sections): Init mapping symbol information for erratum 835769. (elf_backend_write_section): Define. ld/ * emultempl/aarch64elf.em: Add command-line option for erratum 835769. ld/testsuite/ * ld-aarch64/aarch64-elf.exp (aarch64elftests): Drive erratum 835769 tests. * ld-aarch64/erratum835769.d: New. * ld-aarch64/erratum835769.s: New.
2014-10-24daily updateAlan Modra1-1/+1
2014-10-23Refactoring/cleanup of nios2 opcodes and assembler code.Sandra Loosemore10-1567/+1706
2014-10-23 Sandra Loosemore <sandra@codesourcery.com> include/opcode/ * nios2.h (enum iw_format_type): New. (struct nios2_opcode): Update comments. Add size and format fields. (NIOS2_INSN_OPTARG): New. (REG_NORMAL, REG_CONTROL, REG_COPROCESSOR): New. (struct nios2_reg): Add regtype field. (GET_INSN_FIELD, SET_INSN_FIELD): Delete. (IW_A_LSB, IW_A_MSB, IW_A_SZ, IW_A_MASK): Delete. (IW_B_LSB, IW_B_MSB, IW_B_SZ, IW_B_MASK): Delete. (IW_C_LSB, IW_C_MSB, IW_C_SZ, IW_C_MASK): Delete. (IW_IMM16_LSB, IW_IMM16_MSB, IW_IMM16_SZ, IW_IMM16_MASK): Delete. (IW_IMM26_LSB, IW_IMM26_MSB, IW_IMM26_SZ, IW_IMM26_MASK): Delete. (IW_OP_LSB, IW_OP_MSB, IW_OP_SZ, IW_OP_MASK): Delete. (IW_OPX_LSB, IW_OPX_MSB, IW_OPX_SZ, IW_OPX_MASK): Delete. (IW_SHIFT_IMM5_LSB, IW_SHIFT_IMM5_MSB): Delete. (IW_SHIFT_IMM5_SZ, IW_SHIFT_IMM5_MASK): Delete. (IW_CONTROL_REGNUM_LSB, IW_CONTROL_REGNUM_MSB): Delete. (IW_CONTROL_REGNUM_SZ, IW_CONTROL_REGNUM_MASK): Delete. (OP_MASK_OP, OP_SH_OP): Delete. (OP_MASK_IOP, OP_SH_IOP): Delete. (OP_MASK_IRD, OP_SH_IRD): Delete. (OP_MASK_IRT, OP_SH_IRT): Delete. (OP_MASK_IRS, OP_SH_IRS): Delete. (OP_MASK_ROP, OP_SH_ROP): Delete. (OP_MASK_RRD, OP_SH_RRD): Delete. (OP_MASK_RRT, OP_SH_RRT): Delete. (OP_MASK_RRS, OP_SH_RRS): Delete. (OP_MASK_JOP, OP_SH_JOP): Delete. (OP_MASK_IMM26, OP_SH_IMM26): Delete. (OP_MASK_RCTL, OP_SH_RCTL): Delete. (OP_MASK_IMM5, OP_SH_IMM5): Delete. (OP_MASK_CACHE_OPX, OP_SH_CACHE_OPX): Delete. (OP_MASK_CACHE_RRS, OP_SH_CACHE_RRS): Delete. (OP_MASK_CUSTOM_A, OP_SH_CUSTOM_A): Delete. (OP_MASK_CUSTOM_B, OP_SH_CUSTOM_B): Delete. (OP_MASK_CUSTOM_C, OP_SH_CUSTOM_C): Delete. (OP_MASK_CUSTOM_N, OP_SH_CUSTOM_N): Delete. (OP_<insn>, OPX_<insn>, OP_MATCH_<insn>, OPX_MATCH_<insn>): Delete. (OP_MASK_<insn>, OP_MASK): Delete. (GET_IW_A, GET_IW_B, GET_IW_C, GET_IW_CONTROL_REGNUM): Delete. (GET_IW_IMM16, GET_IW_IMM26, GET_IW_OP, GET_IW_OPX): Delete. Include nios2r1.h to define new instruction opcode constants and accessors. (nios2_builtin_opcodes): Rename to nios2_r1_opcodes. (bfd_nios2_num_builtin_opcodes): Rename to nios2_num_r1_opcodes. (bfd_nios2_num_opcodes): Rename to nios2_num_opcodes. (NUMOPCODES, NUMREGISTERS): Delete. * nios2r1.h: New file. opcodes/ * nios2-opc.c (nios2_builtin_regs): Add regtype field initializers. (nios2_builtin_opcodes): Rename to nios2_r1_opcodes. Use new MATCH_R1_<insn> and MASK_R1_<insn> macros in initializers. Add size and format initializers. Merge 'b' arguments into 'j'. (NIOS2_NUM_OPCODES): Adjust definition. (bfd_nios2_num_builtin_opcodes): Rename to nios2_num_r1_opcodes. (nios2_opcodes): Adjust. (bfd_nios2_num_opcodes): Rename to nios2_num_opcodes. * nios2-dis.c (INSNLEN): Update comment. (nios2_hash_init, nios2_hash): Delete. (OPCODE_HASH_SIZE): New. (nios2_r1_extract_opcode): New. (nios2_disassembler_state): New. (nios2_r1_disassembler_state): New. (nios2_init_opcode_hash): Add state parameter. Adjust to use it. (nios2_find_opcode_hash): Use state object. (bad_opcode): New. (nios2_print_insn_arg): Add op parameter. Use it to access format. Remove 'b' case. (nios2_disassemble): Remove special case for nop. Remove hard-coded instruction size. gas/ * config/tc-nios2.c (nios2_insn_infoS): Add constant_bits field. (nios2_arg_infoS, nios2_arg_hash, nios2_arg_lookup): Delete. (nios2_control_register_arg_p): Delete. (nios2_coproc_reg): Delete. (nios2_relax_frag): Remove hard-coded instruction size. (md_convert_frag): Use new insn accessor macros. (nios2_diagnose_overflow): Remove hard-coded instruction size. (md_apply_fix): Likewise. (bad_opcode): New. (nios2_parse_reg): New. (nios2_assemble_expression): Remove prev_reloc parameter. Adjust uses and callers. (nios2_assemble_arg_c): New. (nios2_assemble_arg_d): New. (nios2_assemble_arg_s): New. (nios2_assemble_arg_t): New. (nios2_assemble_arg_i): New. (nios2_assemble_arg_u): New. (nios2_assemble_arg_o): New. (nios2_assemble_arg_j): New. (nios2_assemble_arg_l): New. (nios2_assemble_arg_m): New. (nios2_assemble_args): New. (nios2_assemble_args_dst): Delete. (nios2_assemble_args_tsi): Delete. (nios2_assemble_args_tsu): Delete. (nios2_assemble_args_sto): Delete. (nios2_assemble_args_o): Delete. (nios2_assemble_args_is): Delete. (nios2_assemble_args_m): Delete. (nios2_assemble_args_s): Delete. (nios2_assemble_args_tis): Delete. (nios2_assemble_args_dc): Delete. (nios2_assemble_args_cs): Delete. (nios2_assemble_args_ds): Delete. (nios2_assemble_args_ldst): Delete. (nios2_assemble_args_none): Delete. (nios2_assemble_args_dsj): Delete. (nios2_assemble_args_d): Delete. (nios2_assemble_args_b): Delete. (nios2_arg_info_structs): Delete. (NIOS2_NUM_ARGS): Delete. (nios2_consume_arg): Remove insn parameter. Use new macros. Don't check register arguments here. Remove 'b' case. (nios2_consume_separator): Move check for missing separators to... (nios2_parse_args): ...here. Remove special case for optional arguments. (output_insn): Avoid using hard-coded insn size. (output_ubranch): Likewise. (output_cbranch): Likewise. (output_call): Use new macros. (output_addi): Likewise. (output_ori): Likewise. (output_xori): Likewise. (output_movia): Likewise. (md_begin): Remove nios2_arg_info_structs initialization. (md_assemble): Initialize constant_bits field. Use nios2_parse_args instead of looking up parse function in hash table. gdb/ * nios2-tdep.c (nios2_analyze_prologue): Use new instruction field accessors and constants from nios2 opcodes update. (nios2_get_next_pc): Likewise.
2014-10-23ARM: plt_size functions need to read instructions in right byte orderVictor Kamensky2-4/+32
elf32_arm_plt0_size and elf32_arm_plt_size read instructions to determine what is size of PLT entry. However it does not read instruction correctly in case of ARM big endian V7 case. In this case instructions are still kept in little endian order (BE8). * elf32-arm.c (read_code32): New function to read 32 bit arm instruction. (read_code16): New function to read 16 bit thumb instrution. (elf32_arm_plt0_size, elf32_arm_plt_size): Use read_code32 and read_code16 to read instructions.
2014-10-23daily updateAlan Modra1-1/+1
generated by cgit v1.1 at 2025-01-09 03:06:54 +0000