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:
* main.c (get_init_files): Use filename_ncmp instead of strncmp.
Use IS_DIR_SEPARATOR instead of looking for a character inside
SLASH_STRING. Include filenames.h.
(captured_main) [__MINGW32__]: Make argv[0] absolute, so that
relocate_gdb_directory works when passed gdb_program_name.
Jan Kratochvil [Fri, 5 Apr 2013 19:17:27 +0000 (19:17 +0000)]
gdb/
Fix compatibility with Linux kernel 3.8.3.
* linux-tdep.c (linux_find_memory_regions_full): Move variable number
to more inner block. Remove parsing of NUMBER from outer block.
Parse NUMBER only if KEYWORD has been identified.
Pedro Alves [Thu, 4 Apr 2013 19:15:55 +0000 (19:15 +0000)]
tracepoint->step_count fixes
If a tracepoint's actions list includes a while-stepping action, and
then the actions are changed to a list without any while-stepping
action, the tracepoint's step_count will be left with a stale value.
For example:
(gdb) trace subr
Tracepoint 1 at 0x4004d9: file ../../../src/gdb/testsuite//actions-changed.c, line 31.
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $reg
>end
(gdb) set debug remote 1
(gdb) tstart
Sending packet: $QTinit#59...Packet received: OK
Sending packet: $QTDP:1:00000000004004d9:E:0:0-#a3...Packet received: OK
Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK
(gdb) tstop
Sending packet: $QTStop#4b...Packet received: OK
Sending packet: $QTNotes:#e8...Packet received: OK
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $reg
>while-stepping 1
>collect $reg
>end
>end
(gdb) tstart
Sending packet: $QTinit#59...Packet received: OK
Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF-#58...Packet received: OK
Sending packet: $QTDP:-1:00000000004004d9:SR03FFFFFFFFFFFFFFFFFF#7e...Packet received: OK
(gdb) tstop
Sending packet: $QTStop#4b...Packet received: OK
Sending packet: $QTNotes:#e8...Packet received: OK
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $regs
>end
(gdb) tstart
Sending packet: $QTinit#59...Packet received: OK
Sending packet: $QTDP:1:00000000004004d9:E:1:0-#a4...Packet received: OK
Sending packet: $QTDP:-1:00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK
A related issue is that the "commands" command actually supports
setting commands to a range of breakpoints/tracepoints at once. But,
hacking "maint info breakpoints" to print t->step_count, reveals:
(gdb) trace main
Tracepoint 5 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
(gdb) trace main
Note: breakpoint 5 also set at pc 0x45a2ab.
Tracepoint 6 at 0x45a2ab: file ../../src/gdb/gdb.c, line 29.
(gdb) commands 5-6
Type commands for breakpoint(s) 5-6, one per line.
End with a line saying just "end".
> while-stepping 5
>end
> end
(gdb) maint info breakpoints 5
Num Type Disp Enb Address What
5 tracepoint keep y 0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
step_count=5
^^^^^^^^^^^^
while-stepping 5
end
not installed on target
(gdb) maint info breakpoints 6
Num Type Disp Enb Address What
6 tracepoint keep y 0x000000000045a2ab in main at ../../src/gdb/gdb.c:29 inf 1
step_count=0
^^^^^^^^^^^^
while-stepping 5
end
not installed on target
(gdb)
that tracepoint 6 doesn't end up with the correct step_count.
validate_actionline is never called for tracepoints other than the
first (the copy_command_lines path). Right below, we have:
/* If a breakpoint was on the list more than once, we don't need to
do anything. */
if (b->commands != info->cmd)
{
validate_commands_for_breakpoint (b, info->cmd->commands);
incref_counted_command_line (info->cmd);
decref_counted_command_line (&b->commands);
b->commands = info->cmd;
observer_notify_breakpoint_modified (b);
}
And validate_commands_for_breakpoint looks like the right place to put
a call; if we reset step_count there too, we have a nice central fix
for the first issue as well, because trace_actions_command calls
breakpoint_set_commands that also calls
validate_commands_for_breakpoint.
We end up calling validate_actionline twice for the first tracepoint,
since read_command_lines calls it too, through
check_tracepoint_command, but that should be harmless.
2013-04-04 Pedro Alves <palves@redhat.com>
Hui Zhu <hui@codesourcery.com>
* breakpoint.c (validate_commands_for_breakpoint): If validating a
tracepoint, reset its STEP_COUNT and call validate_actionline.
2013-04-04 Stan Shebs <stan@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.trace/Makefile.in (PROGS): Add actions-changed.
* gdb.trace/actions-changed.c: New file.
* gdb.trace/actions-changed.exp: New file.
* lib/trace-support.exp (gdb_trace_setactions): Rename to ...
(gdb_trace_setactions_command): ... this. Add "actions_command"
parameter, and handle it.
(gdb_trace_setactions, gdb_trace_setcommands): New procedures.
Pedro Alves [Tue, 2 Apr 2013 18:01:06 +0000 (18:01 +0000)]
NEWS/manual: Missing documentation for new commands in 7.6.
I hacked "apropos" to dump the whole set of commands (just make it
accept the entry string as regex), and then diffed the output of 7.5
vs 7.6, --enable-targets=all builds. That allowed then checking
whether some commands had not been mentioned in NEWS or the manual.
These are what I found missing. We've been a bit negligent in
requiring documentation bits for debug commands.
Pedro Alves [Tue, 2 Apr 2013 13:54:21 +0000 (13:54 +0000)]
unpush the remote target if serial_write fails.
PR gdb/15275 notes that when debugging with a remote connection over a
serial link and the link is disconnected, say by disconnecting USB
serial port, the GDB quit command no longer works:
This is not reproducible with TCP connections, as with that, sending
doesn't error out, but instead the error is detected on the subsequent
readchar. When that read fails, we unpush the remote target, and
throw TARGET_CLOSE_ERROR. To address PR gdb/15275, instead of
catching the error in remote_get_trace_status as presently done (which
leaves this same issue latent for another packet to trip on), or of
making ser-unix.c fake success too on failed writes, so we'd get to
readchar detecting the error on serial ports too, better let the error
propagate out of serial_write, and catch it at the remote.c level,
throwing away the target if writing fails too, instead of delaying
that until the next read.
gdb/
2013-04-02 Pedro Alves <palves@redhat.com>
PR gdb/15275
* remote.c (send_interrupt_sequence): Use remote_serial_write.
(remote_serial_write): New function.
(putpkt_binary, getpkt_or_notif_sane_1): Use remote_serial_write.
projects / thirdparty / binutils-gdb.git / log
