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.
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.
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.
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".
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.
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.
* 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.
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".
Make sure we don't fallback to printing the initial value of a
non-const variable in the executable.
Also make sure we can do 'disassemble', as another test that GDB is
able to read read-only parts from the executable (the existing test of
printing constglob also covers that case).
gdb/testsuite/
2013-03-20 Pedro Alves <palves@redhat.com>
Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.c: Add comments.
(nonconstglob): New global.
* gdb.trace/tfile.exp: Add comments. Test printing a non-const
global that is not covered by the trace frame. Test
disassembling.
Subject: [PATCH] Fix for PR c++/15203 and PR c++/15210
Date: Sat, 09 Mar 2013 02:50:49 -0300 (5 days, 4 hours, 57 minutes ago)
Message-ID: <m3a9qdnmti.fsf@redhat.com>
Hi,
This bug was reported internally at our Bugzilla, along with a proposed
fix. After talking to Keith about it, he investigated and came up with
another patch needed to really fix the issue on CVS HEAD.
The first part of the fix is the patch to cp-namespace.c. It handles
the case when we are accessing a static variable inside a function
(inside a class) by the full linespec (is it right, Keith?). E.g.:
class foo
{
public:
int bar()
{
static int var = 0;
}
};
And then, printing the value of `var':
(gdb) print 'foo::bar()::var'
GDB would fall in an internal_error:
gdb/cp-namespace.c:816: internal-error: cp_lookup_nested_symbol called on a non-aggregate type.
This is because `cp_lookup_nested_symbol' is not handling the case when
TYPE_CODE is either _FUNC or _METHOD. This patch fixes it by returning
NULL in this case.
The second part of the fix is the patch to elfread.c. It is needed
because the BSF_GNU_UNIQUE flag was added to some symbols in
<http://sourceware.org/ml/binutils/2009-06/msg00016.html>. Because of
that, (still) the command:
(gdb) print 'foo::bar()::var'
where `var' is a static variable returns:
"No symbol "foo::bar()::var" in current context."
So with the second patch applied the command finally DTRT:
(gdb) print 'foo::bar()::var'
$1 = 0
This may not be the ideal solution, according to Keith it would be good
to implement productions on c-exp.y in order to recognize
CLASS::FUNCTION::VARIABLE, but it is a solution which works with what we
have today.
I regtested it in Fedora 17 x86_64 with -m64 and -m32, including
gdbserver, without regressions.
gdb/:
2013-03-14 Keith Seitz <keiths@redhat.com>
Alan Matsuoka <alanm@redhat.com>
PR c++/15203
PR c++/15210
* cp-namespace.c (cp_lookup_nested_symbol): Handle TYPE_CODE_FUNC and
TYPE_CODE_METHOD.
* elfread.c (elf_symtab_read): Handle BSF_GNU_UNIQUE for certain
symbols.
gdb/testsuite/:
2013-03-14 Sergio Durigan Junior <sergiodj@redhat.com>
PR c++/15203
PR c++/15210
* gdb.cp/m-static.cc (keepalive_int): New function.
(gnu_obj_1::method): New variable `sintvar', call `keepalive_int'.
* gdb.cp/m-static.exp: New test for `sintvar'.
* gdb.trace/tstatus.exp (run_trace_experiment): Save the output
of 'tstatus' into tstatus_output.
(top level): Save the trace data to tfile. Read trace file in
tfile target. Check the trace status.
the last matched 'V' blcok in trace frame.
gdb/gdbserver:
* tracepoint.c (traceframe_read_tsv): Look for the last matched
'V' block in trace frame.
gdb/testsuite:
* gdb.trace/tsv.exp (check_tsv): New.
(top level): Save a tfile on current trace session. Call
check_tsv on live target. Load the tfile with target tfile
and call check_tsv again.
GDB treats the identifiers 'if', 'thread', and 'task' unconditionally
as expression delimiters in Ada mode, which is correct for 'if' and 'task',
but wrong for 'thread' in cases such as
print thread
Borrowing from c-exp.y, we observe that 'thread' must be followed by
numerals, whereas identifiers never are and treat them as delimiters
only in that case.
In the process, the current also refactors and incidentally fixes the
code for rewinding the input to before the delimiting tokens. For
example, the code
watch expr if i > 2
fails because the input is only rewound to just before the 'i',
leaving the 'if' as part of the expression (and thus making the
rest look like trailing junk rather than a conditional clause).
gdb/ChangeLog:
* ada-lex.l (rules): Only recognize 'thread' as a
delimiter when followed by numerals, as for c-exp.y.
Use new rewind_to_char function to rewind the input for
expression-delimiting tokens.
(rewind_to_char): New function.
gdb/testsuite/ChangeLog:
* gdb.ada/expr_delims.exp: New file.
* gdb.ada/expr_delims/foo.adb: New file.
* gdb.ada/expr_delims/pck.ads: New file.
* gdb.ada/expr_delims/pck.adb: New file.
Fix entry-values if the callee called a noreturn function.
* dwarf2-frame-tailcall.c (dwarf2_tailcall_sniffer_first): Use
get_frame_address_in_block. Add new comment.
gdb/testsuite/
Fix entry-values if the callee called a noreturn function.
* gdb.arch/amd64-tailcall-noret.S: New file.
* gdb.arch/amd64-tailcall-noret.c: New file.
* gdb.arch/amd64-tailcall-noret.exp: New file.
Fix entry-values in C++ across CUs.
* dwarf2loc.c (call_site_to_target_addr) <FIELD_LOC_KIND_PHYSNAME>: Use
lookup_minimal_symbol. Add a comment.
* dwarf2read.c
(read_call_site_scope) <is_ref_attr> <die_is_declaration>: Prefer
DW_AT_linkage_name.
gdb/testsuite/
Fix entry-values in C++ across CUs.
* gdb.arch/amd64-tailcall-cxx.exp: New file.
* gdb.arch/amd64-tailcall-cxx1.S: New file.
* gdb.arch/amd64-tailcall-cxx1.cc: New file.
* gdb.arch/amd64-tailcall-cxx2.S: New file.
* gdb.arch/amd64-tailcall-cxx2.cc: New file.
Hafiz Abid Qadeer <abidh@codesourcery.com>
gdb/
* NEWS: Mention set and show trace-buffer-size commands.
Mention new packet.
* target.h (struct target_ops): New method
to_set_trace_buffer_size.
(target_set_trace_buffer_size): New macro.
* target.c (update_current_target): Set up new method.
* tracepoint.c (trace_buffer_size): New global.
(start_tracing): Send it to the target.
(set_trace_buffer_size): New function.
(_initialize_tracepoint): Add new setshow for trace-buffer-size.
* remote.c (remote_set_trace_buffer_size): New function.
(_initialize_remote): Use it.
(QTBuffer:size) New remote command.
(PACKET_QTBuffer_size): New enum.
(remote_protocol_features): Add an entry for
PACKET_QTBuffer_size.
gdb/gdbserver/
* tracepoint.c (trace_buffer_size): New global.
(DEFAULT_TRACE_BUFFER_SIZE): New define.
(init_trace_buffer): Change to one-argument function. Allocate
trace buffer memory.
(handle_tracepoint_general_set): Call cmd_bigqtbuffer_size to
handle QTBuffer:size packet.
(cmd_bigqtbuffer_size): New function.
(initialize_tracepoint): Call init_trace_buffer with
DEFAULT_TRACE_BUFFER_SIZE.
* server.c (handle_query): Add QTBuffer:size in the
supported packets.
gdb/doc/
* gdb.texinfo (Starting and Stopping Trace Experiments): Document
trace-buffer-size set and show commands.
(Tracepoint Packets): Document QTBuffer:size.
(General Query Packets): Document QTBuffer:size.
gdb/testsuite/
* gdb.trace/trace-buffer-size.exp: New file.
* gdb.trace/trace-buffer-size.c: New file.
The current tstatus.exp tests shows PASSes if either the target
support or not the optional tstatus bits:
PASS: gdb.trace/tstatus.exp: tstatus does not report trace stop reason
PASS: gdb.trace/tstatus.exp: tstatus reports trace stop reason
The former (and any other similar case) should be UNSUPPORTED rather
than PASS. That'd make it much easier to spot actually problems with
the test (e.g., the one Yao's previous patch addressed), along with
regressions and progressions.
The "not supported" paths in tstatus.exp explicitly check for output
you'd get if the feature wasn't supported, so real unexpected failures
will still be caught as FAILs.
So now e.g., where we wanted to check if tstatus reports the trace
stop reason, and if the target does support it, we get
PASS: tstatus reports trace stop reason
if the target actually reports what we'd expect if the trace stop
reason isn't supported, we get:
UNSUPPORTED: tstatus reports trace stop reason
and if the target reports something else unexpected, we get:
FAIL: tstatus reports trace stop reason
That has the added bonus that the test string is always the same and
only the test results change (PASS/FAIL/UNSUPPORTED), which makes it
easier for testers see regressions, compared to the previous:
-PASS: gdb.trace/tstatus.exp: tstatus reports trace stop reason
+PASS: gdb.trace/tstatus.exp: tstatus does not report trace stop reason
which clearly easily goes by unnoticed, as evidenced by the existing
problem Yao's previous patch addressed.
Tested on x86_64 Fedora 17.
gdb/testsuite/
2013-03-06 Pedro Alves <palves@redhat.com>
* gdb.trace/tstatus.exp (run_trace_experiment): When the target
doesn't support the tested optional feature, call "unsupported"
with the same test message as the "pass" case, instead of calling
"pass" with a different message. Use the same text for the "fail"
cases too.
* gdb.trace/tstatus.exp: Remove the invocation of
gdb_load_shlibs, gdb_compile, clean_restart and runto_main.
(test_tracepoints): Don't set fast tracepoint.
(top level): Don't check agent library is loaded or not.
* linespec.c (struct linespec_canonical_name): New.
(struct linespec_state): Change canonical_names type to it.
(add_sal_to_sals): Change variable canonical_name to canonical. Change
xrealloc element size. Initialize the different CANONICAL fields.
(canonical_to_fullform): New.
(filter_results): Use it. Add variables canonical, fullform and
cleanup.
(struct decode_line_2_item, decode_line_2_compare_items): New.
(decode_line_2): Remove variables iter and item_names, add variables
items and items_count. Modify the code for these new variables.
gdb/testsuite/
* gdb.linespec/base/one/thefile.cc (twodup): New.
(m): Call it.
* gdb.linespec/base/two/thefile.cc (dupname): New.
(n): Call it.
* gdb.linespec/break-ask.exp: New file.
* gdb.linespec/lspec.cc (body_elsewhere): New comment marker.
* gdb.trace/report.exp: Move some code to ...
(use_collected_data): New.
(top level): Call use_collected_data once on the live target.
Save at file of the current trace session, load it with target
tfile, and call use_collected_data again.
