Commit graph

33556 commits

Author SHA1 Message Date
Walfred Tedeschi
244ec0da38 Fix PR16193 - gdbserver aborts.
The MPX patch has broken the I386_XSTATE_SIZE macro.  For AVX machines,
it ends up returning I386_XSTATE_SSE_SIZE.  Where it first reads
I386_XSTATE_AVX_SIZE, it should have read I386_XSTATE_AVX:

 #define I386_XSTATE_SIZE(XCR0) \
     (((XCR0) & I386_XSTATE_BNDCFG) != 0 ? I386_XSTATE_BNDCFG_SIZE \
        : (((XCR0) & I386_XSTATE_BNDREGS) != 0 ? I386_XSTATE_BNDCFG_SIZE \
 -       : (((XCR0) & I386_XSTATE_AVX_SIZE) != 0 ? I386_XSTATE_AVX_SIZE \
 +       : (((XCR0) & I386_XSTATE_AVX) != 0 ? I386_XSTATE_AVX_SIZE \
        : I386_XSTATE_SSE_SIZE)))

The patch goes a step further and improves readability of the macro,
by adding a couple other auxiliary macros.


2013-11-26  Walfred Tedeschi  <walfred.tedeschi@intel.com>

	* i386-xstate.h (I386_XSTATE_MPX): New Macro.
	(I386_XSTATE_MPX_MASK): Makes use of I386_XSTATE_MPX.
	(HAS_MPX): New macro.
	(HAS_AVX): New macro.
	(I386_XSTATE_SIZE): Uses HAS_MPX and HAS_AVX.
2013-11-26 08:32:16 +00:00
Keith Seitz
f7e3ecae9f PR c++/14819: Explicit class:: inside class scope does not work
https://sourceware.org/ml/gdb-patches/2013-11/msg00102.html
2013-11-25 13:37:08 -08:00
Yao Qi
23e9d3b9ce GDB perf test on backtrace
gdb/testsuite/

2013-11-25  Yao Qi  <yao@codesourcery.com>

	* gdb.perf/backtrace.c: New.
	* gdb.perf/backtrace.exp: New.
	* gdb.perf/backtrace.py: New.
2013-11-25 09:12:38 +08:00
Yao Qi
283f7163ec Use target_read_code in disassemble.
This patch teaches "disassembly" use code cache mechanism to read
target code.

gdb:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* disasm.c (dis_asm_read_memory): Call target_read_code
	instead of target_read_memory.
2013-11-24 14:56:51 +08:00
Yao Qi
29453a1455 set/show code-cache
Similar to stack cache, in this patch, we add
TARGET_OBJECT_CODE_MEMORY to read code from target and add a new
option "set code-cache on|off" to optimize code accesses by
using the target memory cache.

In V4:
 - Remove "without affecting correctness" from NEWS and doc.
 - Replace "ON" with "on" in doc.
 - "access" -> "accesses".

In V3:
 - Rename functions and variables.
 - Update command help, doc and NEWS entry.
 - Invalidate cache on option transitions, to align with
   the behaviour of "stack-cache".  Since cache invalidation is
   transparent to users, users don't know option "stack-cache"
   transitions cause code cache invalidation.

V2 was reviewed by Doug.  There are some changes in V3, so I post it
here.

gdb:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* NEWS: Add note on new "set code-cache" option.
	* target-dcache.c (code_cache_enabled_1): New variable.
	(code_cache_enabled): New variable.
	(show_code_cache, set_code_cache): New function.
	(code_cache_enabled_p): New function.
	(_initialize_target_dcache): Register command.
	* target-dcache.h (code_cache_enabled_p): Declare.
	* target.c (memory_xfer_partial_1):Handle
	TARGET_OBJECT_CODE_MEMORY and code_cache_enabled.
	(target_read_code): New function.
	* target.h (enum target_object) <TARGET_OBJECT_CODE_MEMORY>:
	New.
	(target_read_code): Declare.

gdb/doc:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* gdb.texinfo (Caching Remote Data): Document new
	"set/show stack-cache" option.
2013-11-24 14:56:49 +08:00
Yao Qi
0fb14d8ffd Renaming in target-dcache.c
Hi,
This patch does some renamings on "stack-cache" related functions and
variables.

In the review to "code cache" series v2, we have some discussions on the
name of predicate function 'stack_cache_enabled', and have some options,

 1 keep it unchanged, as it is already a predicate clearly,
 2 rename it to stack_cache_enabled_p,
 3 rename it to enable_stack_cache_p,

I choose #2, because 'stack_cache_enabled' is a predicate, but
it's better to add "_p" suffix to stress this.  There are some other
similar patterns used in GDB source, such as unop_user_defined_p
and agent_loaded_p.

Then, I have to rename variable stack_cache_enabled_p to something
else.  The option is "stack-cache", so I'd like to name the variable
associated with this command as "stack_cache".  Similarly, the commands
associated with this command should be renamed to "set_stack_cache"
and "show_stack_cache" respectively.

gdb:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* target-dcache.c (stack_cache_enabled_p_1): Rename to ...
	(stack_cache_enabled_1): ... this.  New variable.
	(stack_cache_enabled_p): Rename to ...
	(stack_cache_enabled): ... this.  New variable.
	(set_stack_cache_enabled_p): Rename to ...
	(set_stack_cache): ... this.  Update caller.
	(show_stack_cache_enabled_p): Rename to ...
	(show_stack_cache): ... this.  Update caller.
	(stack_cache_enabled): Rename to ...
	(stack_cache_enabled_p): ... this.  Update caller.
	(_initialize_target_dcache): Replace "data cache" with
	"target memory cache".
	* target-dcache.h (stack_cache_enabled): Remove declaration.
	(stack_cache_enabled_p): Add declaration.
2013-11-24 14:56:48 +08:00
Yao Qi
22825df749 GDB perf test on single step
gdb/testsuite:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* gdb.perf/single-step.c: New.
	* gdb.perf/single-step.exp: New.
	* gdb.perf/single-step.py: New.
2013-11-24 14:33:31 +08:00
Yao Qi
6dd315bae3 Write "ON" and "OFF" in lower case in GDB doc.
gdb/doc:

2013-11-24  Yao Qi  <yao@codesourcery.com>

	* gdb.texinfo (Caching Target Data): Replace "ON" with "on".
	(Maintenance Commands): Replace "ON" and "OFF" with "on" and
	"off" respectively.
2013-11-24 11:11:39 +08:00
Doug Evans
c1ea7c017e * gdb.base/ena-dis-br.exp: Add missing quote to "step after continue
with ignore count".
2013-11-23 16:43:29 -08:00
Doug Evans
35720eaabd Test name tweaks for py-value.exp.
* gdb.python/py-value.exp (test_lazy_strings): Tweak test names.
	(test_subscript_regression): Ditto.
	(top level): Run test_subscript_regression for c++ with "c++" prefix.
2013-11-23 16:03:47 -08:00
Doug Evans
3cd14e4575 * gdb.python/py-type.exp (test_enums): Fix typo. 2013-11-23 15:54:05 -08:00
Doug Evans
985c818c2d * gdb.python/py-symbol.exp: Add some comments. Make all test names unique. 2013-11-23 15:45:43 -08:00
Doug Evans
f873dd7ade * gdb.python/py-symbol.exp: Fix whitespace. 2013-11-23 15:20:42 -08:00
Doug Evans
995c1ad93a Fix long line in earlier entry. 2013-11-23 15:15:17 -08:00
Doug Evans
38a502a410 * gdb.python/python.exp: Don't call skip_python_tests, we still want
to test some things in the case where python is not configured in.
2013-11-23 15:08:28 -08:00
Doug Evans
a12361b95c * python/py-frame.c (gdbpy_initialize_frames): Remove FIRST_ERROR,
superfluous.
2013-11-23 14:46:43 -08:00
Doug Evans
1e1d69201b * python/py-frame.c (frapy_block): Fix error message text. 2013-11-23 14:36:57 -08:00
Doug Evans
1e9c71b81b cli/cli-script.c (multi_line_command_p): New function.
* cli/cli-script.c (multi_line_command_p): New function.
	(recurse_read_control_structure, read_command_lines_1): Call it.
	(execute_control_command): Consistently have a blank line between
	each case.
2013-11-23 11:47:24 -08:00
Yao Qi
9df9dbe031 Update doc on displayhint in command -var-list-children
Hi,
When using command -var-list-children, "displayhint" appears in the result of
each child, shown as the following output.

-var-list-children  ss1  ^M
^done,numchild="2",displayhint="pp_ss",children=[child={name="ss1.a",exp="a",numchild="0",type="struct s",thread-id="1",displayhint="pp_s",dynamic="1"},child={name="ss1.b",exp="b",numchild="0",type="struct s",thread-id="1",displayhint="pp_s",dynamic="1"}],has_more="0"

Current doc on command -var-list-children doesn't reflect this.  This
patch is to fix it.

gdb/doc:

2013-11-23  Yao Qi  <yao@codesourcery.com>

	* gdb.texinfo (GDB/MI Variable Objects): Add the description
	of "displayhint" to the table about child results.
2013-11-23 20:33:11 +08:00
Sterling Augustine
38e1f2a7d5 2013-11-22 Sterling Augustine <saugustine@google.com>
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-22 14:25:14 -08:00
Sterling Augustine
f380848e84 2013-11-22 Sterling Augustine <saugustine@google.com>
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-22 13:58:55 -08:00
Pedro Alves
c0621699ff Rename gdb.dwarf2/dw2-bad-cfi.* to gdb.dwarf2/dw2-unspecified-ret-addr.*.
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-22 19:19:13 +00:00
Tom Tromey
f57e61cdf6 update comment in dw2-bad-cfi.S.
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-22 12:08:15 -07:00
Tom Tromey
da2b2fdf57 handle an unspecified return address column
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-22 11:02:01 -07:00
Tom Tromey
6eeee81c8e Detect infinite loop in value_fetch_lazy's lval_register handling.
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-22 17:38:44 +00:00
Pedro Alves
194cca4119 Make use of the frame stash to detect wider stack cycles.
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-22 13:53:39 +00:00
Pedro Alves
33f8fe58b9 Don't let two frames with the same id end up in the frame chain.
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-22 13:50:48 +00:00
Pedro Alves
1ec56e88aa Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (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-22 13:50:11 +00:00
Pedro Alves
8ad6489081 Revert "Don't let two frames with the same id end up in the frame chain."
This reverts commit be2c48b4d5.
2013-11-22 13:46:51 +00:00
Pedro Alves
c8381c86b4 Revert "Make use of the frame stash to detect wider stack cycles."
This reverts commit f5b0ed3c8c.
2013-11-22 13:46:43 +00:00
Pedro Alves
1bd122facc Revert "Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (move dwarf2_tailcall_sniffer_first elsewhere)."
This reverts commit 1dc8686c48.
2013-11-22 13:46:35 +00:00
Pedro Alves
1dc8686c48 Eliminate dwarf2_frame_cache recursion, don't unwind from the dwarf2 sniffer (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-22 13:41:59 +00:00
Pedro Alves
f5b0ed3c8c Make use of the frame stash to detect wider stack cycles.
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-22 13:41:43 +00:00
Pedro Alves
be2c48b4d5 Don't let two frames with the same id end up in the frame chain.
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-22 13:41:43 +00:00
Doug Evans
ca092b61dc Move types_deeply_equal from py-type.c to gdbtypes.c.
* 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-21 20:28:35 -08:00
Yao Qi
0a1e61210c Check has_more in mi_create_dynamic_varobj
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-22 08:34:42 +08:00
Yao Qi
0061ea2440 Use mi_create_floating_varobj
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-22 08:34:22 +08:00
Yao Qi
c78feb398f Doc 'dynamic' for command -var-list-children
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-21 11:41:55 +08:00
Yao Qi
27b81af3ea s/see @pxref/@pxref in doc
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-21 10:33:39 +08:00
Doug Evans
ebcf782c74 * linux-low.c (linux_set_resume_request): Fix comment. 2013-11-20 17:32:33 -08:00
Doug Evans
20ad937816 * linux-low.c (resume_status_pending_p): Tweak comment. 2013-11-20 16:31:48 -08:00
Pedro Alves
069d6a0fbf Add missing ChangeLog entry.
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-20 17:23:39 +00:00
Joel Brobecker
7c245c246c get rid of py-value.c:is_intlike (use is_integral_type instead)
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-20 21:20:11 +04:00
Pedro Alves
e48744a00a Make the maint.exp:'maint print objfiles' test less fragile.
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-20 17:12:37 +00:00
Tom Tromey
8986e351a4 remove strerror module
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-20 08:49:40 -07:00
Sanimir Agovic
10d8cbd222 test: test eval routines with EVAL_AVOID_SIDE_EFFECTS flag set
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-20 13:50:14 +00:00
Yao Qi
6b1141e3f3 set_address_space_data if dcache is NULL.
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-20 21:15:57 +08:00
Walfred Tedeschi
60650f2e2f Add MPX registers tests.
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-20 14:42:53 +01:00
Walfred Tedeschi
09748966c1 Add pretty-printer for MPX bnd registers.
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-20 14:42:53 +01:00
Walfred Tedeschi
a196ebeb91 Add MPX support to gdbserver.
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-20 14:42:52 +01:00