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.
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.
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.
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.
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 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.
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.
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.
free location in the text memory region, not a computation based
upon the size of the text section. Orphaned sections or other
linker scripts might insert new sections between the .text section
and the .data section.
* scripttempl/elf32msp430_3.sc (.data): Likewise.
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.
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.
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-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-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
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
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.
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.
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.
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.
ld/
* emultempl/elf32.em (gld${EMULATION_NAME}_before_allocation):
Don't use bfd_elf_record_link_assignment to mark __ehdr_start
hidden. Instead, just do it directly here, and only if it was
referenced but not defined.
ld/testsuite/
* ld-elf/ehdr_start-userdef.t: New file.
* ld-elf/ehdr_start-userdef.d: New file.
* ld-elf/ehdr_start-strongref.s: New file.
* ld-elf/ehdr_start-missing.t: New file.
* ld-elf/ehdr_start-missing.d: New file.
* ld-elf/ehdr_start-weak.d: New file.
* ld-mips-elf/ehdr_start-2.nd: Expect __ehdr_start to be global.
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 '\'.
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.
