aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2013-11-222013-11-22 Sterling Augustine <saugustine@google.com>Sterling Augustine1-1/+1
PR gdb/16196: * valprint.c (read_string): Set new variable fetchlen based on fetchlimit and size. Use it in call to partial_memory_read. Update comment.
2013-11-222013-11-22 Sterling Augustine <saugustine@google.com>Sterling Augustine2-7/+18
PR gdb/16196: * valprint.c (read_string): Set new variable fetchlen based on fetchlimit and size. Use it in call to partial_memory_read. Update comment.
2013-11-22Rename gdb.dwarf2/dw2-bad-cfi.* to gdb.dwarf2/dw2-unspecified-ret-addr.*.Pedro Alves4-13/+22
gdb/testsuite/ 2013-11-22 Pedro Alves <palves@redhat.com> * gdb.dwarf2/dw2-bad-cfi.S: Rename to ... * gdb.dwarf2/dw2-unspecified-ret-addr.S: ... this. Adjust. * gdb.dwarf2/dw2-bad-cfi.c: Rename to ... * gdb.dwarf2/dw2-unspecified-ret-addr.c: ... this. * gdb.dwarf2/dw2-bad-cfi.exp: Rename to ... * gdb.dwarf2/dw2-unspecified-ret-addr.exp: ... this.
2013-11-22update comment in dw2-bad-cfi.S.Tom Tromey2-1/+6
Pedro asked me to add a comment to dw2-bad-cfi.S explaining the nature of the badness. I'm checking this in. 2013-11-22 Tom Tromey <tromey@redhat.com> * gdb.dwarf2/dw2-bad-cfi.S: Update comment.
2013-11-22handle an unspecified return address columnTom Tromey6-0/+302
Debugging PR 16155 further, I found that the DWARF unwinder found the function in question, but thought it had no registers saved (fs->regs.num_regs == 0). It seems to me that if a frame does not specify the return address column, or if the return address column is explicitly marked as DWARF2_FRAME_REG_UNSPECIFIED, then we should set the "undefined_retaddr" flag and let the DWARF unwinder gracefully stop. This patch implements that idea. With this patch the backtrace works properly: (gdb) bt #0 0x0000007fb7ed485c in nanosleep () from /lib64/libc.so.6 #1 0x0000007fb7ed4508 in sleep () from /lib64/libc.so.6 #2 0x00000000004008bc in thread_function (arg=0x4) at threadapply.c:73 #3 0x0000007fb7fad950 in start_thread () from /lib64/libpthread.so.0 #4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6 2013-11-22 Tom Tromey <tromey@redhat.com> PR backtrace/16155: * dwarf2-frame.c (dwarf2_frame_cache): Set undefined_retaddr if the return address column is unspecified. 2013-11-22 Tom Tromey <tromey@redhat.com> * gdb.dwarf2/dw2-bad-cfi.c: New file. * gdb.dwarf2/dw2-bad-cfi.exp: New file. * gdb.dwarf2/dw2-bad-cfi.S: New file.
2013-11-22Detect infinite loop in value_fetch_lazy's lval_register handling.Tom Tromey2-1/+26
If value_fetch_lazy loops infinitely while unwrapping lval_register values, it means we either somehow ended up with two frames with the same ID in the frame chain, or some code is trying to unwind behind get_prev_frame's back (e.g., a frame unwind sniffer trying to unwind). In any case, it should always be an internal error to end up in this situation. This patch adds a check and throws an internal error if the same frame is returned. 2013-11-22 Tom Tromey <tromey@redhat.com> Pedro Alves <palves@redhat.com> PR backtrace/16155 * value.c (value_fetch_lazy): Internal error if get_frame_register_value returns the same register.
2013-11-22Make use of the frame stash to detect wider stack cycles.Pedro Alves2-63/+100
Given we already have the frame id stash, which holds the ids of all frames in the chain, detecting corrupted stacks with wide stack cycles with non-consecutive dup frame ids is just as cheap as just detecting cycles in consecutive frames: #0 frame_id1 #1 frame_id2 #2 frame_id3 #3 frame_id1 #4 frame_id2 #5 frame_id3 #6 frame_id1 ... forever ... We just need to check whether the stash already knows about a given frame id instead of comparing the ids of the previous/this frames. Tested on x86_64 Fedora 17. gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> * frame.c (frame_stash_add): Now returns whether a frame with the same ID was already known. (compute_frame_id): New function, factored out from get_frame_id. (get_frame_id): No longer lazilly compute the frame id here. (get_prev_frame_if_no_cycle): New function. Detects wider stack cycles. (get_prev_frame_1): Use it instead of get_prev_frame_raw directly, and checking for stack cycles here.
2013-11-22Don't let two frames with the same id end up in the frame chain.Pedro Alves6-17/+660
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame when we go try to unwind the previous frame. But at this point, it's already too late -- we ended up with two frames with the same ID in the frame chain. Each frame having its own ID is an invariant assumed throughout GDB. This patch applies the UNWIND_SAME_ID detection earlier, right after the previous frame is unwound, discarding the dup frame if a cycle is detected. The patch includes a new test that fails before the change. Before the patch, the test causes an infinite loop in GDB, after the patch, the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with: Backtrace stopped: previous frame identical to this frame (corrupt stack?) The test uses dwarf CFI to emulate a corrupted stack with a cycle. It has a function with registers marked DW_CFA_same_value (most importantly RSP/RIP), so that GDB computes the same ID for that frame and its caller. IOW, something like this: #0 - frame_id_1 #1 - frame_id_2 #2 - frame_id_3 #3 - frame_id_4 #4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID). (The test's code is just a copy of dw2-reg-undefined.S / dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of DW_CFA_undefined, and to mark a different set of registers.) The infinite loop is here, in value_fetch_lazy: while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val)) { frame = frame_find_by_id (VALUE_FRAME_ID (new_val)); ... new_val = get_frame_register_value (frame, regnum); } get_frame_register_value can return a lazy register value pointing to the next frame. This means that the register wasn't clobbered by FRAME; the debugger should therefore retrieve its value from the next frame. To be clear, get_frame_register_value unwinds the value in question from the next frame: struct value * get_frame_register_value (struct frame_info *frame, int regnum) { return frame_unwind_register_value (frame->next, regnum); ^^^^^^^^^^^ } In other words, if we get a lazy lval_register, it should have the frame ID of the _next_ frame, never of FRAME. At this point in value_fetch_lazy, the whole relevant chunk of the stack up to frame #4 has already been unwound. The loop always "unlazies" lval_registers in the "next/innermost" direction, not in the "prev/unwind further/outermost" direction. So say we're looking at frame #4. get_frame_register_value in frame #4 can return a lazy register value of frame #3. So the next iteration, frame_find_by_id tries to read the register from frame #3. But, since frame #4 happens to have same id as frame #3, frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have an infinite loop. This is an old latent problem, exposed by the recent addition of the frame stash. Before we had a stash, frame_find_by_id(frame_id_4) would walk over all frames starting at the current frame, and would always find #3 first. The stash happens to return #4 instead: struct frame_info * frame_find_by_id (struct frame_id id) { struct frame_info *frame, *prev_frame; ... /* Try using the frame stash first. Finding it there removes the need to perform the search by looping over all frames, which can be very CPU-intensive if the number of frames is very high (the loop is O(n) and get_prev_frame performs a series of checks that are relatively expensive). This optimization is particularly useful when this function is called from another function (such as value_fetch_lazy, case VALUE_LVAL (val) == lval_register) which already loops over all frames, making the overall behavior O(n^2). */ frame = frame_stash_find (id); if (frame) return frame; for (frame = get_current_frame (); ; frame = prev_frame) { gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between this frame and the new previous frame, not between this frame and the next frame. gdb/testsuite/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * gdb.dwarf2/dw2-dup-frame.S: New file. * gdb.dwarf2/dw2-dup-frame.c: New file. * gdb.dwarf2/dw2-dup-frame.exp: New file.
2013-11-22Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer ↵Pedro Alves2-15/+32
(move dwarf2_tailcall_sniffer_first elsewhere). Two rationales, same patch. TL;DR 1: dwarf2_frame_cache recursion is evil. dwarf2_frame_cache calls dwarf2_tailcall_sniffer_first which then recurses into dwarf2_frame_cache. TL;DR 2: An unwinder trying to unwind is evil. dwarf2_frame_sniffer calls dwarf2_frame_cache which calls dwarf2_tailcall_sniffer_first which then tries to unwind the PC of the previous frame. Avoid all that by deferring dwarf2_tailcall_sniffer_first until it's really necessary. Rationale 1 =========== A frame sniffer should not try to unwind, because that bypasses all the validation checks done by get_prev_frame. The UNWIND_SAME_ID scenario is one such case where GDB is currently broken because (in part) of this (the next patch adds a test that would fail without this). GDB goes into an infinite loop in value_fetch_lazy, here: while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val)) { frame = frame_find_by_id (VALUE_FRAME_ID (new_val)); ... new_val = get_frame_register_value (frame, regnum); } (top-gdb) bt #0 value_fetch_lazy (val=0x11516d0) at ../../src/gdb/value.c:3510 #1 0x0000000000584bd8 in value_optimized_out (value=0x11516d0) at ../../src/gdb/value.c:1096 #2 0x00000000006fe7a1 in frame_register_unwind (frame=0x1492600, regnum=16, optimizedp=0x7fffffffcdec, unavailablep=0x7fffffffcde8, lvalp=0x7fffffffcdd8, addrp= 0x7fffffffcde0, realnump=0x7fffffffcddc, bufferp=0x7fffffffce10 "@\316\377\377\377\177") at ../../src/gdb/frame.c:940 #3 0x00000000006fea3a in frame_unwind_register (frame=0x1492600, regnum=16, buf=0x7fffffffce10 "@\316\377\377\377\177") at ../../src/gdb/frame.c:990 #4 0x0000000000473b9b in i386_unwind_pc (gdbarch=0xf54660, next_frame=0x1492600) at ../../src/gdb/i386-tdep.c:1771 #5 0x0000000000601dfa in gdbarch_unwind_pc (gdbarch=0xf54660, next_frame=0x1492600) at ../../src/gdb/gdbarch.c:2870 #6 0x0000000000693db5 in dwarf2_tailcall_sniffer_first (this_frame=0x1492600, tailcall_cachep=0x14926f0, entry_cfa_sp_offsetp=0x7fffffffcf00) at ../../src/gdb/dwarf2-frame-tailcall.c:389 #7 0x0000000000690928 in dwarf2_frame_cache (this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/dwarf2-frame.c:1245 #8 0x0000000000690f46 in dwarf2_frame_sniffer (self=0x8e4980, this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/dwarf2-frame.c:1423 #9 0x000000000070203b in frame_unwind_find_by_frame (this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/frame-unwind.c:112 #10 0x00000000006fd681 in get_frame_id (fi=0x1492600) at ../../src/gdb/frame.c:408 #11 0x00000000007006c2 in get_prev_frame_1 (this_frame=0xdc1860) at ../../src/gdb/frame.c:1826 #12 0x0000000000700b7a in get_prev_frame (this_frame=0xdc1860) at ../../src/gdb/frame.c:2056 #13 0x0000000000514588 in frame_info_to_frame_object (frame=0xdc1860) at ../../src/gdb/python/py-frame.c:322 #14 0x000000000051784c in bootstrap_python_frame_filters (frame=0xdc1860, frame_low=0, frame_high=-1) at ../../src/gdb/python/py-framefilter.c:1396 #15 0x0000000000517a6f in apply_frame_filter (frame=0xdc1860, flags=7, args_type=CLI_SCALAR_VALUES, out=0xed7a90, frame_low=0, frame_high=-1) at ../../src/gdb/python/py-framefilter.c:1492 #16 0x00000000005e77b0 in backtrace_command_1 (count_exp=0x0, show_locals=0, no_filters=0, from_tty=1) at ../../src/gdb/stack.c:1777 #17 0x00000000005e7c0f in backtrace_command (arg=0x0, from_tty=1) at ../../src/gdb/stack.c:1891 #18 0x00000000004e37a7 in do_cfunc (c=0xda4fa0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:107 #19 0x00000000004e683c in cmd_func (cmd=0xda4fa0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:1882 #20 0x00000000006f35ed in execute_command (p=0xcc66c2 "", from_tty=1) at ../../src/gdb/top.c:468 #21 0x00000000005f8853 in command_handler (command=0xcc66c0 "bt") at ../../src/gdb/event-top.c:435 #22 0x00000000005f8e12 in command_line_handler (rl=0xfe05f0 "@") at ../../src/gdb/event-top.c:632 #23 0x000000000074d2c6 in rl_callback_read_char () at ../../src/readline/callback.c:220 #24 0x00000000005f8375 in rl_callback_read_char_wrapper (client_data=0x0) at ../../src/gdb/event-top.c:164 #25 0x00000000005f876a in stdin_event_handler (error=0, client_data=0x0) at ../../src/gdb/event-top.c:375 #26 0x00000000005f72fa in handle_file_event (data=...) at ../../src/gdb/event-loop.c:768 #27 0x00000000005f67a3 in process_event () at ../../src/gdb/event-loop.c:342 #28 0x00000000005f686a in gdb_do_one_event () at ../../src/gdb/event-loop.c:406 #29 0x00000000005f68bb in start_event_loop () at ../../src/gdb/event-loop.c:431 #30 0x00000000005f83a7 in cli_command_loop (data=0x0) at ../../src/gdb/event-top.c:179 #31 0x00000000005eeed3 in current_interp_command_loop () at ../../src/gdb/interps.c:327 #32 0x00000000005ef8ff in captured_command_loop (data=0x0) at ../../src/gdb/main.c:267 #33 0x00000000005ed2f6 in catch_errors (func=0x5ef8e4 <captured_command_loop>, func_args=0x0, errstring=0x8b6554 "", mask=RETURN_MASK_ALL) at ../../src/gdb/exceptions.c:524 #34 0x00000000005f0d21 in captured_main (data=0x7fffffffd9e0) at ../../src/gdb/main.c:1067 #35 0x00000000005ed2f6 in catch_errors (func=0x5efb9b <captured_main>, func_args=0x7fffffffd9e0, errstring=0x8b6554 "", mask=RETURN_MASK_ALL) at ../../src/gdb/exceptions.c:524 #36 0x00000000005f0d57 in gdb_main (args=0x7fffffffd9e0) at ../../src/gdb/main.c:1076 #37 0x000000000045bb6a in main (argc=4, argv=0x7fffffffdae8) at ../../src/gdb/gdb.c:34 (top-gdb) GDB is trying to unwind the PC register of the previous frame (frame #5 above), starting from the frame being sniffed (the THIS frame). But the THIS frame's unwinder says the PC of the previous frame is actually the same as the previous's frame's next frame (which is the same frame we started with, the THIS frame), therefore it returns an lval_register lazy value with frame set to THIS frame. And so the value_fetch_lazy loop never ends. Rationale 2 =========== As an experiment, I tried making dwarf2-frame.c:read_addr_from_reg use address_from_register. That caused a bunch of regressions, but it actually took me a long while to figure out what was going on. Turns out dwarf2-frame.c:read_addr_from_reg is called while computing the frame's CFA, from within dwarf2_frame_cache. address_from_register wants to create a register with frame_id set to the frame being constructed. To create the frame id, we again call dwarf2_frame_cache, which given: static struct dwarf2_frame_cache * dwarf2_frame_cache (struct frame_info *this_frame, void **this_cache) { ... if (*this_cache) return *this_cache; returns an incomplete object to the caller: static void dwarf2_frame_this_id (struct frame_info *this_frame, void **this_cache, struct frame_id *this_id) { struct dwarf2_frame_cache *cache = dwarf2_frame_cache (this_frame, this_cache); ... (*this_id) = frame_id_build (cache->cfa, get_frame_func (this_frame)); } As cache->cfa is still 0 (we were trying to compute it!), and get_frame_id recalls this id from here on, we end up with a broken frame id in recorded for this frame. Later, when inspecting locals, the dwarf machinery needs to know the selected frame's base, which calls get_frame_base: CORE_ADDR get_frame_base (struct frame_info *fi) { return get_frame_id (fi).stack_addr; } which as seen above then returns 0 ... So I gave up using address_from_register. But, the pain of investigating this made me want to have GDB itself assert that recursion never happens here. So I wrote a patch to do that. But, it triggers on current mainline, because dwarf2_tailcall_sniffer_first, called from dwarf2_frame_cache, unwinds the this_frame. A sniffer shouldn't be trying to unwind, exactly because of this sort of tricky issue. The patch defers calling dwarf2_tailcall_sniffer_first until it's really necessary, in dwarf2_frame_prev_register (thus actually outside the sniffer path). As this makes the call to dwarf2_frame_sniffer in dwarf2_frame_cache unnecessary again, the patch removes that too. Tested on x86_64 Fedora 17. gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * dwarf2-frame.c (struct dwarf2_frame_cache) <checked_tailcall_bottom, entry_cfa_sp_offset, entry_cfa_sp_offset_p>: New fields. (dwarf2_frame_cache): Adjust to use the new cache fields instead of locals. Don't call dwarf2_tailcall_sniffer_first here. (dwarf2_frame_prev_register): Call it here, but only once.
2013-11-22Revert "Don't let two frames with the same id end up in the frame chain."Pedro Alves4-646/+17
This reverts commit be2c48b4d50b992ba83bc51f086e316621a03a14.
2013-11-22Revert "Make use of the frame stash to detect wider stack cycles."Pedro Alves1-88/+63
This reverts commit f5b0ed3c8ce42b0dd6b6caa0b3d7b7e734311afe.
2013-11-22Revert "Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 ↵Pedro Alves2-32/+15
sniffer (move dwarf2_tailcall_sniffer_first elsewhere)." This reverts commit 1dc8686c48e72fc02723d44ee0fecde0d233c74e.
2013-11-22Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer ↵Pedro Alves2-15/+32
(move dwarf2_tailcall_sniffer_first elsewhere). Two rationales, same patch. TL;DR 1: dwarf2_frame_cache recursion is evil. dwarf2_frame_cache calls dwarf2_tailcall_sniffer_first which then recurses into dwarf2_frame_cache. TL;DR 2: An unwinder trying to unwind is evil. dwarf2_frame_sniffer calls dwarf2_frame_cache which calls dwarf2_tailcall_sniffer_first which then tries to unwind the PC of the previous frame. Avoid all that by deferring dwarf2_tailcall_sniffer_first until it's really necessary. Rationale 1 =========== A frame sniffer should not try to unwind, because that bypasses all the validation checks done by get_prev_frame. The UNWIND_SAME_ID scenario is one such case where GDB is currently broken because (in part) of this (the next patch adds a test that would fail without this). GDB goes into an infinite loop in value_fetch_lazy, here: while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val)) { frame = frame_find_by_id (VALUE_FRAME_ID (new_val)); ... new_val = get_frame_register_value (frame, regnum); } (top-gdb) bt #0 value_fetch_lazy (val=0x11516d0) at ../../src/gdb/value.c:3510 #1 0x0000000000584bd8 in value_optimized_out (value=0x11516d0) at ../../src/gdb/value.c:1096 #2 0x00000000006fe7a1 in frame_register_unwind (frame=0x1492600, regnum=16, optimizedp=0x7fffffffcdec, unavailablep=0x7fffffffcde8, lvalp=0x7fffffffcdd8, addrp= 0x7fffffffcde0, realnump=0x7fffffffcddc, bufferp=0x7fffffffce10 "@\316\377\377\377\177") at ../../src/gdb/frame.c:940 #3 0x00000000006fea3a in frame_unwind_register (frame=0x1492600, regnum=16, buf=0x7fffffffce10 "@\316\377\377\377\177") at ../../src/gdb/frame.c:990 #4 0x0000000000473b9b in i386_unwind_pc (gdbarch=0xf54660, next_frame=0x1492600) at ../../src/gdb/i386-tdep.c:1771 #5 0x0000000000601dfa in gdbarch_unwind_pc (gdbarch=0xf54660, next_frame=0x1492600) at ../../src/gdb/gdbarch.c:2870 #6 0x0000000000693db5 in dwarf2_tailcall_sniffer_first (this_frame=0x1492600, tailcall_cachep=0x14926f0, entry_cfa_sp_offsetp=0x7fffffffcf00) at ../../src/gdb/dwarf2-frame-tailcall.c:389 #7 0x0000000000690928 in dwarf2_frame_cache (this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/dwarf2-frame.c:1245 #8 0x0000000000690f46 in dwarf2_frame_sniffer (self=0x8e4980, this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/dwarf2-frame.c:1423 #9 0x000000000070203b in frame_unwind_find_by_frame (this_frame=0x1492600, this_cache=0x1492618) at ../../src/gdb/frame-unwind.c:112 #10 0x00000000006fd681 in get_frame_id (fi=0x1492600) at ../../src/gdb/frame.c:408 #11 0x00000000007006c2 in get_prev_frame_1 (this_frame=0xdc1860) at ../../src/gdb/frame.c:1826 #12 0x0000000000700b7a in get_prev_frame (this_frame=0xdc1860) at ../../src/gdb/frame.c:2056 #13 0x0000000000514588 in frame_info_to_frame_object (frame=0xdc1860) at ../../src/gdb/python/py-frame.c:322 #14 0x000000000051784c in bootstrap_python_frame_filters (frame=0xdc1860, frame_low=0, frame_high=-1) at ../../src/gdb/python/py-framefilter.c:1396 #15 0x0000000000517a6f in apply_frame_filter (frame=0xdc1860, flags=7, args_type=CLI_SCALAR_VALUES, out=0xed7a90, frame_low=0, frame_high=-1) at ../../src/gdb/python/py-framefilter.c:1492 #16 0x00000000005e77b0 in backtrace_command_1 (count_exp=0x0, show_locals=0, no_filters=0, from_tty=1) at ../../src/gdb/stack.c:1777 #17 0x00000000005e7c0f in backtrace_command (arg=0x0, from_tty=1) at ../../src/gdb/stack.c:1891 #18 0x00000000004e37a7 in do_cfunc (c=0xda4fa0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:107 #19 0x00000000004e683c in cmd_func (cmd=0xda4fa0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:1882 #20 0x00000000006f35ed in execute_command (p=0xcc66c2 "", from_tty=1) at ../../src/gdb/top.c:468 #21 0x00000000005f8853 in command_handler (command=0xcc66c0 "bt") at ../../src/gdb/event-top.c:435 #22 0x00000000005f8e12 in command_line_handler (rl=0xfe05f0 "@") at ../../src/gdb/event-top.c:632 #23 0x000000000074d2c6 in rl_callback_read_char () at ../../src/readline/callback.c:220 #24 0x00000000005f8375 in rl_callback_read_char_wrapper (client_data=0x0) at ../../src/gdb/event-top.c:164 #25 0x00000000005f876a in stdin_event_handler (error=0, client_data=0x0) at ../../src/gdb/event-top.c:375 #26 0x00000000005f72fa in handle_file_event (data=...) at ../../src/gdb/event-loop.c:768 #27 0x00000000005f67a3 in process_event () at ../../src/gdb/event-loop.c:342 #28 0x00000000005f686a in gdb_do_one_event () at ../../src/gdb/event-loop.c:406 #29 0x00000000005f68bb in start_event_loop () at ../../src/gdb/event-loop.c:431 #30 0x00000000005f83a7 in cli_command_loop (data=0x0) at ../../src/gdb/event-top.c:179 #31 0x00000000005eeed3 in current_interp_command_loop () at ../../src/gdb/interps.c:327 #32 0x00000000005ef8ff in captured_command_loop (data=0x0) at ../../src/gdb/main.c:267 #33 0x00000000005ed2f6 in catch_errors (func=0x5ef8e4 <captured_command_loop>, func_args=0x0, errstring=0x8b6554 "", mask=RETURN_MASK_ALL) at ../../src/gdb/exceptions.c:524 #34 0x00000000005f0d21 in captured_main (data=0x7fffffffd9e0) at ../../src/gdb/main.c:1067 #35 0x00000000005ed2f6 in catch_errors (func=0x5efb9b <captured_main>, func_args=0x7fffffffd9e0, errstring=0x8b6554 "", mask=RETURN_MASK_ALL) at ../../src/gdb/exceptions.c:524 #36 0x00000000005f0d57 in gdb_main (args=0x7fffffffd9e0) at ../../src/gdb/main.c:1076 #37 0x000000000045bb6a in main (argc=4, argv=0x7fffffffdae8) at ../../src/gdb/gdb.c:34 (top-gdb) GDB is trying to unwind the PC register of the previous frame (frame #5 above), starting from the frame being sniffed (the THIS frame). But the THIS frame's unwinder says the PC of the previous frame is actually the same as the previous's frame's next frame (which is the same frame we started with, the THIS frame), therefore it returns an lval_register lazy value with frame set to THIS frame. And so the value_fetch_lazy loop never ends. Rationale 2 =========== As an experiment, I tried making dwarf2-frame.c:read_addr_from_reg use address_from_register. That caused a bunch of regressions, but it actually took me a long while to figure out what was going on. Turns out dwarf2-frame.c:read_addr_from_reg is called while computing the frame's CFA, from within dwarf2_frame_cache. address_from_register wants to create a register with frame_id set to the frame being constructed. To create the frame id, we again call dwarf2_frame_cache, which given: static struct dwarf2_frame_cache * dwarf2_frame_cache (struct frame_info *this_frame, void **this_cache) { ... if (*this_cache) return *this_cache; returns an incomplete object to the caller: static void dwarf2_frame_this_id (struct frame_info *this_frame, void **this_cache, struct frame_id *this_id) { struct dwarf2_frame_cache *cache = dwarf2_frame_cache (this_frame, this_cache); ... (*this_id) = frame_id_build (cache->cfa, get_frame_func (this_frame)); } As cache->cfa is still 0 (we were trying to compute it!), and get_frame_id recalls this id from here on, we end up with a broken frame id in recorded for this frame. Later, when inspecting locals, the dwarf machinery needs to know the selected frame's base, which calls get_frame_base: CORE_ADDR get_frame_base (struct frame_info *fi) { return get_frame_id (fi).stack_addr; } which as seen above then returns 0 ... So I gave up using address_from_register. But, the pain of investigating this made me want to have GDB itself assert that recursion never happens here. So I wrote a patch to do that. But, it triggers on current mainline, because dwarf2_tailcall_sniffer_first, called from dwarf2_frame_cache, unwinds the this_frame. A sniffer shouldn't be trying to unwind, exactly because of this sort of tricky issue. The patch defers calling dwarf2_tailcall_sniffer_first until it's really necessary, in dwarf2_frame_prev_register (thus actually outside the sniffer path). As this makes the call to dwarf2_frame_sniffer in dwarf2_frame_cache unnecessary again, the patch removes that too. Tested on x86_64 Fedora 17. gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * dwarf2-frame.c (struct dwarf2_frame_cache) <checked_tailcall_bottom, entry_cfa_sp_offset, entry_cfa_sp_offset_p>: New fields. (dwarf2_frame_cache): Adjust to use the new cache fields instead of locals. Don't call dwarf2_tailcall_sniffer_first here. (dwarf2_frame_prev_register): Call it here, but only once.
2013-11-22Make use of the frame stash to detect wider stack cycles.Pedro Alves1-63/+88
Tested on x86_64 Fedora 17. gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@redhat.com> * frame.c (frame_stash_add): Now returns whether a frame with the same ID was already known. (compute_frame_id): New function, factored out from get_frame_id. (get_frame_id): No longer lazilly compute the frame id here. (get_prev_frame_if_no_cycle): New function. Detects wider stack cycles. (get_prev_frame_1): Use it instead of get_prev_frame_raw directly, and checking for stack cycles here.
2013-11-22Don't let two frames with the same id end up in the frame chain.Pedro Alves4-17/+646
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame when we go try to unwind the previous frame. But at this point, it's already too late -- we ended up with two frames with the same ID in the frame chain. Each frame having its own ID is an invariant assumed throughout GDB. This patch applies the UNWIND_SAME_ID detection earlier, right after the previous frame is unwound, discarding the dup frame if a cycle is detected. The patch includes a new test that fails before the change. Before the patch, the test causes an infinite loop in GDB, after the patch, the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with: Backtrace stopped: previous frame identical to this frame (corrupt stack?) The test uses dwarf CFI to emulate a corrupted stack with a cycle. It has a function with registers marked DW_CFA_same_value (most importantly RSP/RIP), so that GDB computes the same ID for that frame and its caller. IOW, something like this: #0 - frame_id_1 #1 - frame_id_2 #2 - frame_id_3 #3 - frame_id_4 #4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID). (The test's code is just a copy of dw2-reg-undefined.S / dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of DW_CFA_undefined, and to mark a different set of registers.) The infinite loop is here, in value_fetch_lazy: while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val)) { frame = frame_find_by_id (VALUE_FRAME_ID (new_val)); ... new_val = get_frame_register_value (frame, regnum); } get_frame_register_value can return a lazy register value pointing to the next frame. This means that the register wasn't clobbered by FRAME; the debugger should therefore retrieve its value from the next frame. To be clear, get_frame_register_value unwinds the value in question from the next frame: struct value * get_frame_register_value (struct frame_info *frame, int regnum) { return frame_unwind_register_value (frame->next, regnum); ^^^^^^^^^^^ } In other words, if we get a lazy lval_register, it should have the frame ID of the _next_ frame, never of FRAME. At this point in value_fetch_lazy, the whole relevant chunk of the stack up to frame #4 has already been unwound. The loop always "unlazies" lval_registers in the "next/innermost" direction, not in the "prev/unwind further/outermost" direction. So say we're looking at frame #4. get_frame_register_value in frame #4 can return a lazy register value of frame #3. So the next iteration, frame_find_by_id tries to read the register from frame #3. But, since frame #4 happens to have same id as frame #3, frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have an infinite loop. This is an old latent problem, exposed by the recent addition of the frame stash. Before we had a stash, frame_find_by_id(frame_id_4) would walk over all frames starting at the current frame, and would always find #3 first. The stash happens to return #4 instead: struct frame_info * frame_find_by_id (struct frame_id id) { struct frame_info *frame, *prev_frame; ... /* Try using the frame stash first. Finding it there removes the need to perform the search by looping over all frames, which can be very CPU-intensive if the number of frames is very high (the loop is O(n) and get_prev_frame performs a series of checks that are relatively expensive). This optimization is particularly useful when this function is called from another function (such as value_fetch_lazy, case VALUE_LVAL (val) == lval_register) which already loops over all frames, making the overall behavior O(n^2). */ frame = frame_stash_find (id); if (frame) return frame; for (frame = get_current_frame (); ; frame = prev_frame) { gdb/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between this frame and the new previous frame, not between this frame and the next frame. gdb/testsuite/ 2013-11-22 Pedro Alves <palves@redhat.com> PR 16155 * gdb.dwarf2/dw2-dup-frame.S: New file. * gdb.dwarf2/dw2-dup-frame.c: New file. * gdb.dwarf2/dw2-dup-frame.exp: New file.
2013-11-21Move types_deeply_equal from py-type.c to gdbtypes.c.Doug Evans4-187/+229
* gdbtypes.c: #include bcache.h, dwarf2loc.h. (type_equality_entry): Move here from python/py-type.c. (type_equality_entry_d): Ditto. (compare_maybe_null_strings, check_types_equal): Ditto. (check_types_worklist, types_deeply_equal): Ditto. * gdbtypes.h (types_deeply_equal): Declare. * python/py-type.c: Remove inclusion of bcache.h, dwarf2loc.h. (typy_richcompare): Update.
2013-11-22Check has_more in mi_create_dynamic_varobjYao Qi3-9/+18
Hi, I find "has_more" is not checked when a dynamic varobj is created in proc mi_create_dynamic_varobj. This patch adds the check to "has_more". gdb/testsuite: 2013-11-22 Yao Qi <yao@codesourcery.com> * lib/mi-support.exp (mi_create_dynamic_varobj): Update comment and add one more argument "has_more". * gdb.python/py-mi.exp: Callers update.
2013-11-22Use mi_create_floating_varobjYao Qi2-2/+7
In gdb.python/py-mi.exp, two varobjs container and nscont are created when pretty-printing is still not enabled, so they are not dynamic varobj, IIUC. In this patch, we use mi_create_floating_varobj instead of mi_create_dynamic_varobj. gdb/testsuite: 2013-11-22 Yao Qi <yao@codesourcery.com> * gdb.python/py-mi.exp: Use mi_create_floating_varobj instead of mi_create_dynamic_varobj.
2013-11-21Doc 'dynamic' for command -var-list-childrenYao Qi2-0/+11
Hi, I find "dynamic=1" appear in the result of each child of the output of -var-list-children, -var-list-children ss1 ^done,numchild="2",children=[child={name="ss1.a",exp="a",numchild="0",type="struct s",thread-id="1",dynamic="1"},child={name="ss1.b",exp="b",numchild="0",type="struct s",thread-id="1",dynamic="1"}],has_more="0" but the doc doesn't mention this. This patch is to copy the description of "dynamic=1" here. gdb/doc: 2013-11-21 Yao Qi <yao@codesourcery.com> * gdb.texinfo (GDB/MI Variable Objects): Add attribute 'dynamic' for the output of command -var-list-children.
2013-11-21s/see @pxref/@pxref in docYao Qi2-1/+6
Looks "see" is unnecessary before @pxref. gdb/doc: 2013-11-21 Yao Qi <yao@codesourcery.com> * gdb.texinfo (Caching Target Data): Remove "see" before @pxref.
2013-11-20 * linux-low.c (linux_set_resume_request): Fix comment.Doug Evans2-3/+9
2013-11-20 * linux-low.c (resume_status_pending_p): Tweak comment.Doug Evans2-1/+6
2013-11-20Add missing ChangeLog entry.Pedro Alves1-0/+5
2013-11-20 Pedro Alves <palves@redhat.com> * gdb.base/maint.exp (maint print objfiles): Consume one line at a time, and run it through all three milestone regexes.
2013-11-20get rid of py-value.c:is_intlike (use is_integral_type instead)Joel Brobecker2-15/+11
is_intlike was mostly duplicating is_integral_type, with the exception of the handling of TYPE_CODE_PTR when parameter PTR_OK is nonzero. This patches deletes the is_intlike function, using is_integral_type instead, and adjusting the two locations where this function gets called. The code should remain strictly equivalent. gdb/ChangeLog: * python/py-value.c (is_intlike): Delete. (valpy_int): Replace use of CHECK_TYPEDEF and is_intlike by use of is_integral_type. (valpy_long): Replace use of CHECK_TYPEDEF and is_intlike by use of is_integral_type and check for TYPE_CODE_PTR.
2013-11-20Make the maint.exp:'maint print objfiles' test less fragile.Pedro Alves1-3/+12
I was "lucky" enough that an unrelated patch changed how many symtabs GDB expands in a plain run to main, and that triggered a latent issue in this test: PASS: gdb.base/maint.exp: maint print objfiles: header PASS: gdb.base/maint.exp: maint print objfiles: psymtabs FAIL: gdb.base/maint.exp: maint print objfiles: symtabs The problem is in my case, expect is managing to alway put in the buffer chunks like this: Psymtabs: ../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0, Symtabs: ../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0, Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms Psymtabs: bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at 0x1f65290, ... Note: Psymtabs:/Symtabs:/Psymtabs:. So, the loop matches the first Psymtabs in the buffer. Then we're left with ../../../src/gdb/testsuite/gdb.base/break1.c at 0x1ed2280, ../../../src/gdb/testsuite/gdb.base/break.c at 0x1ed21d0, Symtabs: ../../../src/gdb/testsuite/gdb.base/break.c at 0x1f044f0, /usr/include/stdio.h at 0x1ed25a0, /usr/include/libio.h at 0x1ed2510, /usr/include/bits/types.h at 0x1ed2480, /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include/stddef.h at 0x1ed23f0, Object file /usr/lib/debug/lib64/ld-2.15.so.debug: Objfile at 0x1f4bff0, bfd at 0x1f2d940, 0 minsyms Psymtabs: bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at 0x1f65290, ... In the next iteration, because the psymtabs regex comes first, we match with the Psymtabs: line, then of course, end up with just bsearch.c at 0x1f65340, ../sysdeps/x86_64/multiarch/init-arch.c at 0x1f65290, ... in the buffer. The "Symtabs:" line is lost. expect then reads more gdb output, and manages to again retrieve the same pattern. Rinse, repeat, and the test never matches any "Symtab:" line. We don't know the order the matches lines will appear, so the fix is to consume one line at a time, and run it through all three milestone regexes. gdb/testsuite/ 2013-11-20 Pedro Alves <palves@redhat.com> * gdb.base/maint.exp (maint print objfiles): Consume one line at a time, and run it through all three milestone regexes.
2013-11-20remove strerror moduleTom Tromey17-2230/+84
This fixes the mingw build breakage reported by Pierre. I found that the gnulib strerror module somehow requires us to pull in the gethostname module. However, pulling in the gethostname module makes many things break. I've sent a bug report to gnulib. Meanwhile, removing the strerror module should not harm gdb and fixes the build. I'm checking this in. 2013-11-20 Tom Tromey <tromey@redhat.com> * gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Remove strerror module. * gnulib/aclocal.m4: Update. * gnulib/config.in: Update. * gnulib/configure: Update. * gnulib/import/Makefile.am: Update. * gnulib/import/Makefile.in: Update. * gnulib/import/errno.in.h: Remove. * gnulib/import/intprops.h: Remove. * gnulib/import/m4/errno_h.m4: Remove. * gnulib/import/m4/gnulib-cache.m4: Update. * gnulib/import/m4/gnulib-comp.m4: Update. * gnulib/import/m4/strerror.m4: Remove. * gnulib/import/m4/sys_socket_h.m4: Remove. * gnulib/import/strerror-override.c: Remove. * gnulib/import/strerror-override.h: Remove. * gnulib/import/strerror.c: Remove. * gnulib/update-gnulib.sh: Update.
2013-11-20test: test eval routines with EVAL_AVOID_SIDE_EFFECTS flag setSanimir Agovic2-0/+44
Ensure that certain commands (e.g. whatis/ptype) and sizeof intrinsic have no side effects (variables cannot be altered). 2013-11-20 Sanimir Agovic <sanimir.agovic@intel.com> testsuite/ * gdb.base/eval-avoid-side-effects.exp: New test.
2013-11-20set_address_space_data if dcache is NULL.Yao Qi2-1/+10
gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * target-dcache.c (target_dcache_get_or_init): Call set_address_space_data if 'dcache' is NULL.
2013-11-20Add MPX registers tests.Walfred Tedeschi5-1/+250
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com> * common/i386-gcc-cpuid.h (bit_MPX): Synchronize with gcc file. testsuite/ * gdb.arch/i386-mpx.c: New file * gdb.arch/i386-mpx.exp: New file. Change-Id: Ica4c9ee823c8210ca876e31f27dcd8583b660a9f Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
2013-11-20Add pretty-printer for MPX bnd registers.Walfred Tedeschi5-4/+61
Boundary length is simpler implemented by means of a pretty printer. This simplifies users life when examining a bound register. Changelog: 2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com> * python/lib/gdb/command/bound_register.py: New file. * gdb/data-directory/Makefile.in: copy bond_register.py to the right path to be initialized at gdb startup. testsuite/ * gdb.python/py-pp-maint.exp: Consider new pretty-print added for registers. Change-Id: Id4f39845e5ece56c370a1fd4343648909f08b731 Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com> Conflicts: gdb/ChangeLog
2013-11-20Add MPX support to gdbserver.Walfred Tedeschi5-26/+197
2013-05-22 Walfred Tedeschi <walfred.tedeschi@intel.com> gdbserver/ * Makefile.in: Add i386-mpx.c, i386-mpx-linux.c, amd64-mpx.c, amd64-mpx-linux.c, x32-mpx.c and x32-mpx-linux.c generation. * configure.srv (srv_i386_regobj): Add i386-mpx.o. (srv_i386_linux_regobj): Add i386-mpx-linux.o. (srv_amd64_regobj): Add amd64-mpx.o. (srv_amd64_linux_regobj): Add amd64-mpx-linux.o. (srv_i386_32bit_xmlfiles): Add i386/32bit-mpx.xml. (srv_i386_64bit_xmlfiles): Add i386/64bit-mpx.xml. * i387-fp.c (num_pl_bnd_register) Added constant. (num_pl_bnd_cfg_registers) Added constant. (struct i387_xsave) Added reserved area and MPX fields. (i387_cache_to_xsave, i387_xsave_to_cache) Add MPX. * linux-x86-low.c (init_registers_i386_mpx_linux): Declare new function. (tdesc_i386_mpx_linux): Add MPX amd64 target. (init_registers_amd64_mpx_linux): Declare new function. (tdesc_amd64_mpx_linux): Add MPX amd64 target. (x86_64_regmap): Add MPX registers. (x86_linux_read_description): Add MPX case. (initialize_low_arch): Initialize MPX targets. Change-Id: I394d81afa76d11375ce792cefad0ceb9825fb379 Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
2013-11-20MPX for amd64Walfred Tedeschi6-13/+88
2013-06-24 Walfred Tedeschi <walfred.tedeschi@intel.com> * amd64-linux-nat.c (amd64_linux_gregset32_reg_offset): Add MPX registers. (amd64_linux_read_description): Add initialization for MPX and AVX independently. * amd64-linux-tdep.c: Includes features/i386/amd64-mpx-linux.c. (amd64_linux_gregset_reg_offset): Add MPX registers. (amd64_linux_core_read_description): Add initialization for MPX registers. (_initialize_amd64_linux_tdep): Initialize MPX targets. * amd64-linux-tdep.h (AMD64_LINUX_RAX_REGNUM): Set it to the last register on the list. (tdesc_amd64_mpx_linux) Add new target for MPX. * amd64-tdep.c: Includes features/i386/amd64-mpx.c. (amd64_mpx_names): MPX register names. (amd64_init_abi): Add MPX register while initializing the ABI. (_initialize_amd64_tdep): Initialize MPX targets. * amd64-tdep.h (amd64_regnum): Add MPX registers. (AMD64_NUM_REGS): Set number of registers taking MPX into account. Change-Id: I4a785c181e2fb45e4086650b2f87426caeb2f800 Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com> Conflicts: gdb/ChangeLog
2013-11-20Add MPX support for i386Walfred Tedeschi9-23/+466
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com> * i386-linux-nat.c (GETXSTATEREGS_SUPPLIES): Add MPX registers on the range of registers to be read from xsave buffer. (i386_linux_read_description): Add case for MPX. * i386-linux-tdep.c: Include features/i386/i386-mpx-linux.c. (i386_linux_gregset_reg_offset): Add MPX registers. (i386_linux_core_read_description): Initialize also MPX. (_initialize_i386_linux_tdep): Add mpx initialization. * i386-tdep.h (gdbarch_tdep): Add fields bnd0r_regnum, bnd0_regnum, mpx_register_names. (i386_regnum): Add MPX registers. (I386_MPX_NUM_REGS): New macro. (i386_bnd_regnum_p): New function. * i386-linux-tdep.h (I386_LINUX_NUM_REGS): Set number of registers to be the number of BNDSTATUS. (tdesc_i386_mpx_linux): Add description for MPX Linux registers. * i386-tdep.c: Include features/i386/i386-mpx.c. (i386_mpx_names): Add MPX register names array. (i386_bnd_names): Add bnd pseudo register names array. (i386_bndr_regnum_p): Lookup register numbers for bnd raw registers. (i386_bndr_regnum_p): Lookup register numbers for bnd raw registers. (386_mpx_ctrl_regnum_p): Lookup register numbers for MPX control registers. (i386_bnd_type): New function. (i386_pseudo_register_type): Use i386_bnd_type for bnd pseudo register types. (i386_pseudo_register_read_into_value): Add bnd case. (i386_pseudo_register_write): Add bnd pseudo registers. (i386_register_reggroup_p): Add MPX register to the group all. (i386_validate_tdesc_p): Add MPX to the target description validation. (i386_pseudo_register_name): Add bnd pseudo registers. (i386_gdbarch_init): Add MPX for architecture initialization. (_initia_initialize_i386_tdep): Add mpx initialization. * i387-tdep.c (xsave_mpx_offset): New vector for MPX offsets on XSAVE buffer. (XSAVE_MPX_ADDR): New macro. (i387_supply_xsave): Add MPX case. (i387_collect_xsave): Add MPX case. * i387-tdep.h (I387_BND0R_REGNUM): New macro. (I387_BNDCFGU_REGNUM): New macro. (I387_NUM_MPX_REGS): New macro. (I387_NUM_BND_REGS): New macro. (I387_NUM_MPX_CTRL_REGS): New macro. (I387_MPXEND_REGNUM): New macro. * common/i386-xstate.h (I386_XSTATE_BNDREGS): New macro. (I386_XSTATE_BNDCFG): Likewise. (I386_XSTATE_MPX_MASK): Likewise. (I386_XSTATE_ALL_MASK): New macro represents flags for all states. (I386_XSTATE_BNDREGS_SIZE): New macro. (I386_XSTATE_BNDCFG_SIZE): Likewise. (I386_XSTATE_SIZE): Adapt for MPX. (I386_XSTATE_MAX_SIZE): Likewise. Change-Id: I9ddb7d49434d86fa18eb6b99515203d7c567aefd Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com> Conflicts: gdb/ChangeLog
2013-11-20Add MPX registers XML files.Walfred Tedeschi16-0/+1262
2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com> * features/i386/Makefile: Adapts for using MPX registers. * features/i386/32bit-mpx.xml: New file. * features/i386/64bit-mpx.xml: Likewise. * features/i386/amd64-mpx-linux.c: Likewise. * features/i386/amd64-mpx-linux.xml: Likewise. * features/i386/amd64-mpx.c: Likewise. * features/i386/amd64-mpx.xml: Likewise. * features/i386/i386-mpx-linux.c: Likewise. * features/i386/i386-mpx-linux.xml: Likewise. * features/i386/i386-mpx.c: Likewise. * features/i386/i386-mpx.xml: Likewise. * regformats/i386/amd64-mpx-linux.dat: New file. * regformats/i386/amd64-mpx.dat: Likewise. * regformats/i386/i386-mpx-linux.dat: Likewise. * regformats/i386/i386-mpx.dat: Likewise.
2013-11-20Fix conditions in creating a bitfield.Walfred Tedeschi4-1/+13
Bitfields are represented by intervals [start, begin]. It means that for an interval comprised by only one bit start and end will be equal. The present condition does not always hold. On the other hand in target-description.c (tdesc_gdb_type) bitfield is created when "f->type" is null. The routine maint_print_maint_print_c_tdesc_cmd is modified to follow the same strategy. 2013-11-20 Walfred Tedeschi <walfred.tedeschi@intel.com> * target-descriptions.c (maint_print_maint_print_c_tdesc_cmd): Modified logic of creating a bitfield to be in sync with tdesc_gdb_type. testsuite/ * gdb.xml/maint_print_struct.xml (bitfield): Added bitfield having start and end equal 0. Change-Id: I8c62db049995f0c0c30606d9696b86afe237cbb9
2013-11-20gdb/arm-tdep.c: Remove "Infinite loop detected" error message.Will Newton2-10/+7
Since as far back as the beginning of the sourceware repository the ARM port has printed an error "Infinite loop detected" when the next_pc calculated is the same as the current one, for example when encountering a branch to the current PC address. This causes the test gdb.base/random-signal.exp as the error message is not expected. I have not been able to find a good reason for the message to be here so remove it and let the test pass. gdb/ChangeLog: 2013-11-20 Will Newton <will.newton@linaro.org> * arm-tdep.c (arm_get_next_pc): Remove "Infinite loop detected" error message.
2013-11-20Associate target_dcache to address_space.Yao Qi5-14/+65
Hi, Nowadays, 'target_dcache' is a global variable in GDB, which is not necessary. It can be a per-address-space variable. In this patch, we associate target_dcache to address_space. gdb/doc: 2013-11-20 Yao Qi <yao@codesourcery.com> * gdb.texinfo (Caching Target Data): Update doc for per-address-space dcache. gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * progspace.h (struct address_space_data): Declare. * target-dcache.c: Include "progspace.h". (target_dache): Remove. (target_dcache_aspace_key): New. (target_dcache_cleanup): New function. (target_dcache_init_p): Get data through target_dcache_aspace_key. (target_dcache_invalidate): Likewise. (target_dcache_get): Likewise. (target_dcache_get_or_init): Likewise. (_initialize_target_dcache): Initialize target_dcache_aspace_key.
2013-11-20Add REGISTRY for struct address_space.Yao Qi3-4/+28
This patch adds REGISTRY for struct address_space. gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * progspace.c (struct address_space): Update comments. <REGISTRY_FIELDS>: New fields. DEFINE_REGISTRY for address_space. (new_address_space): Call address_space_alloc_data. (free_address_space): Call address_space_free_data. * progspace.h: Use DECLARE_REGISTRY.
2013-11-20Don't stress 'remote' in "Data Caching" in docYao Qi2-15/+22
When I try to describe the cache and its related commands (in a cache-per-address-space world), I find hard to add, because existing doc is focused on remote debugging, while data cache is used regardless of the target. More precisely, GDB cache target data, instead of remote data. gdb/doc: 2013-11-20 Yao Qi <yao@codesourcery.com> * gdb.texinfo (Data): Rename menu item. (Caching Remote Data): Rename to ... (Caching Target Data): ... it. Update.
2013-11-20Move target-dcache out of target.cYao Qi10-92/+185
This patch moves target_dcache related code out of target.c. gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * Makefile.in (SFILES):Add target-dcache.c. (HFILES_NO_SRCDIR): Add target-dcache.h. (COMMON_OBS): Add target-dcache.o. * dcache.c: Remove inclusion to "target.h". Include "target-dcache.h". * memattr.c: Include "target-dcache.h". * top.c: Likewise. * tracepoint.c: Likewise. * target.c: (stack_cache_enabled_p_1): Move to target-dcache.c. (stack_cache_enabled_p): Likewise. (set_stack_cache_enabled_p): Likewise. (show_stack_cache_enabled_p): Likewise. (target_dcache, target_dcache_init_p): Likewise. (target_dcache_invalidate): Likewise. (target_dcache_get, target_dcache_get_or_init): Likewise. (memory_xfer_partial_1): Call function stack_cache_enabled. (initialize_target): Move code to target-dcache.c. * target.h (target_dcache_invalidate): Move to target-dcache.h. (target_dcache_get): Likewise. * target-dcache.c: New. * target-dcache.h: New.
2013-11-20Don't update target_dcache if it is not initializedYao Qi2-1/+7
After previous patch, 'target_dcache' is initialized lazily. It is possible that 'target_dcache' is still NULL when GDB writes to memory. In this case, update to 'target_dcache' can be skipped. gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * target.c (memory_xfer_partial_1): Update 'target_dcache' if it is initialized.
2013-11-20Remove last_cacheYao Qi4-32/+86
This patch removes global variable 'last_cache', and initialize 'target_dcache' lazily, so that 'target_dcache' can replace 'last_cache'. No functionalities should be changed after this patch. gdb: 2013-11-20 Yao Qi <yao@codesourcery.com> * dcache.c (last_cache): Remove. (dcache_free, dcache_init): Update. (dcache_update): (dcache_print_line): Add parameter 'dcache'. Replace 'target_dcache' with 'dcache'. (dcache_info): Move code to dcache_info_1. Call 'dcache_info_1'. (dcache_info_1): New function. (set_dcache_size): Call target_dcache_invalidate. (set_dcache_line_size): Call target_dcache_invalidate. * target.c (target_dcache_init_p): New function. (target_dcache_invalidate): Check target_dcache_init_p first. (target_dcache_get, target_dcache_get_or_init): New function. (memory_xfer_partial_1): Adjust. (initialize_target): Don't initialize 'target_dcache'. * target.h (struct dcache_struct): Declare. (target_dcache_get): Declare.
2013-11-20Move changelog entry to the right ChangeLogYao Qi2-5/+5
2013-11-19Remove unnecessary '\'.Yao Qi2-2/+6
Hi, In proc mi_child_regexp, \(,thread-id=\"\[0-9\]+\") is appended to children_exp, while the first '\' is not necessary. This patch is to remove it. With this patch applied, Emacs can find the right left paren. gdb/testsuite: 2013-11-19 Yao Qi <yao@codesourcery.com> * lib/mi-support.exp (mi_child_regexp): Remove unnecessary '\'.
2013-11-19Fix format issues in lib/mi-support.expYao Qi2-278/+282
There are some format issues in lib/mi-support.exp, such as using spaces instead of tab and trailing spaces. This patch is to fix them. gdb/testsuite: 2013-11-19 Yao Qi <yao@codesourcery.com> * lib/mi-support.exp: Fix format.
2013-11-19Remove 'whatever' in lib/mi-support.expYao Qi2-3/+5
Variable 'whatever' is not used at all. This patch is to remove it. gdb/testsuite: 2013-11-19 Yao Qi <yao@codesourcery.com> * lib/mi-support.exp (mi_child_regexp): Remove 'whatever'. (mi_list_varobj_children_range): Likewise.
2013-11-19Fix typoYao Qi2-1/+5
Hi, "It's" should be "Its". This patch is to fix it. Committed as obvious. gdb: 2013-11-19 Yao Qi <yao@codesourcery.com> * varobj.c (varobj_get_type): Fix typo.
2013-11-19Fix int() builtin with range type gdb.Value objects.Joel Brobecker7-0/+126
Consider the following variable: type Small is range -128 .. 127; SR : Small := 48; Trying to get its value as an integer within Python code yields: (gdb) python sr = gdb.parse_and_eval('sr') (gdb) python print int(sr) Traceback (most recent call last): File "<string>", line 1, in <module> gdb.error: Cannot convert value to int. Error while executing Python code. This is happening because our variable is a range type, and py-value's is_intlike does not handle TYPE_CODE_RANGE. This patch fixes this. gdb/ChangeLog: * python/py-value.c (is_intlike): Add TYPE_CODE_RANGE handling. gdb/testsuite/ChangeLog: * gdb.ada/py_range: New testcase.
2013-11-19gdb_ari.sh: Remove entries for dirent.h and stat.h.Joel Brobecker2-18/+5
The corresponding gdb_dirent.h and gdb_stat.h no longer exist. We rely on gnulib for those, now. gdb/ChangeLog: * contrib/ari/gdb_ari.sh: Remove checks for "dirent.h" and "stat.h".
2013-11-18remove gdb_stat.hTom Tromey35-92/+70
This patch is purely mechanical. It removes gdb_stat.h and changes the code to use sys/stat.h. 2013-11-18 Tom Tromey <tromey@redhat.com> * common/gdb_stat.h: Remove. * ada-lang.c: Use sys/stat.h, not gdb_stat.h. * common/filestuff.c: Use sys/stat.h, not gdb_stat.h. * common/linux-osdata.c: Use sys/stat.h, not gdb_stat.h. * corefile.c: Use sys/stat.h, not gdb_stat.h. * ctf.c: Use sys/stat.h, not gdb_stat.h. * darwin-nat.c: Use sys/stat.h, not gdb_stat.h. * dbxread.c: Use sys/stat.h, not gdb_stat.h. * dwarf2read.c: Use sys/stat.h, not gdb_stat.h. * exec.c: Use sys/stat.h, not gdb_stat.h. * gdbserver/linux-low.c: Use sys/stat.h, not gdb_stat.h. * gdbserver/remote-utils.c: Use sys/stat.h, not gdb_stat.h. * inf-child.c: Use sys/stat.h, not gdb_stat.h. * jit.c: Use sys/stat.h, not gdb_stat.h. * linux-nat.c: Use sys/stat.h, not gdb_stat.h. * m68klinux-nat.c: Use sys/stat.h, not gdb_stat.h. * main.c: Use sys/stat.h, not gdb_stat.h. * mdebugread.c: Use sys/stat.h, not gdb_stat.h. * mi/mi-cmd-env.c: Use sys/stat.h, not gdb_stat.h. * nto-tdep.c: Use sys/stat.h, not gdb_stat.h. * objfiles.c: Use sys/stat.h, not gdb_stat.h. * procfs.c: Use sys/stat.h, not gdb_stat.h. * remote-fileio.c: Use sys/stat.h, not gdb_stat.h. * remote-mips.c: Use sys/stat.h, not gdb_stat.h. * remote.c: Use sys/stat.h, not gdb_stat.h. * rs6000-nat.c: Use sys/stat.h, not gdb_stat.h. * sol-thread.c: Use sys/stat.h, not gdb_stat.h. * solib-spu.c: Use sys/stat.h, not gdb_stat.h. * source.c: Use sys/stat.h, not gdb_stat.h. * symfile.c: Use sys/stat.h, not gdb_stat.h. * symmisc.c: Use sys/stat.h, not gdb_stat.h. * symtab.c: Use sys/stat.h, not gdb_stat.h. * top.c: Use sys/stat.h, not gdb_stat.h. * xcoffread.c: Use sys/stat.h, not gdb_stat.h.