Pedro Alves [Fri, 28 Jun 2013 12:39:00 +0000 (12:39 +0000)]
[PR tui/14880] Fetch values before comparing their contents.
PR tui/14880 shows a reproducer that triggers this assertion:
int
value_available_contents_eq (const struct value *val1, int offset1,
const struct value *val2, int offset2,
int length)
{
int idx1 = 0, idx2 = 0;
/* This routine is used by printing routines, where we should
already have read the value. Note that we only know whether a
value chunk is available if we've tried to read it. */
gdb_assert (!val1->lazy && !val2->lazy);
(top-gdb) bt
#0 internal_error (file=0x88a26c "../../src/gdb/value.c", line=549, string=0x88a220 "%s: Assertion `%s' failed.") at ../../src/gdb/utils.c:844
#1 0x000000000057b9cd in value_available_contents_eq (val1=0x10fa900, offset1=0, val2=0x10f9e10, offset2=0, length=8) at ../../src/gdb/value.c:549
#2 0x00000000004fd756 in tui_get_register (frame=0xd5c430, data=0x109a548, regnum=0, changedp=0x109a560) at ../../src/gdb/tui/tui-regs.c:736
#3 0x00000000004fd111 in tui_check_register_values (frame=0xd5c430) at ../../src/gdb/tui/tui-regs.c:521
#4 0x0000000000501884 in tui_check_data_values (frame=0xd5c430) at ../../src/gdb/tui/tui-windata.c:234
#5 0x00000000004f976f in tui_selected_frame_level_changed_hook (level=1) at ../../src/gdb/tui/tui-hooks.c:222
#6 0x00000000006f0681 in select_frame (fi=0xd5c430) at ../../src/gdb/frame.c:1490
#7 0x00000000005dd94b in up_silently_base (count_exp=0x0) at ../../src/gdb/stack.c:2268
#8 0x00000000005dd985 in up_command (count_exp=0x0, from_tty=1) at ../../src/gdb/stack.c:2280
#9 0x00000000004dc5cf in do_cfunc (c=0xd3f720, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:113
#10 0x00000000004df664 in cmd_func (cmd=0xd3f720, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:1888
#11 0x00000000006e43e1 in execute_command (p=0xc7e6c2 "", from_tty=1) at ../../src/gdb/top.c:489
The fix is to fetch the value before comparing the contents. The
comment additions to value.h explain why it can't be
value_available_contents_eq itself that fetches the contents.
Doug Evans [Thu, 27 Jun 2013 22:18:33 +0000 (22:18 +0000)]
PR 15519
* cp-namespace.c (find_symbol_in_baseclass): Call
cp_lookup_symbol_in_namespace instead of cp_lookup_symbol_namespace.
Check result of call to lookup_symbol_static.
Call lookup_static_symbol_aux unconditionally.
Call check_typedef on base types before accessing them.
(cp_lookup_nested_symbol): Fix comment.
testsuite/
* gdb.cp/derivation2.cc: New file.
* gdb.cp/derivation.cc (main): Call foo2.
* gdb.cp/derivation.exp: Add tests for typedefs in another
file, and when there's an active block.
testsuite/
* gdb.cp/derivation.exp: Make tests have unique names.
Hui Zhu [Wed, 26 Jun 2013 02:32:53 +0000 (02:32 +0000)]
2013-06-26 Yao Qi <yao@codesourcery.com>
Hui Zhu <hui@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/15075
PR breakpoints/15434
* breakpoint.c (bpstat_stop_status): Call
b->ops->after_condition_true.
(update_dprintf_command_list): Don't append "continue" command
to the command list of dprintf breakpoint.
(base_breakpoint_after_condition_true): New function.
(base_breakpoint_ops): Add base_breakpoint_after_condition_true.
(dprintf_after_condition_true): New function.
(initialize_breakpoint_ops): Set dprintf_after_condition_true.
* breakpoint.h (breakpoint_ops): Add after_condition_true.
2013-06-26 Yao Qi <yao@codesourcery.com>
Hui Zhu <hui@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR breakpoints/15075
PR breakpoints/15434
* gdb.base/dprintf-next.c: New file.
* gdb.base/dprintf-next.exp: New file.
* gdb.base/dprintf-non-stop.c: New file.
* gdb.base/dprintf-non-stop.exp: New file.
* gdb.base/dprintf.exp: Don't check "continue" in the output
of "info breakpoints".
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify):
Don't check "continue" in script field.
Pedro Alves [Fri, 10 May 2013 13:51:49 +0000 (13:51 +0000)]
PR remote/15455 - QTro remote packet broken
In the function remote_trace_set_readonly_regions in gdb/remote.c, the
local variable 'offset' does not account for "QTro" at the start of
the packet with the result that if there are any read-only regions,
the packet is sent -- but without the "QTro" -- causing the remote
stub to report that the packet is unsupported:
We don't see the problem when testing with GDBserver, as that supports
qXfer:trace-frame-info:read, meaning GDBserver never needs to read
from the read-only sections directly itself. This commit adds a test
that explicitly disables qXfer:trace-frame-info:read.
gdb/
2013-05-10 David Taylor <dtaylor@emc.com>
PR remote/15455
* remote.c (remote_trace_set_readonly_regions): Do not overwrite
"QTro" at start of packet.
gdb/testsuite/
2013-05-10 Pedro Alves <palves@redhat.com>
PR remote/15455
* gdb.trace/qtro.c: New file.
* gdb.trace/qtro.exp: New file.
Joel Brobecker [Fri, 10 May 2013 12:30:05 +0000 (12:30 +0000)]
move sparc-sol-thread.c back into sol-thread.c.
The routines in sparc-sol-thread used to be SPARC-specific (and
documented as such in the ptrace man page), and therefore hosting them
in a sparc-specific file made sense. However, newer versions of
Solaris now use those callbacks (Solaris 10 Update 10, apparently),
and thus the note about these callbacks being specific to SPARC
was removed.
So this patch deletes sparc-sol-thread.c and moves the code back
inside sol-thread.c.
PR breakpoints/15413:
* breakpoint.c (condition_completer): Simplify the code to
disconsider multiple locations of breakpoints when completing the
"condition" command.
PR breakpoints/15413:
* gdb.base/pending.exp: Add test for completion of the "condition"
command for pending breakpoints.
* gdb.linespec/linespec.ex: Add test for completion of the
"condition" command when dealing with multiple locations.
Andrew Haley found a bug on GDB running on ARM when using
--enable-64-bit-bfd. Basically the issue happens when dealing with "bl"
instructions: GDB does branch destination calculation and (wrongly)
sign-extends the PC. Here is a piece of his original message explaining
the problem:
> next_pc = arm_get_next_pc (frame, get_frame_pc (frame));
>
> /* The Linux kernel offers some user-mode helpers in a high page. We can
> not read this page (as of 2.6.23), and even if we could then we couldn't
> set breakpoints in it, and even if we could then the atomic operations
> would fail when interrupted. They are all called as functions and return
> to the address in LR, so step to there instead. */
> if (next_pc > 0xffff0000)
> next_pc = get_frame_register_unsigned (frame, ARM_LR_REGNUM);
>
> arm_insert_single_step_breakpoint (gdbarch, aspace, next_pc);
>
> Unfortunately, branch destination addresses are SIGN EXTENDED to 64
> bits. So,
>
> (top-gdb) p/x next_pc
> $14 = 0xffffffffb6df2864
>
> Which triggers the next_pc = get_frame_register_unsigned(), and we
> cannot step into any branches because the destination PC is wrong.
Anyway, the fix is simple and Andrew himself provided it for us. It
took a while for me to figure out how to trigger the bug (in order to
write a testcase for it), but I finally made it.
The attached patch fixes the problem (by casting to `unsigned long'
instead of just `long'), and also includes a testcase to reproduce the
issue.
gdb/ChangeLog:
2013-04-25 Andrew Haley <aph@redhat.com>
* arm-tdep.c (BranchDest): Cast result as "unsigned long",
instead of "long".
* breakpoint.c (dprintf_print_recreate): New.
(save_breakpoints): Let it not save dprintf commands.
(initialize_breakpoint_ops): Set dprintf_print_recreate.
Pedro Alves [Fri, 19 Apr 2013 14:15:51 +0000 (14:15 +0000)]
Fix the x87 FP register printout when issuing the “info float” command.
Consider the following simple program:
.globl _start
.text
_start:
fldt val
.data
val: .byte 0x00,0x00,0x45,0x07,0x11,0x19,0x22,0xe9,0xfe,0xbf
With current GDB on x86-64 GNU/Linux hosts, after the moment the fldt
command has been executed the register st(0) looks like this,
according to the “info regs” output (TOP=7):
which is clearly wrong (just count its length). The problem is due to
the printf statement (see patch) printing a promoted integer value of
a char argument "raw[i]", and, since char is signed on x86-64
GNU/Linux, the erroneous “ffffff” are printed for the first three
bytes which turn out to be "negative". The fix is to use gdb_byte
instead which is unsigned (and is the type of value_contents(), the
type to be used for raw target bytes anyway). After the fix the value
will be printed correctly:
projects / thirdparty / binutils-gdb.git / log
