... when !HAVE_PYTHON.
gdb/ChangeLog:
* varobj.c (update_dynamic_varobj_children) [!HAVE_PYTHON]:
Use gdb_assert_not_reached instead of invalid boolean expression.
The current throw_perror_with_name/TARGET_CLOSE_ERROR calls assume
errno is still set to the right error, although remote_unpush_target
is called in between, which may well change errno.
Tested on x86_64 Fedora 17 w/ gdbserver.
gdb/
2013-04-09 Pedro Alves <palves@redhat.com>
* remote.c (unpush_and_perror): New function.
(readchar, remote_serial_write): Use it.
* solib-som.c (som_solib_section_offsets): Use BFD section
indices. Set offsets for all sections.
* somread.c (som_symtab_read): Compute BFD section for
symbol. Use prim_record_minimal_symbol_and_info.
(som_symfile_read): Fix comment.
(struct find_section_offset_arg): New.
(find_section_offset, set_section_index): New functions.
(som_symfile_offsets): Use set_section_index to compute
section indices.
bfd/
* som.c (bfd_section_from_som_symbol): No longer static.
* som.h (bfd_section_from_som_symbol): Declare.
If !PARSE_CONDITION_AND_THREAD, then ARG is just the location, nothing
else. The fact that the describing comment of create_breakpoint
doesn't mention this just looks like an oversight of when extra_string
was added. "parse_condition_and_thread" has been a misnomer ever
since extra_string was added -- better rename it avoid more confusion.
This makes it "parse_arg", as that'll remain stable even if/when more
explicit parameters are added.
gdb/
2013-04-08 Pedro Alves <palves@redhat.com>
Keith Seitz <keiths@redhat.com>
* breakpoint.c (create_breakpoint): Rename
"parse_condition_and_thread" parameter to "parse_arg". Update
describing comment. If !PARSE_ARG, then error out if ARG is not
the empty string after extracting the location.
* breakpoint.h (create_breakpoint): Rename
"parse_condition_and_thread" parameter to "parse_arg".
gdb/testsuite/
2013-04-08 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-break.exp (test_error): Add tests with garbage after
the location.
* remote.c (remote_trace_find): Change type of parameters 'addr1'
and 'addr2' to CORE_ADDR.
* target.c (update_current_target): Update.
* target.h (struct target_ops) <to_trace_find>: Change parameter
type to CORE_ADDR.
* tracepoint.c (tfind_1): Change type of parameters 'addr1' and
'addr2' to CORE_ADDR.
(tfile_trace_find): Likewise.
(tfile_get_traceframe_address): Change return type to CORE_ADDR.
Change local variable 'addr' to type CORE_ADDR.
* tracepoint.h (tfind_1): Update declaration.
* gdb.texinfo (gdbserver man): Rename tty to comm. Swap --attach
parameters order. Remove "On some targets" for --attach. Document the
--multi parameter and extended-remote command. Document all the
options.
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.
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👎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👎00000000004004d9:R03FFFFFFFFFFFFFFFFFF-#58...Packet received: OK
Sending packet: $QTDP👎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👎00000000004004d9:R03FFFFFFFFFFFFFFFFFF#2b...Packet received: OK
The last "$QTDP:1:00000000004004d9:E:1:0-#a4" should be "$QTDP:1:00000000004004d9:E:0:0-#a3".
In pseudo-diff:
-$QTDP:1:00000000004004d9:E:1:0-#a4
+$QTDP:1:00000000004004d9:E:0:0-#a3
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.
The issue is that here:
static void
do_map_commands_command (struct breakpoint *b, void *data)
{
struct commands_info *info = data;
if (info->cmd == NULL)
{
struct command_line *l;
if (info->control != NULL)
l = copy_command_lines (info->control->body_list[0]);
else
{
struct cleanup *old_chain;
char *str;
str = xstrprintf (_("Type commands for breakpoint(s) "
"%s, one per line."),
info->arg);
old_chain = make_cleanup (xfree, str);
l = read_command_lines (str,
info->from_tty, 1,
(is_tracepoint (b)
? check_tracepoint_command : 0),
b);
do_cleanups (old_chain);
}
info->cmd = alloc_counted_command_line (l);
}
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.
read_die_and_siblings.
(read_die_and_siblings): New function.
(read_cutu_die_from_dwo): Dump die if requested.
(read_die_and_children): Call read_full_die_1 and
read_die_and_siblings_1.
(read_full_die): Dump die if requested.
* dwarf2read.c (read_comp_units_from_section): Add debugging printf.
Rename member name to dwo_name. All uses updated.
(hash_dwo_file): Include comp_dir in computation.
(eq_dwo_file): Ditto.
(lookup_dwo_file_slot): New arg comp_dir. All callers updated.
(create_dwo_in_dwp, lookup_dwo_in_dwp, open_and_init_dwo_file): Ditto.
x86_64/Cygwin is only mentioned as a new target, but we gained support
for building a native x86_64/Cygwin debugger too.
gdb/
2013-04-03 Pedro Alves <palves@redhat.com>
* NEWS: Mention x86_64/Cygwin as new native configuration.
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.
gdb/
2013-04-02 Pedro Alves <palves@redhat.com>
* NEWS: Mention "set/show debug aarch64", "set/show debug
coff-pe-read" and "set/show debug mach-o".
gdb/doc/
2013-04-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Debugging Output): Document "set/show debug
aarch64", "set/show debug coff-pe-read" and "set/show debug
mach-o".
The "New commands" section reads:
"New commands (for set/show, see "New options" below)"
gdb/
2013-04-02 Pedro Alves <palves@redhat.com>
* NEWS: Move "set debug notification" and "set trace-buffer-size"
under "New options".
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:
(gdb)
tar ext /dev/ttyACM0
&"tar ext /dev/ttyACM0\n"
~"Remote debugging using /dev/ttyACM0\n"
^done
(gdb)
set debug remote 1
&"set debug remote 1\n"
^done
(gdb)
quit
&"quit\n"
&"Sending packet: $qTStatus#49..."
&"putpkt: write failed: Input/output error.\n"
^error,msg="putpkt: write failed: Input/output error."
(gdb)
(gdb)
quit
&"quit\n"
&"Sending packet: $qTStatus#49..."
&"putpkt: write failed: Input/output error.\n"
^error,msg="putpkt: write failed: Input/output error."
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.
type_unit_group ...
(struct signatured_type): ... to here.
(sig_type_ptr): New typedef.
(type_unit_group): Delete member 't.first_cu'. Move member 'tus'
out of union 't'. All uses updated.
(dw2_get_file_names_reader): Assert not called for a type unit.
(dw2_get_file_names): Assert not called for a type unit or type
unit group.
(build_type_psymtabs_reader): Assert called for a type unit.
(build_type_psymtab_dependencies): Assert called for a type unit group.
Delete arg is_dwp. All callers updated.
(open_dwp_file): New function.
(open_and_init_dwp_file): Call it.
(get_dwp_file): New function.
(lookup_dwo_cutu): Call it.
2013-03-29 Yao Qi <yao@codesourcery.com>
* corelow.c: Include "completer.h".
(_initialize_corelow): Call add_target_with_completer with
argument 'filename_completer'.
* tracepoint.c: Likewise.
* exec.c (_initialize_exec): Likewise.
* target.c (add_target): Rename to ...
(add_target_with_completer): ... this. Call set_cmd_completer
if parameter completer is not NULL.
(add_target): New.
* target.h: Include "command.h".
(add_target_with_completer): Declare it.
gdb/testsuite:
2013-03-29 Yao Qi <yao@codesourcery.com>
* gdb.base/completion.exp: Test completion of commands
"target core", "target tfile" and "target exec".
* gdb.trace/tfile.exp: Test completion of command
"target tfile".
The debugger sometimes prints strange function names for given
addresses. For instance, with the following source code...
4 procedure Foo is
5 A : Integer;
6 begin
7 Do_Nothing (A'Address);
8 end Foo;
... we can see...
(gdb) info line 5
Line 5 of "foo.adb" starts at address 0x4017ca <_ada_foo+6>
and ends at 0x4017d2 <_fu29__system__scalar_values__is_is4+7>.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_fu29__system__scalar_values__is_is4 is an artificial symbol
generated by the linker, and interferes with the pc-to-symbol
resolution. There isn't much in the general minimal_symbol
data that could help us identify them, so this patch changes
the COFF reader to simply ignore them.
gdb/ChangeLog:
* coffread.c (is_import_fixup_symbol): New function.
(record_minimal_symbol): Use is_import_fixup_symbol to
detect import fixup symbols, and discard them.
gdb/testsuite/ChangeLog:
* gdb.ada/win_fu_syms: New testcase.
GDB currently sends a qTStatus even if the target previously replied
an empty packet to a previous qTStatus. If the target doesn't
recognize the packet, there's no point in trying again.
The machinery we have in place is packet_ok, which has the nice side
effect of forcing one to install a configuration command/knob for the
packet in question, which is often handy when you need to debug
things, and/or emulate a target that doesn't support the packet, or even,
it can be used as workaround for the old broken kgdb's that return error
to qTSTatus instead of an empty packet.
gdb/
2013-03-28 Pedro Alves <palves@redhat.com>
* NEWS (New options): New section.
(New options): Mention set/show remote trace-status-packet.
* remote.c (PACKET_qTStatus): New enumeration value.
(remote_get_trace_status): Skip sending qTStatus if the packet is
disabled. Use packet_ok.
(_initialize_remote): Register a configuration command for
qTStatus packet.
gdb/doc/
2013-03-28 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Remote Configuration) <set remote @var{name}-packet
table>: Add entry for "trace-status".
(compute_symtab_includes): Remove unnecessary forward declaration.
(die_needs_namespace): Add comment marking group of functions for
dwarf2 name computation.
Currently, "set listsize -1" is supposed to mean "unlimited" source
lines, but, alas, it doesn't actually work:
(gdb) set listsize -1
(gdb) show listsize
Number of source lines gdb will list by default is unlimited.
(gdb) list 1
(gdb) list 1
(gdb) list 1
(gdb) set listsize 10
(gdb) list 1
1 /* Main function for CLI gdb.
2 Copyright (C) 2002-2013 Free Software Foundation, Inc.
3
4 This file is part of GDB.
5
6 This program is free software; you can redistribute it and/or modify
7 it under the terms of the GNU General Public License as published by
8 the Free Software Foundation; either version 3 of the License, or
9 (at your option) any later version.
10
Before this patch:
http://sourceware.org/ml/gdb-patches/2012-08/msg00367.html
was applied, the "set listsize" command was a var_integer command, and
"unlimited" was set with 0. Internally, var_integer maps 0 to INT_MAX
case var_integer:
{
...
if (val == 0 && c->var_type == var_integer)
val = INT_MAX;
The change in that patch to zuinteger_unlimited command, meant that -1
is left as -1 in the command's control variable (lines_to_list), and
the code in source.c isn't expecting that -- it only expects positive
numbers.
I previously suggested fixing the code and keeping the new behavior,
but I found that "set listsize 0" is currently used in the wild, and
we do have a bunch of other commands where "0" means unlimited, so I'm
thinking that changing this command alone in isolation is not a good
idea.
So I now strongly prefer reverting back the behavior in 7.6 to the
same behavior the command has had since 2006 (0==unlimited, -1=error).
Before that, set listsize -1 would be accepted as unlimited as well.
After 7.6 is out, in mainline, we can get back to reconsidering
changing this command's behavior, if there's a real need for being
able to suppress output. For now, let's play it safe.
The "list line 1 with unlimited listsize" test in list.exp was
originally written years and years ago expecting 0 to mean "no
output", but GDB never actually worked that way, even when the tests
were written, so the tests had been xfailed then. This patch now
adjusts the test to the new behavior, so that the test actually
passes, and the xfail is removed.
gdb/
2013-03-28 Pedro Alves <palves@redhat.com>
PR gdb/15294
* source.c (_initialize_source): Change back "set listsize" to an
integer command.
gdb/testsuite/
2013-03-28 Pedro Alves <palves@redhat.com>
PR gdb/15294
* gdb.base/list.exp (set_listsize): Adjust to accept $arg == 0 to
mean unlimited instead of $arg < 0.
(test_listsize): Remove "listsize of 0 suppresses output" test.
Test that "set listsize 0" ends up with an unlimited listsize.
gdb/doc/
2013-03-28 Pedro Alves <palves@redhat.com>
PR gdb/15294
* gdb.texinfo (List) <set listsize>: Adjust to document that
listsize 0 means no limit, and remove mention of -1.
The previous patch actually wasn't the first time I had to update line
numbers in this file.
This avoids hard coding line numbers, hopefully making the next time a
little easier.
Tested on x86_64 Fedora 17.
gdb/testsuite/
2013-03-28 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (last_line): New global.
(last_line_re): New global.
(test_listsize, test_list_function, test_list_forward)
(test_repeat_list_command, test_list_range)
(test_list_filename_and_function): Use them.
* gdb.base/list0.c: Comment the last line of the file with "last
line".
The "set listsize -1" test in list.exp can't work correct anymore
nowadays, because the test's source files grew over time, and this
particular test was never updated.
This fixes it in the obvious way.
gdb/testsuite/
2013-03-28 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (test_listsize): Adjust test to make sure we
list the whole file.
Before the changes starting at
<http://sourceware.org/ml/gdb-patches/2012-08/msg00020.html>, the 'set
listsize' command only accepted "0" as special value, meaning
"unlimited". The testsuite actually tried "set listsize -1" and
expected that to mean unlimited too.
If you tried testing list.exp at the time of that patch above,
you'd get:
(gdb) PASS: gdb.base/list.exp: list line 10 with listsize 100
set listsize 0
(gdb) PASS: gdb.base/list.exp: setting listsize to 0 #6
show listsize
Number of source lines gdb will list by default is unlimited.
(gdb) PASS: gdb.base/list.exp: show listsize unlimited #6
list 1
1 #include "list0.h"
2
...
42 /* Not used for anything */
43 }
(gdb) PASS: gdb.base/list.exp: listsize of 0 suppresses output
set listsize -1
integer 4294967295 out of range
(gdb) PASS: gdb.base/list.exp: setting listsize to -1 #7
show listsize
Number of source lines gdb will list by default is unlimited.
(gdb) PASS: gdb.base/list.exp: show listsize unlimited #7
list 1
1 #include "list0.h"
Notice that "set listsize -1" actually failed with "integer 4294967295
out of range", but we issued a PASS anyway.
(and notice how the "listsize of 0 suppresses output" test passes bogusly too.)
This patch fixes that testsuite problem in the obvious way.
gdb/testsuite/
2013-03-28 Pedro Alves <palves@redhat.com>
* gdb.base/list.exp (set_listsize): Use gdb_test_no_output for
"set listsize".
The whole readline interface is signed, and works with the 0..INT_MAX
range.
We don't allow setting the size to UINT_MAX directly. The documented
user visible interface is "use 0 for unlimited". The UINT_MAX
representation is an implementation detail we could change, e.g., by
keeping a separate flag for "unlimited", which is actually what the
readline interface does (stifled vs non stifled). Generically
speaking, exposing this detail to clients of the interface may make
our lives complicated when we find the need to extend the range of
some command in the future, and it's better if users
(frontends/scripts) aren't relying on anything but what we tell them
to use for "unlimited". Making values other than 0 error out is the
way to prevent users from using those ranges inappropriately. Quite
related, note:
(gdb) set history size 0xffffffff
integer 4294967295 out of range
But,
(gdb) set history size 0xfffffffe
(gdb) show history size
The size of the command history is unlimited.
(gdb) set history size 0x100000000
integer 4294967296 out of range
If values over INT_MAX are accepted as unlimited, then there's no good
argument for only accepting [INT_MAX..UINT_MAX) as valid "unlimited"
magic numbers, while not accepting [UINT_MAX..inf).
Making the setting's control variable of different type (unsigned int)
of the rest of the related code (int) adds the need to recall that one
variable among all these is unsigned, and that one need to think about
whether these comparisons are signed or unsigned, along with the
promotion/conversion rules. Since this is an easy to forget detail,
this patch renames the variable to at least make it more obvious that
this variable is not one of GNU history's public int variables, which
are all signed. We don't actually need the only code that presently
is affected by this, though, the code that is computing the current
history's length. We can just use GNU history's history_length
instead:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Variable: int history_length
The number of entries currently stored in the history list.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/* Return the history entry which is logically at OFFSET in the history array.
OFFSET is relative to history_base. */
HIST_ENTRY *
history_get (offset)
int offset;
{
int local_index;
local_index = offset - history_base;
return (local_index >= history_length || local_index < 0 || the_history == 0)
? (HIST_ENTRY *)NULL
: the_history[local_index];
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At the time this code was added (gdb 4.13 ~1994), 'history_length' was
extern, but not documented in readline's GNU history documents, so I
guess it wasn't considered public then and the loop was the
workaround.
One of the warts of GDB choosing 0 to mean unlimited is that "set
history size 0" behaves differently from 'HISTSIZE=0 gdb'. The latter
leaves GDB with no history, while the former means "unlimited"...
$ HISTSIZE=0 ./gdb
...
(gdb) show history size
The size of the command history is 0.
We shouldn't really change what HISTSIZE=0 means, as bash, etc. also
handle 0 as real zero, and zero it's what really makes sense.
gdb/
2013-03-27 Pedro Alves <palves@redhat.com>
* top.c (history_size): Rename to ...
(history_size_setshow_var): ... this. Add comment.
(show_commands): Use readline's 'history_length' instead of
computing the history length by calling history_get in a loop.
(set_history_size_command): Error out for sizes over INT_MAX.
Restore previous history size on invalid size.
(init_history): If HISTSIZE is negative, leave the history size as
zero. Add comments.
(init_main): Adjust.
Hyphens are much more common than underscores in command names.
gdb/
2013-03-27 Pedro Alves <palves@redhat.com>
* coff-pe-read.c (_initialize_coff_pe_read): Rename "set debug
coff_pe_read" command to "set debug coff-pe-read".
The "set tcp connect-timeout" variable is unsigned:
/* Timeout period for connections, in seconds. */
static unsigned int tcp_retry_limit = 15;
And used like:
/* Check for timeout. */
if (*polls > tcp_retry_limit * POLL_INTERVAL)
{
errno = ETIMEDOUT;
return -1;
}
Which made me stop and look over why is it that 'polls' is signed.
What I found is there's really no reason.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* ser-tcp.c (wait_for_connect): Make 'polls' parameter unsigned.
(net_open): Make 'polls' local unsigned.
It makes no sense to talk about an "unlimited" address size in this
context.
(gdb) show remoteaddresssize
The maximum size of the address (in bits) in a memory packet is 0.
(gdb) set remoteaddresssize 0
(gdb) show remoteaddresssize
The maximum size of the address (in bits) in a memory packet is unlimited.
"set remoteaddresssize 0" mapping to UINT_MAX means you can't
force gdb through this path twice in the same GDB run:
static CORE_ADDR
remote_address_masked (CORE_ADDR addr)
{
unsigned int address_size = remote_address_size;
/* If "remoteaddresssize" was not set, default to target address size. */
if (!address_size)
address_size = gdbarch_addr_bit (target_gdbarch ());
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* remote.c (_initialize_remote): Make "set remoteaddresssize"
a zuinteger command instead of uinteger.
The "set record full insn-number-max" command is an uinteger command.
If the variable that holds the maximum count of logged instructions is
unsigned, it's better if the variable that holds the current number of
logged instructions is also unsigned. Looking over the code, there's
no case the variable could end up negative.
Then, tests like "if (record_full_insn_max_num)" are always true,
because being a uinteger command means that "set record full
insn-number-max 0" is actually mapped to UINT_MAX internally. IOW,
the command's variable is never 0. The checks might make some sense
if 0 wasn't mapped to UINT_MAX, and 0 meant unlimited, but, that's not
how things work.
Tested on x86_64 Fedora 17.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* record-full.c (record_full_insn_num): Make it unsigned.
(record_full_check_insn_num, record_full_message)
(record_full_registers_change, record_full_xfer_partial): Remove
record_full_insn_max_num check (it's always != 0).
(record_full_info, record_full_restore): Use %u as format string.
(): Use %u as format string.
(set_record_full_insn_max_num): Remove record_full_insn_max_num
check (it's always != 0).
It doesn't make sense to request an "unlimited" dcache. You want to
configure the cache with specific lines and length of lines.
It doesn't actually work anyway:
(gdb) set dcache line-size 0
Invalid dcache line size: 4294967295 (must be power of 2).
(gdb) set dcache size 0
(gdb) show dcache size
Number of dcache lines is unlimited.
(gdb) info dcache
Dcache 4294967295 lines of 64 bytes each.
No data cache available.
The code already has guards in place to forbid 0s:
static void
set_dcache_size (char *args, int from_tty,
struct cmd_list_element *c)
{
if (dcache_size == 0)
{
dcache_size = DCACHE_DEFAULT_SIZE;
error (_("Dcache size must be greater than 0."));
}
if (last_cache)
dcache_invalidate (last_cache);
}
static void
set_dcache_line_size (char *args, int from_tty,
struct cmd_list_element *c)
{
if (dcache_line_size < 2
|| (dcache_line_size & (dcache_line_size - 1)) != 0)
{
unsigned d = dcache_line_size;
dcache_line_size = DCACHE_DEFAULT_LINE_SIZE;
error (_("Invalid dcache line size: %u (must be power of 2)."), d);
}
if (last_cache)
dcache_invalidate (last_cache);
}
So we now get:
(gdb) set dcache line-size 0
Invalid dcache line size: 0 (must be power of 2).
(gdb) set dcache size 0
Dcache size must be greater than 0.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* dcache.c (_initialize_dcache): Make the "set dcache line-size"
and "set dcache size" commands zuinteger instead of uinteger.
Being a uinteger means you revert back to having GDB decide the
version. It makes no sense to have an "unlimited" version.
(gdb) show cris-version
The current CRIS version is 0.
(gdb) set cris-version 0
(gdb) show cris-version
The current CRIS version is unlimited.
(gdb)
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* cris-tdep.c (_initialize_cris_tdep): Make the "set cris-version"
command zuinteger instead of uinteger.
Being a uinteger means you can't disable debug output after enabling it...
(gdb) show debug coff_pe_read
Coff PE read debugging is 0.
(gdb) set debug coff_pe_read 0
(gdb) show debug coff_pe_read
Coff PE read debugging is unlimited.
(gdb)
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* coff-pe-read.c (_initialize_coff_pe_read): Make the command
zuinteger instead of uinteger.
When I tried running the btrace tests, I noticed something odd in the gdb.log file:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.x
Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c:1
1 /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace22343.c: No such file or directory.
^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) record btrace
Target does not support branch tracing.
(gdb) testcase ../../../src/gdb/testsuite/gdb.btrace/enable.exp completed in 0 seconds
I knew that the btrace tests on my machine weren't supposed to work,
but still, that error made me wonder if the test had something broken,
and waste a few minutes looking up where that is coming from.
The issue is that the btrace detection deletes the source file right
after compiling it, and before GDB has a chance to open it. It's
really harmless, but I'd rather spare others from going through the
same exercise.
We now get the regular:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.x
...
Breakpoint 1, main () at /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.btrace/btrace24210.c:1
1 int main(void) { return 0; }
...
gdb/testsuite/
2013-03-26 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (skip_btrace_tests): Delay deleting the source file
until after GDB has run.
While the commands are uinteger, the target interfaces are limited to
INT_MAX. Don't let the user request more than we can handle.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* record.c (record_insn_history_size_setshow_var)
(record_call_history_size_setshow_var): New globals.
(command_size_to_target_size): New function.
(cmd_record_insn_history, cmd_record_call_history): Use
command_size_to_target_size instead of cast.
(validate_history_size, set_record_insn_history_size)
(set_record_call_history_size): New functions.
(_initialize_record): Install set_record_insn_history_size and
set_record_call_history_size as "set" hooks of "set record
instruction-history-size" and "set record
function-call-history-size".
Ref: http://www.sourceware.org/ml/gdb-patches/2002-08/msg00486.html
We've long since imported a newer readline, no need to use the old
compatibility variable anymore.
Tested on x86_64 Fedora 17.
gdb/
2013-03-26 Pedro Alves <palves@redhat.com>
* top.c (gdb_rl_operate_and_get_next): Replace max_input_history
use with history_max_entries use. Remove FIXME note.
Reading symbols from /bin/true...(no debugging symbols found)...done.
(gdb) b _start
Function "_start" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_start) pending.
(gdb) r
Starting program: /bin/true
Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) rec b
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /bin/true
Breakpoint 1, 0x00000039a0400af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) rec b
gdb/record-btrace.c:154: internal-error: record_btrace_open:
Assertion `record_btrace_thread_observer == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
gdb/
* record-btrace.c (record_btrace_close): Call
record_btrace_auto_disable.
testsuite/
* gdb.btrace/enable.exp: Add regression test.
* c-exp.y (exp): Add new productions for destructors after '.' and
'->'.
(write_destructor_name): New function.
gdb/testsuite
* gdb.cp/m-static.exp: Add destructor-printing tests.
windows-nat.c (windows_get_absolute_argv0): New function.
windows-nat.h: Add its prototype.
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.
Include windows-nat.h.
* exceptions.h (enum errors): New entry TARGET_CLOSE_ERROR.
* remote.c (trace_error): Remove the special handling of '2'.
(readchar) <SERIAL_EOF>
(readchar) <SERIAL_ERROR>
(getpkt_or_notif_sane_1): Use TARGET_CLOSE_ERROR for them.
(remote_get_trace_status): Call throw_exception if EX is
TARGET_CLOSE_ERROR.
* utils.c (perror_with_name): Rename to ...
(throw_perror_with_name): ... here. New parameter errcode, describe it
in the function comment.
(perror_with_name): New function wrapper.
* utils.h (enum errors): New stub declaration.
(throw_perror_with_name): New declaration.
gdb/testsuite/
* gdb.server/server-kill.c: New file.
* gdb.server/server-kill.exp: New file.
The range validation added by
http://sourceware.org/ml/gdb-patches/2013-03/msg00767.html
Changes things to allow setting the command to INT_MAX or UINT_MAX
directly, with signed and unsigned commands respectively. However,
that went a little bit too far, as in the cases of var_integer and
var_uinteger, those values are actually implementation detail. It's
better to not expose them in the interface, and have users assume
those values mean "unlimited" too, so to be safer to expand the range
of the commands in the future if we want to. Yes, it's pedantic, and
it's not likely users actually will do this, but MI frontends and
Python scripts might.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
Mark Kettenis <kettenis@gnu.org>
* cli/cli-setshow.c (do_set_command) <var_uinteger>:
Don't let the user set the value to UINT_MAX directly.
<var_integer>: Don't let the user set the value to INT_MAX
directly.
The range validation added by
http://sourceware.org/ml/gdb-patches/2013-03/msg00767.html
Changes things to allow setting the command to INT_MAX or UINT_MAX
directly, with signed and unsigned commands respectively. However,
that went a little bit too far, as in the cases of var_integer and
var_uinteger, those values are actually implementation detail. It's
better to not expose them in the interface, and have users assume
those values mean "unlimited" too, so to be safer to expand the range
of the commands in the future if we want to. Yes, it's pedantic, and
it's not likely users actually will do this, but MI frontends and
Python scripts might.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
Mark Kettenis <kettenis@gnu.org>
* cli/cli-setshow.c (do_set_command) <var_uinteger>:
Don't let the user set the value to UINT_MAX directly.
<var_integer>: Don't let the user set the value to INT_MAX
directly.
Oleg Nesterov told me that the Linux kernel copies the parent's ptrace
options to fork/clone children, so there's no need for GDB to do that
manually.
I was actually a bit surprised, since I thought the ptracer had to
always set the ptrace options itself, and GDB is indeed calling
PTRACE_SETOPTIONS for each new fork child, if it'll stay attached.
Looking at the history of that code, I found that is was actually I
who added that set-ptrace-options-in-children bit, back in
http://sourceware.org/ml/gdb-patches/2009-05/msg00656.html. But,
honestly, I don't recall why I needed that. I think I may have just
blindly believed it was necessary.
I then looked back at the history of all the PTRACE_SETOPTIONS code we
have, and found that gdb never did copy the ptrace options before my
patch. But, when gdbserver learnt to use PTRACE_EVENT_CLONE, at
http://sourceware.org/ml/gdb-patches/2007-10/msg00547.html, it was
made to do 'ptrace (PTRACE_SETOPTIONS, new_pid, 0,
PTRACE_O_TRACECLONE)' for all new clones. Hmmm. But, GDB itself
never did that, so it can't really ever have been necessary, I
believe, otherwise GDB should have been doing it too.
(GDBserver doesn't support following forks, and so naturally doesn't
do any PTRACE_SETOPTIONS on fork children.)
So this patch removes the -I believe- unnecessary ptrace syscalls.
Tested on x86_64 Fedora 17, native/gdbserver, and on x86_64 RHEL5
native/gdbserver (Linux 2.6.18, I think a ptrace-on-utrace kernel).
No regressions.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_child_follow_fork): Don't call
linux_enable_event_reporting.
(linux_handle_extended_wait): Don't call
linux_enable_event_reporting.
gdb/gdbserver/
2013-03-22 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Don't call
linux_enable_event_reporting.
$ make WERROR_CFLAGS="-Wpointer-sign -Werror" hppa-hpux-tdep.o -k 2>&1 1>/dev/null
../../src/gdb/hppa-hpux-tdep.c: In function ‘hppa_hpux_push_dummy_code’:
../../src/gdb/hppa-hpux-tdep.c:1225:7: error: pointer targets in passing argument 2 of ‘write_memory’ differ in signedness [-Werror=pointer-sign]
In file included from ../../src/gdb/hppa-hpux-tdep.c:22:0:
../../src/gdb/gdbcore.h:85:13: note: expected ‘const gdb_byte *’ but argument is of type ‘char *’
../../src/gdb/hppa-hpux-tdep.c:1251:7: error: pointer targets in passing argument 2 of ‘write_memory’ differ in signedness [-Werror=pointer-sign]
In file included from ../../src/gdb/hppa-hpux-tdep.c:22:0:
../../src/gdb/gdbcore.h:85:13: note: expected ‘const gdb_byte *’ but argument is of type ‘char *’
../../src/gdb/hppa-hpux-tdep.c: In function ‘hppa_hpux_supply_save_state’:
../../src/gdb/hppa-hpux-tdep.c:1354:9: error: pointer targets in passing argument 1 of ‘extract_unsigned_integer’ differ in signedness [-Werror=pointer-sign]
In file included from ../../src/gdb/hppa-hpux-tdep.c:20:0:
../../src/gdb/defs.h:675:22: note: expected ‘const gdb_byte *’ but argument is of type ‘const char *’
Casting to gdb_byte would fix it, however, writing an
unsigned int array like this
static unsigned int hppa64_tramp[] = {
0xeac0f000, /* bve,l (r22),%r2 */
0x0fdf12d1, /* std r31,-8(,sp) */
0x0fd110c2, /* ldd -8(,sp),rp */
0xe840d002, /* bve,n (rp) */
0x08000240 /* nop */
...
directly to target memory assumes the host endianness is the same as
the target's. hppa is big endian, so I believe this patch should be
correct -- it defines the array as a gdb_byte array. It uses a macro
to make the insn bytes a little more readable. I thought of using
write_memory_unsigned_integer once for each element of the unsigned
int array, but this way keeps issuing a single target memory write /
roundtrip for the whole trampoline.
gdb/
2013-03-22 Pedro Alves <palves@redhat.com>
* hppa-hpux-tdep.c (hppa_hpux_push_dummy_code): Define INSN macro,
use it to rewrite the trampoline buffers with type gdb_byte[], and
undefine the macro. Remove char* cast.
Just the usual missing $gdb_prompt match:
(gdb) tstatus
No trace has been run on the target.
Collected 0 trace frames.
Trace buffer has 5242880 bytes of 5242880 bytes free (0% full).
Trace will stop if GDB disconnects.
Not looking at any trace frame.
PASS: gdb.trace/trace-buffer-size.exp: get default buffer size
(gdb) set trace-buffer-size 4
(gdb) FAIL: gdb.trace/trace-buffer-size.exp: set trace buffer size 1
This fixes it.
gdb/testsuite/
2013-03-21 Pedro Alves <palves@redhat.com>
* gdb.trace/trace-buffer-size.exp (get default buffer size):
Expect $gdb_prompt in gdb_test_multiple.
* NEWS: Add entry.
* event-top.c: #include "maint.h".
* main.c: #include "maint.h".
* maint.c: #include <sys/time.h>, <time.h>, block.h, top.h,
timeval-utils.h, maint.h, cli/cli-setshow.h.
(per_command_time, per_command_space): New static globals.
(per_command_symtab): New static global.
(per_command_setlist, per_command_showlist): New static globals.
(struct cmd_stats): Move here from utils.c.
(set_per_command_time): Renamed from set_display_time in utils.c
and moved here. All callers updated.
(set_per_command_space): Renamed from set_display_space in utils.c
and moved here. All callers updated.
(count_symtabs_and_blocks): New function.
(report_command_stats): Moved here from utils.c. Add support for
printing symtab stats. Only print data if enabled before command
executed.
(make_command_stats_cleanup): Ditto.
(sert_per_command_cmd, show_per_command_cmd): New functions.
(_initialize_maint_cmds): Add new commands
mt set per-command {space,time,symtab} {on,off}.
* maint.h: New file.
* top.c: #include "maint.h".
* utils.c (reset_prompt_for_continue_wait_time): New function.
(get_prompt_for_continue_wait_time): New function.
* utils.h (reset_prompt_for_continue_wait_time): Declare
(get_prompt_for_continue_wait_time): Declare.
(make_command_stats_cleanup): Moved to maint.h.
(set_display_time, set_display_space): Moved to maint.h and renamed
to set_per_command_time, set_per_command_space.
* cli/cli-setshow.c (parse_cli_boolean_value): Renamed from
parse_binary_operation and made non-static. Don't call error,
just return an error marker. All callers updated.
* cli/cli-setshow.h (parse_cli_boolean_value): Declare.
doc/
* gdb.texinfo (Maintenance Commands): Add docs for
"mt set per-command {space,time,symtab} {on,off}".
testsuite/
* gdb.base/maint.exp: Update tests for per-command stats.
* c-exp.y (yylex): Rewrite to push all tokens onto the FIFO.
Handle FILENAME token.
gdb/testsuite
* gdb.cp/cpexprs.exp: Add test for FILENAME:: case.
* gdb.cp/misc.exp: Add test for FILENAME:: case.
This is a regression from 7.5, introduced/exposed by:
http://sourceware.org/ml/gdb-patches/2012-07/msg00259.html
There are a series of issues with this code.
It does:
unsigned int val = parse_and_eval_long (arg);
^^^^^^^^^^^^
(unsigned, usually 32-bit) while parse_and_eval_long returns a LONGEST
(usually 64-bit), so we lose precision without noticing:
(gdb) set remote hardware-watchpoint-limit 0x100000000
(gdb) show remote hardware-watchpoint-limit 0x100000000
The maximum number of target hardware watchpoints is 0.
While at it, print the invalid number with plongest, so the user sees
what GDB thought the number was:
(gdb) set remote hardware-watchpoint-limit 0x100000000
integer 4294967296 out of range
So with "set remote hardware-watchpoint-limit -1", val ends converted
to 0xffffffff, which then fails the
else if (val >= INT_MAX)
error (_("integer %u out of range"), val);
test.
Looking at that INT_MAX check, we forbid INT_MAX itself, but we
shouldn't, as that does fit in 'int' -- we want to forbid values
_greater_ than INT_MAX (and less than INT_MIN, while at it):
(gdb) set remote hardware-watchpoint-limit 2147483647
integer 2147483647 out of range
The same problem is in the new var_zuinteger_unlimited code, which
also uses "int" for variable.
Also, when printing a 'signed int', we should use %d, not %u.
This adds a couple regression tests. Not completely thorough in checking
all kinds of invalid input; I'm saving more exaustive testing around
zXXinteger commands for something like new test-assisting commands
like "maint test cmd-zinteger -1", where testing would focus on the
command types, and thus be independent of particular user commands of
particular GDB features.
Tested on x86_64 Fedora 17.
gdb/
2013-03-20 Pedro Alves <palves@redhat.com>
PR gdb/15289
* cli/cli-setshow.c (do_set_command)
<var_uinteger, var_zuinteger>: Use LONGEST for variable holding
the result of parsing the command argument. Throw error if the
value is greater than UINT_MAX. Print the invalid value with
plongest.
<var_integer, var_zinteger>: Use LONGEST for variable holding the
result of parsing the command argument. Throw error if the value
is greater than INT_MAX, not greater or equal. Also throw error
if the value is less than INT_MIN. Print the invalid value with
plongest.
<var_zuinteger_unlimited>: Throw error if the value is greater
than INT_MAX, not greater or equal.
(do_show_command) <var_integer, var_zinteger,
var_zuinteger_unlimited>: Use %d for printing int, not %u.
gdb/testsuite/
2013-03-20 Pedro Alves <palves@redhat.com>
PR gdb/15289
* gdb.base/remote.exp: Test
"set remote hardware-watchpoint-limit -1",
"set remote hardware-breakpoint-limit -1",
"set remote hardware-watchpoint-limit 2147483647" and
"set remote hardware-breakpoint-limit 2147483647".
Hui Zhu
Joel Brobecker
gdbadmin
Jan Kratochvil
Pedro Alves
Markus Metzger
Tom Tromey
Aleksandar Ristovski
Yao Qi
Eli Zaretskii
Doug Evans
Sandra Loosemore
Jiong Wang
Tiago Daitx
Pierre Muller
Keith Seitz