Recently I fixed a bug that caused a DW_OP_implicit_pointer with non-zero
offset into a DW_OP_implicit_value to be handled incorrectly on big-endian
targets. GDB ignored the offset and copied the wrong bytes:
https://sourceware.org/ml/gdb-patches/2017-01/msg00251.html
But there is still a similar issue when a DW_OP_implicit_pointer points
into a DW_OP_stack_value instead; and again, the offset is ignored. There
is an important difference, though: While implicit values are treated like
blocks of data and anchored at the lowest-addressed byte, stack values
traditionally contain integer numbers and are anchored at the *least
significant* byte. Also, stack values do not come in varying sizes, but
are cut down appropriately when used. Thus, on big-endian targets the
scenario looks like this (higher addresses shown right):
|<- - - - - Stack value - - - - - - ->|
| |
|<- original object ->|
|
| offset ->|####|
^^^^
de-referenced
implicit pointer
(Note how the original object's size influences the position of the
de-referenced implicit pointer within the stack value. This is not the
case for little-endian targets, where the original object starts at offset
zero within the stack value.)
This patch implements the logic indicated in the above diagram and adds an
appropriate test case. A new function dwarf2_fetch_die_type_sect_off is
added; it is used for retrieving the original object's type, so its size
can be determined. That type is passed to dwarf2_evaluate_loc_desc_full
via a new parameter.
gdb/ChangeLog:
* dwarf2loc.c (indirect_synthetic_pointer): Get data type of
pointed-to DIE and pass it to dwarf2_evaluate_loc_desc_full.
(dwarf2_evaluate_loc_desc_full): New parameter subobj_type; rename
byte_offset to subobj_byte_offset. Fix the handling of
DWARF_VALUE_STACK on big-endian targets when coming via an
implicit pointer.
(dwarf2_evaluate_loc_desc): Adjust call to
dwarf2_evaluate_loc_desc_full.
* dwarf2loc.h (dwarf2_fetch_die_type_sect_off): New declaration.
* dwarf2read.c (dwarf2_fetch_die_type_sect_off): New function.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp: Add support for DW_OP_implicit_pointer.
* gdb.dwarf2/nonvar-access.exp: Add test for stack value location
and implicit pointer into such a location.
This patch keeps the Scheme side of lazy string handling in sync
with the python size, bringing over fixes for
PRs python/17728, python/18439, python/18779.
gdb/ChangeLog:
* guile/scm-lazy-string.c (lazy_string_smob): Clarify use of LENGTH
member. Change type of TYPE member to SCM. All uses updated.
(lsscm_make_lazy_string_smob): Add assert.
(lsscm_make_lazy_string): Flag bad length values.
(lsscm_elt_type): New function.
(gdbscm_lazy_string_to_value): Rewrite to use
lsscm_safe_lazy_string_to_value.
(lsscm_safe_lazy_string_to_value): Fix handling of TYPE_CODE_PTR.
* guile/scm-value.c (gdbscm_value_to_lazy_string): Flag bad length
values. Fix TYPE_CODE_PTR. Handle TYPE_CODE_ARRAY. Handle typedefs
in incoming type.
* guile/guile-internal.h (tyscm_scm_to_type): Declare.
* guile/scm-type.c (tyscm_scm_to_type): New function.
gdb/testsuite/ChangeLog:
* gdb.guile/scm-value.c (main) Delete locals sptr, sn.
* gdb.guile/scm-lazy-string.c: New file.
* gdb.guile/scm-value.exp: Move lazy string tests to ...
* gdb.guile/scm-lazy-string.exp: ... here, new file. Add more tests
for pointer, array, typedef lazy strings.
gdb/ChangeLog:
PR python/17728, python/18439, python/18779
* python/py-lazy-string.c (lazy_string_object): Clarify use of LENGTH
member. Change type of TYPE member to PyObject *. All uses updated.
(stpy_convert_to_value): Fix handling of TYPE_CODE_PTR.
(gdbpy_create_lazy_string_object): Flag bad length values.
Handle TYPE_CODE_ARRAY with possibly different user-provided length.
Handle typedefs in incoming type.
(stpy_lazy_string_elt_type): New function.
(gdbpy_extract_lazy_string): Call it.
* python/py-value.c (valpy_lazy_string): Flag bad length values.
Fix handling of TYPE_CODE_PTR. Handle TYPE_CODE_ARRAY. Handle
typedefs in incoming type.
gdb/testsuite/ChangeLog:
PR python/17728, python/18439, python/18779
* gdb.python/py-value.c (main) Delete locals sptr, sn.
* gdb.python/py-lazy-string.c (pointer): New typedef.
(main): New locals ptr, array, typedef_ptr.
* gdb.python/py-value.exp: Move lazy string tests to ...
* gdb.python/py-lazy-string.exp: ... here. Add more tests for pointer,
array, typedef lazy strings.
The expectation in gdb.cp/m-static.exp for the ptype of
single_constructor is to get in the result of destructor with the
following prototype: ~single_constructor(int).
Yet, m-static.cc declares the destructor as ~single_constructor(). This
commit fixes the expectation.
2017-03-16 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.cp/m-static.exp: Fix expectation for prototype of
test5.single_constructor and single_constructor::single_constructor.
An optional parameter TEST has been added to get_hexadecimal_valueof in commit:
https://sourceware.org/ml/gdb-patches/2016-06/msg00469.html
This patch adds a similar optional parameter to other related methods that
retrieve expression values: get_valueof, get_integer_valueof and get_sizeof.
Thus tests that evaluate same expression multiple times can provide custom
test names, ensuring that test names will be unique.
gdb/testsuite/ChangeLog:
2017-03-14 Anton Kolesov <anton.kolesov@synopsys.com>
* lib/gdb.exp (get_valueof, get_integer_valueof, get_sizeof):
Add optional 'test' parameter.
I noticed that backslash_in_multi_line_command_test in
gdb.base/commands.exp failed on our RHEL6 servers. I traced it to the
old version of DejaGnu (1.4.4). I have found that instead of receiving
the expected:
"print \\\nargc\n"
gdb received:
"print argc\n"
thus breaking the test and its purpose. Versionof DejaGnu < 1.5 mess
up sending "\\\n", it somehow gets replaced with a space. I found that
the following commit in DejaGnu fixed the issue:
http://git.savannah.gnu.org/cgit/dejagnu.git/commit/lib/remote.exp?id=3f39294f5cd6802858838d3bcc0ccce847ae17f2
Even though the commit is almost 10 years old, the following release of
DejaGnu was only in 2013, which is why we still have systems with the
old code.
If the DejaGnu version is < 1.5, we just skip the test.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
Skip for versions of DejaGnu < 1.5.
The next patch will require checking the DejaGnu version. There is
already a test that does this,
gdb.threads/attach-many-short-lived-threads.exp. This patch introduces
a new procedure, dejagnu_version, and makes that test use it.
The version number is "right-padded" with zeroes, to make sure that we
always return a triplet (major, minor, patch).
The procedure does not consider the DejaGnu versions from git. For
example, if you used DejaGnu from its current master branch, the version
would be "1.6.1-git", meaning that 1.6.1 will be the next release. I
figured we'll cross that bridge when (and if) we get there.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (dejagnu_version): New proc.
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
Use dejagnu_version.
For a long time now, c++/8218 has noted that GDB is printing argument types
for destructors:
(gdb) ptype A
type = class A {
public:
~A(int);
}
This happens because cp_type_print_method_args doesn't ignore artificial
arguments. [It ignores the first `this' pointer because it simply skips
the first argument for any non-static function.]
This patch fixes this:
(gdb) ptype A
type = class A {
public:
~A();
}
I've adjusted gdb.cp/templates.exp to account for this and added a new
passing regexp.
gdb/ChangeLog
PR c++/8218
* c-typeprint.c (cp_type_print_method_args): Skip artificial arguments.
gdb/testsuite/ChangeLog
PR c++/8128
* gdb.cp/templates.exp (test_ptype_of_templates): Remove argument
type from destructor regexps.
Add a branch which actually passes the test.
Adjust "ptype t5i" test names.
Currently diffing testrun results shows:
-PASS: gdb.base/step-over-exit.exp: break *0x7ffff77e18c6 if main == 0
+PASS: gdb.base/step-over-exit.exp: break *0x2aaaab0988c6 if main == 0
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/step-over-exit.exp: Add explicit test message.
If you do "interrupt -a" just while some thread is stepping over a
breakpoint, gdb trips on an internal error.
The test added by this patch manages to trigger this consistently by
spawning a few threads that are constantly tripping on a conditional
breakpoint whose condition always evaluates to false. With current
gdb, you get:
~~~
interrupt -a
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=on: iter=0: interrupt -a (GDB internal error)
[...]
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=off: iter=0: wait for stops (GDB internal error)
~~~
The assertion triggers because we're processing a stop for a thread
that had already stopped before and thus had already its inline-frame
state filled in.
Calling handle_inferior_event_1 directly within a
"thread_stop_requested" observer is something that I've wanted to get
rid of before, for being fragile. Nowadays, infrun is aware of
threads with pending events, so we can use that instead, and let the
normal fetch_inferior_event -> handle_inferior_event code path handle
the forced stop.
The change to finish_step_over is necessary because sometimes a thread
that was told to PTRACE_SINGLESTEP reports back a SIGSTOP instead of a
SIGTRAP (i.e., we tell it to single-step, and then interrupt it quick
enough that on the kernel side the thread dequeues the SIGTOP before
ever having had a chance of executing the instruction to be stepped).
SIGSTOP gets translated to a GDB_SIGNAL_0. And then finish_step_over
would miss calling clear_step_over_info, and thus miss restarting the
other threads (which in this case of threads with pending events,
means setting their "resumed" flag, so their pending events can be
consumed).
And now that we always restart threads in finish_step_over, we no
longer need to do that in handle_signal_stop.
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* infrun.c (start_step_over, do_target_resume, resume)
(restart_threads): Assert we're not resuming a thread that is
meant to be stopped.
(infrun_thread_stop_requested_callback): Delete.
(infrun_thread_stop_requested): If the thread is internally
stopped, queue a pending stop event and clear the thread's
inline-frame state.
(handle_stop_requested): New function.
(handle_syscall_event, handle_inferior_event_1): Use
handle_stop_requested.
(handle_stop_requested): New function.
(handle_signal_stop): Set the thread's stop_signal here instead of
at caller.
(finish_step_over): Clear step over info unconditionally.
(handle_signal_stop): If the user had interrupted the event
thread, consider the stop a random signal.
(handle_signal_stop) <signal arrived while stepping over
breakpoint>: Don't restart threads here.
(stop_waiting): Don't clear step-over info here.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* gdb.threads/interrupt-while-step-over.c: New file.
* gdb.threads/interrupt-while-step-over.exp: New file.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/amd64-entry-value-param-dwarf5.exp: Use with_test_prefix.
* gdb.arch/amd64-entry-value-param.exp: Use with_test_prefix.
Currently I get:
(gdb) print have_pkru()
$1 = 0
(gdb) FAIL: gdb.arch/i386-pkru.exp: probe PKRU support
UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not support protection key feature.
Probing suceeded, so that should be a PASS -> UNSUPPORTED.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-pkru.exp (probe PKRU support): Handle detecting
PKRU as not supported as a PASS.
Avoid putting unstable path names in test messages, in order to avoid
spurious testrun result diffs like:
[....]
-PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build1/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
+PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build2/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
[....]
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/break-fun-addr.exp: Use $testfile1/$testfile2 for test
prefix instead of $binfile1/$binfile2.
* gdb.btrace/gcore.exp: Use "core" instead of unstable path name
in test message.
* gdb.python/py-completion.exp: Use "load python file" as test
messages instead of unstable path names.
With commit 3b12939dfc ("Replace the sync_execution global with a
new enum prompt_state tristate"), GDB started aborting if you try
splitting an input line with a continuation char (backslash) while in
a multi-line command:
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>print \
(gdb) 1 # note "(gdb)" incorrectly printed here.
>end
readline: readline_callback_read_char() called with no handler!
$
That abort is actually a symptom of an old problem introduced when
gdb_readline_wrapper was rewritten to use asynchronous readline, back
in 2007. Note how the "(gdb)" prompt is printed above in the "(gdb)
1" line. Clearly it shouldn't be there, but it already was before the
commit mentioned above. Fixing that also fixes the readline abort
shown above.
The problem starts when command_line_input passes a NULL prompt to
gdb_readline_wrapper when it finds previous incomplete input due to a
backslash, trying to fetch more input without printing another ">"
secondary prompt. That itself should not be a problem, because
passing NULL to gdb_readline_wrapper has the same meaning as passing a
pointer to empty string, since gdb_readline_wrapper exposes the same
interface as 'readline(char *)'. However, gdb_readline_wrapper passes
the prompt argument directly to display_gdb_prompt, and for the
latter, a NULL prompt argument has a different meaning - it requests
printing the primary prompt.
Before commit 782a7b8ef9c096 (which rewrote gdb_readline_wrapper to
use asynchronous readline), GDB behaved like this:
(gdb) commands
[....]
>print \
1
>end
(gdb)
The above is what this commit restores GDB back to.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR cli/21218
* top.c (gdb_readline_wrapper): Avoid passing NULL to
display_gdb_prompt.
(command_line_input): Add comment.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR cli/21218
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
New proc.
(top level): Call it.
Commit d7e747318f ("Eliminate make_cleanup_ui_file_delete / make
ui_file a class hierarchy") regressed the TUI's command window.
Newlines miss doing a "carriage return", resulting in output like:
~~~~~~~~~~~~~~~~~~
(gdb) helpList of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before the commit mentioned above, the default ui_file->to_write
implementation had a hack that would defer into the ui_file->to_fputs
method. The TUI's ui_file did not implement the to_write method, so
all writes would end up going to the ncurses window via tui_file_fputs
-> tui_puts.
After the commit above, the hack is gone, but the TUI's ui_file still
does not implement the ui_file::write method. Since tui_file inherits
from stdio_file, writing to a tui_file ends up doing fwrite on the
FILE stream the TUI is "associated" with, via stdio_file::write,
instead of writing to the ncurses window.
The fix is to have tui_file override the "write" method.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* tui/tui-file.c (tui_file::write): New.
* tui/tui-file.h (tui_file): Override "write".
* tui/tui-io.c (do_tui_putc, update_start_line): New functions,
factored out from ...
(tui_puts): ... here.
(tui_putc): Use them.
(tui_write): New function.
* tui/tui-io.h (tui_write): Declare.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* gdb.tui/tui-nl-filtered-output.exp: New file.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/completion.exp: Move TUI completion tests to ...
* gdb.tui/completion.exp: ... this new file.
Let's start putting TUI tests in their own dir.
gdb/testsuite/
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/tui-disasm-long-lines.c,
gdb.base/tui-disasm-long-lines.exp, gdb.base/tui-layout.c,
gdb.base/tui-layout.exp: Move to ...
* gdb.tui/: ... this new directory.
Commit d7e747318f ("Eliminate make_cleanup_ui_file_delete / make
ui_file a class hierarchy") introduced a problem when using "layout
regs", that leads gdb to crash when issuing:
./gdb ./a.out -ex 'layout regs' -ex start
From the backtrace, it's caused by this 'delete' on tui_restore_gdbout():
(gdb) bt
#0 0x00007ffff6b962b2 in free () from /lib64/libc.so.6
#1 0x000000000059fa47 in tui_restore_gdbout (ui=0x22997b0) at ../../gdb/tui/tui-regs.c:714
#2 0x0000000000619996 in do_my_cleanups (pmy_chain=pmy_chain@entry=0x1e08320 <cleanup_chain>, old_chain=old_chain@entry=0x235b4b0) at ../../gdb/common/cleanups.c:154
#3 0x0000000000619b1d in do_cleanups (old_chain=old_chain@entry=0x235b4b0) at ../../gdb/common/cleanups.c:176
#4 0x000000000059fb0d in tui_register_format (frame=frame@entry=0x22564e0, regnum=regnum@entry=0) at ../../gdb/tui/tui-regs.c:747
#5 0x000000000059ffeb in tui_get_register (data=0x2434d18, changedp=0x0, regnum=0, frame=0x22564e0) at ../../gdb/tui/tui-regs.c:768
#6 tui_show_register_group (refresh_values_only=<optimized out>, frame=0x22564e0, group=0x1e09250 <general_group>) at ../../gdb/tui/tui-regs.c:287
#7 tui_show_registers (group=0x1e09250 <general_group>) at ../../gdb/tui/tui-regs.c:156
#8 0x00000000005a07cf in tui_check_register_values (frame=frame@entry=0x22564e0) at ../../gdb/tui/tui-regs.c:496
#9 0x00000000005a3e65 in tui_check_data_values (frame=frame@entry=0x22564e0) at ../../gdb/tui/tui-windata.c:232
#10 0x000000000059cf65 in tui_refresh_frame_and_register_information (registers_too_p=1) at ../../gdb/tui/tui-hooks.c:156
#11 0x00000000006d5c05 in generic_observer_notify (args=0x7fffffffdbe0, subject=<optimized out>) at ../../gdb/observer.c:167
#12 observer_notify_normal_stop (bs=<optimized out>, print_frame=print_frame@entry=1) at ./observer.inc:61
#13 0x00000000006a6409 in normal_stop () at ../../gdb/infrun.c:8364
#14 0x00000000006af8f5 in fetch_inferior_event (client_data=<optimized out>) at ../../gdb/infrun.c:3990
#15 0x000000000066f0fd in gdb_wait_for_event (block=block@entry=0) at ../../gdb/event-loop.c:859
#16 0x000000000066f237 in gdb_do_one_event () at ../../gdb/event-loop.c:322
#17 0x000000000066f386 in gdb_do_one_event () at ../../gdb/event-loop.c:353
#18 0x00000000007411bc in wait_sync_command_done () at ../../gdb/top.c:570
#19 0x0000000000741426 in maybe_wait_sync_command_done (was_sync=0) at ../../gdb/top.c:587
#20 execute_command (p=<optimized out>, p@entry=0x7fffffffe43a "start", from_tty=from_tty@entry=1) at ../../gdb/top.c:676
#21 0x00000000006c2048 in catch_command_errors (command=0x741200 <execute_command(char*, int)>, arg=0x7fffffffe43a "start", from_tty=1) at ../../gdb/main.c:376
#22 0x00000000006c2b60 in captured_main_1 (context=0x7fffffffde70) at ../../gdb/main.c:1119
#23 captured_main (data=0x7fffffffde70) at ../../gdb/main.c:1140
#24 gdb_main (args=args@entry=0x7fffffffdf90) at ../../gdb/main.c:1158
#25 0x0000000000408cf5 in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:32
(gdb) f 1
#1 0x000000000059fa47 in tui_restore_gdbout (ui=0x22997b0) at ../../gdb/tui/tui-regs.c:714
714 delete gdb_stdout;
The problem is simply that the commit mentioned above made the ui_file
that gdb_stdout is temporarily set to be a stack-allocated
string_file, while before it used to be a heap-allocated ui_file. The
fix is simply to remove the now-incorrect delete.
New test included, which exercises enabling all TUI layouts, with and
without execution. (This particular crash only triggers with
execution.)
gdb/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* tui/tui-regs.c (tui_restore_gdbout): Don't delete gdb_stdout.
gdb/testsuite/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* gdb.base/tui-layout.c: New file.
* gdb.base/tui-layout.exp: New file.
To better reflect what the testcase is about, and to make room for a
different testcase.
gdb/testsuite/ChangeLog:
2017-03-07 Pedro Alves <palves@redhat.com>
* gdb.base/tui-layout.c: Rename to ...
* gdb.base/tui-disasm-long-lines.c: ... this.
* gdb.base/tui-layout.exp: Rename to ...
* gdb.base/tui-disasm-long-lines.exp: ... this.
This patch initializes the BND registers before executing the inferior
call. BND registers can be in arbitrary values at the moment of the
inferior call. In case the function being called uses as part of the
parameters BND register, e.g. when passing a pointer as parameter, the
current value of the register will be used. This can cause boundary
violations that are not due to a real bug or even desired by the user.
In this sense the best to be done is set the BND registers to allow
access to the whole memory, i.e. initialized state, before pushing the
inferior call.
2017-03-07 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* i387-tdep.h (i387_reset_bnd_regs): Add function definition.
* i387-tdep.c (i387_reset_bnd_regs): Add function implementation.
* i386-tdep.c (i386_push_dummy_call): Call i387_reset_bnd_regs.
* amd64-tdep (amd64_push_dummy_call): Call i387_reset_bnd_regs.
gdb/testsuite/ChangeLog:
* i386-mpx-call.c: New file.
* i386-mpx-call.exp: New file.
gdb/doc/ChangeLog:
* Memory Protection Extensions: Add information about inferior
calls.
This commit adds support to GDB so that it can modify the disassembler-options
value that is passed to the disassembler, similar to objdump's -M option.
Currently, the only supported targets are ARM, PowerPC and S/390, but
adding support for a new target(s) is not difficult.
include/
* dis-asm.h (disasm_options_t): New typedef.
(parse_arm_disassembler_option): Remove prototype.
(set_arm_regname_option): Likewise.
(get_arm_regnames): Likewise.
(get_arm_regname_num_options): Likewise.
(disassemble_init_s390): New prototype.
(disassembler_options_powerpc): Likewise.
(disassembler_options_arm): Likewise.
(disassembler_options_s390): Likewise.
(remove_whitespace_and_extra_commas): Likewise.
(disassembler_options_cmp): Likewise.
(next_disassembler_option): New inline function.
(FOR_EACH_DISASSEMBLER_OPTION): New macro.
opcodes/
* disassemble.c Include "safe-ctype.h".
(disassemble_init_for_target): Handle s390 init.
(remove_whitespace_and_extra_commas): New function.
(disassembler_options_cmp): Likewise.
* arm-dis.c: Include "libiberty.h".
(NUM_ELEM): Delete.
(regnames): Use long disassembler style names.
Add force-thumb and no-force-thumb options.
(NUM_ARM_REGNAMES): Rename from this...
(NUM_ARM_OPTIONS): ...to this. Use ARRAY_SIZE.
(get_arm_regname_num_options): Delete.
(set_arm_regname_option): Likewise.
(get_arm_regnames): Likewise.
(parse_disassembler_options): Likewise.
(parse_arm_disassembler_option): Rename from this...
(parse_arm_disassembler_options): ...to this. Make static.
Use new FOR_EACH_DISASSEMBLER_OPTION macro to scan over options.
(print_insn): Use parse_arm_disassembler_options.
(disassembler_options_arm): New function.
(print_arm_disassembler_options): Handle updated regnames.
* ppc-dis.c: Include "libiberty.h".
(ppc_opts): Add "32" and "64" entries.
(ppc_parse_cpu): Use ARRAY_SIZE and disassembler_options_cmp.
(powerpc_init_dialect): Add break to switch statement.
Use new FOR_EACH_DISASSEMBLER_OPTION macro.
(disassembler_options_powerpc): New function.
(print_ppc_disassembler_options): Use ARRAY_SIZE.
Remove printing of "32" and "64".
* s390-dis.c: Include "libiberty.h".
(init_flag): Remove unneeded variable.
(struct s390_options_t): New structure type.
(options): New structure.
(init_disasm): Rename from this...
(disassemble_init_s390): ...to this. Add initializations for
current_arch_mask and option_use_insn_len_bits_p. Remove init_flag.
(print_insn_s390): Delete call to init_disasm.
(disassembler_options_s390): New function.
(print_s390_disassembler_options): Print using information from
struct 'options'.
* po/opcodes.pot: Regenerate.
binutils/
* objdump.c (main): Use remove_whitespace_and_extra_commas.
gdb/
* NEWS: Mention new set/show disassembler-options commands.
* doc/gdb.texinfo: Document new set/show disassembler-options commands.
* disasm.c: Include "arch-utils.h", "gdbcmd.h" and "safe-ctype.h".
(prospective_options): New static variable.
(gdb_disassembler::gdb_disassembler): Initialize
m_di.disassembler_options.
(gdb_buffered_insn_length_init_dis): Initilize di->disassembler_options.
(get_disassembler_options): New function.
(set_disassembler_options): Likewise.
(set_disassembler_options_sfunc): Likewise.
(show_disassembler_options_sfunc): Likewise.
(disassembler_options_completer): Likewise.
(_initialize_disasm): Likewise.
* disasm.h (get_disassembler_options): New prototype.
(set_disassembler_options): Likewise.
* gdbarch.sh (gdbarch_disassembler_options): New variable.
(gdbarch_verify_disassembler_options): Likewise.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* arm-tdep.c (num_disassembly_options): Delete.
(set_disassembly_style): Likewise.
(arm_disassembler_options): New static variable.
(set_disassembly_style_sfunc): Convert short style name into long
option name. Call set_disassembler_options.
(show_disassembly_style_sfunc): New function.
(arm_gdbarch_init): Call set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
(_initialize_arm_tdep): Delete regnames variable and update callers.
(arm_disassembler_options): Initialize.
(disasm_options): New variable.
(num_disassembly_options): Rename from this...
(num_disassembly_styles): ...to this. Compute by scanning through
disasm_options.
(valid_disassembly_styles): Initialize using disasm_options.
Remove calls to parse_arm_disassembler_option, get_arm_regnames and
set_arm_regname_option.
Pass show_disassembly_style_sfunc to the "disassembler" setshow command.
* rs6000-tdep.c (powerpc_disassembler_options): New static variable.
(rs6000_gdbarch_init): Call set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
* s390-tdep.c (s390_disassembler_options): New static variable.
(s390_gdbarch_init):all set_gdbarch_disassembler_options and
set_gdbarch_verify_disassembler_options.
gdb/testsuite/
* gdb.arch/powerpc-power.exp: Delete test.
* gdb.arch/powerpc-power.s: Likewise.
* gdb.disasm/disassembler-options.exp: New test.
* gdb.arch/powerpc-altivec.exp: Likewise.
* gdb.arch/powerpc-altivec.s: Likewise.
* gdb.arch/powerpc-altivec2.exp: Likewise.
* gdb.arch/powerpc-altivec2.s: Likewise.
* gdb.arch/powerpc-altivec3.exp: Likewise.
* gdb.arch/powerpc-altivec3.s: Likewise.
* gdb.arch/powerpc-power7.exp: Likewise.
* gdb.arch/powerpc-power7.s: Likewise.
* gdb.arch/powerpc-power8.exp: Likewise.
* gdb.arch/powerpc-power8.s: Likewise.
* gdb.arch/powerpc-power9.exp: Likewise.
* gdb.arch/powerpc-power9.s: Likewise.
* gdb.arch/powerpc-vsx.exp: Likewise.
* gdb.arch/powerpc-vsx.s: Likewise.
* gdb.arch/powerpc-vsx2.exp: Likewise.
* gdb.arch/powerpc-vsx2.s: Likewise.
* gdb.arch/powerpc-vsx3.exp: Likewise.
* gdb.arch/powerpc-vsx3.s: Likewise.
* gdb.arch/arm-disassembler-options.exp: Likewise.
* gdb.arch/powerpc-disassembler-options.exp: Likewise.
* gdb.arch/s390-disassembler-options.exp: Likewise.
As reported in PR21166, there are Intel processors out there that support
rdrand but not rdseed. The fix is to verify both features separately and only
run rdrand/rdseed tests if supported.
gdb/testsuite/ChangeLog:
2017-02-23 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/insn-reverse.x86.c (check_rdrand_support): Renamed to ...
(check_supported_features): ... this. Changed return type to void.
(supports_rdseed): New static global.
(rdseed): Check supports_rdseed.
(initialize): Call check_supported_features.
gdb/
2017-02-21 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* rs6000-tdep.c (LOAD_AND_RESERVE_MASK): Rename from LWARX_MASK.
(STORE_CONDITIONAL_MASK): Rename from STWCX_MASK.
(LBARX_INSTRUCTION, LHARX_INSTRUCTION, LQARX_INSTRUCTION,
STBCX_INSTRUCTION, STHCX_INSTRUCTION, STQCX_INSTRUCTION): New defines.
(IS_LOAD_AND_RESERVE_INSN, IS_STORE_CONDITIONAL_INSN): New macros.
(ppc_displaced_step_copy_insn): Use IS_LOAD_AND_RESERVE_INSN.
(ppc_deal_with_atomic_sequence): Use IS_LOAD_AND_RESERVE_INSN and
IS_STORE_CONDITIONAL_INSN.
gdb/testsuite/
2017-02-21 Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
* gdb.arch/ppc64-isa207-atomic-inst.exp: New testcase based on
gdb.arch/ppc64-atomic-inst.exp. Add tests for lbarx/stbcx, lharx/sthcx
and lqarx/stqcx.
* gdb.arch/ppc64-isa207-atomic-inst.S: New file.
* gdb.arch/ppc64-isa207-atomic-inst.c: Likewise.
DWARF-5 has new form DW_FORM_data16. The problem is that GDB cannot pass
16-byte constant as a constant value as that would require GDB to use GCC
extension __int128.
Formerly such data was coded as DW_FORM_block* so GDB still decodes
DW_FORM_data16 like DW_FORM_block*.
gdb/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (skip_one_die, read_attribute_value)
(dwarf2_const_value_attr, dump_die_shallow)
(dwarf2_get_attr_constant_value, dwarf2_fetch_constant_bytes)
(skip_form_bytes, attr_form_is_constant): Handle DW_FORM_data16.
gdb/testsuite/ChangeLog
2017-02-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/formdata16.c: New file.
* gdb.dwarf2/formdata16.exp: New file.
* lib/dwarf.exp (Dwarf): Add DW_FORM_data16.
This is a fix for PR gdb/21164. The problem started to happen after:
commit 34c41c681f
Author: Doug Evans <xdje42@gmail.com>
AuthorDate: Mon Dec 19 08:33:46 2016 -0800
New syntax for mt print symbols,msymbols,psymbols.
This change introduced new syntax for the mentioned commands, and
improved the parsing of arguments by using 'gdb_buildargv'. However,
it is necessary to check if the argv being built is not NULL, which
can happen if the user doesn't provide any arguments to these
commands.
gdb/ChangeLog:
2017-02-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21164
* psymtab.c (maintenance_print_psymbols): Verify if 'argv' is not
NULL before using it.
* symmisc.c (maintenance_print_symbols): Likewise.
(maintenance_print_msymbols): Likewise.
gdb/testsuite/ChangeLog:
gdb/ChangeLog:
2017-02-15 Sergio Durigan Junior <sergiodj@redhat.com>
PR gdb/21164
* gdb.base/maint.exp: Add testcases for when the commands do
not have arguments.
3d7b173c29 made upper case commands now
illegal. However gdb.cp/chained-calls.exp still contains one test using
P to print an expression. This patch fixes the testcase to use p
instead.
2017-02-13 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/
* gdb.cp/chained-calls.exp: Use p instead of P.
This adds an event that is emitted just before GDB presents a prompt
to the user. This provides Python code a way to react to whatever
changes might have been made by the previous command. For example, in
my GUI I use this to track changes to the selected frame and reflect
them in the UI.
Built and regtested on x86-64 Fedora 23.
gdb/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* python/python.c (gdbpy_before_prompt_hook): Emit before_prompt
event.
* python/py-evts.c (gdbpy_initialize_py_events): Add
before_prompt registry.
* python/py-events.h (events_object) <before_prompt>: New field.
gdb/doc/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* python.texi (Events In Python): Document events.before_prompt.
gdb/testsuite/ChangeLog
2017-02-14 Tom Tromey <tom@tromey.com>
PR python/13598:
* gdb.python/py-events.exp: Add before_prompt event tests.
The test case implptrpiece.exp accesses the second byte of the short
integer number 1 and expects it to be zero. This is valid for
little-endian targets, but fails on big-endian targets.
This is fixed by distinguishing the expected value by endianness.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implptrpiece.exp: Fix check for big-endian targets.
This patch addresses timeout failures i noticed while testing aarch64-elf.
FAIL: gdb.linespec/explicit.exp: complete unique function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-unique function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-existant function name (timeout)
FAIL: gdb.linespec/explicit.exp: complete unique file name (timeout)
FAIL: gdb.linespec/explicit.exp: complete non-unique file name (timeout)
The timeouts were caused by an attempt to match a bell character (x07) that
doesn't show up on my particular test setup.
The bell character is output whenever one tries to complete a pattern and there
are multiple possible matches. When there is only one possible match, GDB will
complete the input pattern without outputting the bell character.
The reason for the discrepancy in this test's behavior is due to the use of
"main" for a unique name test.
On glibc-based systems, GDB may notice the "main_arena" symbol, which is
a data global part of glibc's malloc implementation. Therefore a bell character
will be output because we have a couple possible completion matches.
GDB should not be outputting such a data symbol as a possible match, but this
problem may/will be addressed in a future change and is besides the point of
this particular change.
On systems that are not based on glibc, GDB will not see any other possible
matches for completing "main", so there will be no bell characters.
The use of main is a bit fragile though, so the patch adds a new local function
with a name that has a greater chance of being unique and adjusts the test to
iuse it.
I've also added the regular expression switch (-re) to all the
gdb_test_multiple calls that were missing it. Hopefully this will reduce the
chances of someone wasting time trying to match a regular expression (a much
more common use case) when, in reality, the pattern is supposed to be matched
literally.
gdb/testsuite/ChangeLog
2017-02-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.linespec/explicit.c (my_unique_function_name): New function.
(main): Call my_unique_function_name.
* gdb.linespec/explicit.exp: Use my_unique_function_name to test
completion of patterns with a single match.
Add missing -re switches to gdb_test_multiple calls.
This test attempts to load a x86 core file no matter what target
architectures the tested GDB supports. If GDB doesn't know how to handle
a i386 target, it is very likely the core file will not be recognized.
In this case we should still attempt to load a core file to make sure GDB
doesn't crash or throws an internal error. But we should not proceed to
try to read memory unconditionally.
This patch makes the test check for proper i386 arch support in GDB and bails
out if i386 is not supported and the core file format is not recognized.
This addresses the spurious aarch64-elf failures i'm seeing for this test.
gdb/testsuite/ChangeLog:
2017-02-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.arch/i386-biarch-core.exp: Check for i386 arch support and
return if core file is not recognized.
This is a follow-up to
https://sourceware.org/ml/gdb-patches/2017-02/msg00261.html
This patch restricts queries to the main UI, which allows to avoid two
different problems.
The first one is that GDB is issuing queries on secondary MI channels
for which a TTY is allocated. The second one is that GDB is not able to
handle queries on two (CLI) UIs simultaneously. Restricting queries to
the main UI allows to bypass these two problems.
More details on how/why these two problems happen:
1. Queries on secondary MI UI
The current criterion to decide if we should query the user is whether
the input stream is a TTY. The original way to start GDB in MI mode
from a front-end was to create a subprocess with pipes to its
stdin/stdout. In this case, the input was considered non-interactive
and queries were auto-answered. Now that front-ends can create the MI
channel as a separate UI connected to a dedicated TTY, GDB now
considers this input stream as interactive and sends queries to it.
By restricting queries to the main UI, we make sure we never query on
the secondary MI UI.
2. Simultaneous queries
As Pedro stated it, when you have two queries on two different CLI UIs
at the same time, you end up with the following pseudo stack:
#0 gdb_readline_wrapper
#1 defaulted_query // for UI #2#2 handle_command
#3 execute_command ("handle SIGTRAP" ....
#4 stdin_event_handler // input on UI #2#5 gdb_do_one_event
#7 gdb_readline_wrapper
#8 defaulted_query // for UI #1#9 handle_command
#10 execute_command ("handle SIGINT" ....
#11 stdin_event_handler // input on UI #1#12 gdb_do_one_event
#13 gdb_readline_wrapper
trying to answer the query on UI #1 will therefore answer for UI #2.
By restricting the queries to the main UI, we ensure that there will
never be more than one pending query, since you can't have two queries
on a UI at the same time.
I added a snippet to gdb.base/new-ui.exp to verify that we get a query
on the main UI, but that we don't on the secondary one (or, more
precisely, that it gets auto-answered).
gdb/ChangeLog:
* utils.c (defaulted_query): Don't query on secondary UIs.
gdb/testsuite/ChangeLog:
* gdb.base/new-ui.exp (do_test): Test queries behavior on main
and extra UIs.
While testing this series I saw some errors from the Python test
suite. There were a couple of tests using "P" as a command; this
changes them to "p".
gdb/testsuite/ChangeLog
2017-02-10 Tom Tromey <tom@tromey.com>
* gdb.python/py-xmethods.exp: Use "p" command, not "P".
Currently, the breakpoint documentation refers to some commands taking breakpoint
"ranges" as arguments. We discussed this with Pedro and concluded that it would
be more accurate to speak in terms of breakpoint "lists", whose elements can optionally
be ranges. I also fixed a couple of minor mistakes in the docs.
gdb/ChangeLog:
* breakpoint.c (_initialize_breakpoint): Update the help description
of the 'commands' command to indicate that it takes a list argument.
gdb/doc/ChangeLog:
* gdb.texinfo (Breakpoints): Reword documentation to speak in terms of
space-separated breakpoint lists. Also add a missing @table command
and @cindex for breakpoint lists.
gdb/testsuite/ChangeLog:
* gdb.base/help.exp: Update match pattern for testing 'help commands'.
When defining a new macro, "command" is not recognized as an alias for
"commands":
(gdb) define breakmain
Type commands for definition of "breakmain".
End with a line saying just "end".
>break main
>command
>echo "IN MAIN\n"
>end
(gdb)
There is a special case for while-stepping, where 'ws' and 'stepping' are
recognized explicitely. Instead of adding more special cases, this change
uses cli-decode.
gdb/ChangeLog:
* cli/cli-decode.c (find_command_name_length): Make it extern.
* cli/cli-decode.h (find_command_name_length): Declare.
* cli/cli-script.c (command_name_equals, line_first_arg):
New functions.
(process_next_line): Use cli-decode to parse command names.
(build_command_line): Make args a constant pointer.
gdb/testsuite/ChangeLog:
* gdb.base/define.exp: Add test for command abbreviations
in define.
This patch addresses BZ 21005, which is gdb failing to recognize an rdrand
instruction.
It enables support for both rdrand and rdseed and handles extended register
addressing (R8~R15) for 16-bit, 32-bit and 64-bit.
gdb/ChangeLog
2017-02-06 Luis Machado <lgustavo@codesourcery.com>
* NEWS: Mention support for record/replay of Intel 64 rdrand and
rdseed instructions.
i386-tdep.c (i386_process_record): Handle Intel 64 rdrand and rseed.
gdb/testsuite/ChangeLog:
2017-02-06 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/insn-reverse.c: Include insn-reverse-x86.c.
* gdb.reverse/insn-reverse-x86.c: New file.
gdb/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
Provide and use sparc32 and sparc64 target description XML files.
* features/sparc/sparc32-cp0.xml, features/sparc/sparc32-cpu.xml,
features/sparc/sparc32-fpu.xml: New files for sparc 32-bit.
* features/sparc/sparc64-cp0.xml, features/sparc/sparc64-cpu.xml,
features/sparc/sparc64-fpu.xml: New files for sparc 64-bit.
* features/sparc/sparc32-solaris.xml: New file.
* features/sparc/sparc64-solaris.xml: New file.
* features/sparc/sparc32-solaris.c: Generated.
* features/sparc/sparc64-solaris.c: Generated.
* sparc-tdep.h: Account for differences in target descriptions.
* sparc-tdep.c (sparc32_register_name): Use target provided registers.
(sparc32_register_type): Use target provided registers.
(validate_tdesc_registers): New function.
(sparc32_gdbarch_init): Use tdesc_has_registers.
Set pseudoregister functions.
* sparc64-tdep.c (sparc64_register_name): Use target provided registers.
(sparc64_register_type): Use target provided registers.
(sparc64_init_abi): Set pseudoregister functions.
gdb/doc/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
* gdb.texinfo: (Standard Target Features): Document SPARC features.
(Sparc Features): New node.
gdb/testsuite/ChangeLog:
2017-02-06 Ivo Raisr <ivo.raisr@oracle.com>
PR tdep/20936
* gdb.xml/tdesc-regs.exp: Provide sparc core registers for the tests.
While looking into PR rust/21097, I found that ptype of a
single-element enum in Rust did not always format the result properly.
In particular, it would leave out the members of a tuple struct.
Further testing showed that it also did the wrong thing for ordinary
struct members as well.
This patch fixes these problems. I'm marking it as being associated
with the PR, since that is where the discovery was made; but this
doesn't actually fix that PR (which I think ultimately is due to a
Rust compiler bug).
Built and regtested on x86-64 Fedora 25, using the system Rust
compiler. I'm checking this in.
2017-02-03 Tom Tromey <tom@tromey.com>
PR rust/21097:
* rust-lang.c (rust_print_type) <TYPE_CODE_UNION>: Handle enums
with a single member.
2017-02-03 Tom Tromey <tom@tromey.com>
PR rust/21097:
* gdb.rust/simple.exp: Add new tests.
This commit fixes a "-gdb-set logging redirect on" crash by not
handling "logging redirect on" on the fly.
Previous discussion here:
https://sourceware.org/ml/gdb-patches/2017-01/msg00467.html
Code for handling "logging redirect on" on the fly was added here:
https://sourceware.org/ml/gdb-patches/2010-08/msg00202.html
Meanwhile, MI gained support for logging, but flipping redirect "on"
on the fly was not considered. The result is that this sequence of
commands crashes GDB:
-gdb-set logging on
-gdb-set logging redirect on
Program received signal SIGSEGV, Segmentation fault.
0x00000000008dd7bc in gdb_flush (file=0x2a097f0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/ui-file.c:95
194 file->to_flush (file);
(top-gdb) bt
#0 0x00000000008dd7bc in gdb_flush(ui_file*) (file=0x2a097f0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/ui-file.c:95
#1 0x00000000007b5f34 in gdb_wait_for_event(int) (block=0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:752
#2 0x00000000007b52b6 in gdb_do_one_event() () at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:322
#3 0x00000000007b5362 in start_event_loop() () at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/event-loop.c:371
#4 0x000000000082704a in captured_command_loop(void*) (data=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:325
#5 0x00000000007b8d7c in catch_errors(int (*)(void*), void*, char*, return_mask) (func=0x827008 <captured_command_loop(void*)>, func_args=0x0, errstring=0x11dee51 "", mask=RETURN_MASK_ALL) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/exceptions.c:236
#6 0x000000000082839b in captured_main(void*) (data=0x7fffffffd820) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:1148
During symbol reading, cannot get low and high bounds for subprogram DIE at 24065.
#7 0x00000000008283c4 in gdb_main(captured_main_args*) (args=0x7fffffffd820) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/main.c:1158
#8 0x0000000000412d4d in main(int, char**) (argc=4, argv=0x7fffffffd928) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/gdb.c:32
The handling of redirect on the fly is not really a use case we need
to handle, IMO. Its inconsistent (other "set logging foo" commands
aren't handled on the fly), and complicates the code significantly.
Instead of complicating it further for MI, go back to the original
idea of warning, only:
https://sourceware.org/ml/gdb-patches/2010-08/msg00083.html
New test included.
gdb/ChangeLog:
2017-02-02 Pedro Alves <palves@redhat.com>
* cli/cli-logging.c (maybe_warn_already_logging): New factored out
from ...
(set_logging_overwrite): ... here.
(logging_no_redirect_file): Delete.
(set_logging_redirect): Don't handle redirection on the fly.
Instead warn that "logging off" / "logging on" is necessary.
(pop_output_files): Delete references to logging_no_redirect_file.
(show_logging_command): Always speak in terms of what will happen
once logging is reenabled.
gdb/testsuite/ChangeLog:
2017-02-02 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-logging.exp: Add "redirect while already logging"
tests.
When a variable's location is expressed as DW_OP_implicit_value, but the
given value is longer than needed, which bytes should be used? GDB's
current logic was introduced with a patch from 2011 and uses the "least
significant" bytes:
https://sourceware.org/ml/gdb-patches/2011-08/msg00123.html
Now consider a sub-value from such a location at a given offset, accessed
through DW_OP_implicit_pointer. Which bytes should be used for that? The
patch above *always* uses the last bytes on big-endian targets, ignoring
the offset.
E.g., given the code snippet
const char foo[] = "Hello, world!";
const char *a = &foo[0];
const char *b = &foo[7];
assume that `foo' is described as DW_OP_implicit_value and `a' and `b'
each as DW_OP_implicit_pointer into that value. Then with current GDB
`*a' and `*b' yield the same result -- the string's zero terminator.
This patch basically reverts the portion of the patch above that deals
with DW_OP_implicit_value. This fixes the offset handling and also goes
back to dropping the last instead of the first bytes on big-endian targets
if the implicit value is longer than needed. The latter aspect of the
change probably doesn't matter for actual programs, but simplifies the
logic.
The patch also cleans up the original code a bit and adds appropriate test
cases.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-stack-value.exp: Adjust expected result of
taking a 2-byte value out of a 4-byte DWARF implicit value on
big-endian targets.
* gdb.dwarf2/nonvar-access.exp: Add more comments to existing
logic. Add test cases for DW_OP_implicit.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): For
DWARF_VALUE_LITERAL, no longer ignore the offset on big-endian
targets. And if the implicit value is longer than needed, extract
the first bytes instead of the "least significant" ones.
If GDB is running when gdb_skip_xml_tests is called with
--target_board=native-extended-gdbserer.exp, it fails with:
(gdb) FAIL: ....exp: set tdesc filename .../trivial.xml (got interactive prompt)
monitor exit
Diagnose this in gdb_skip_xml_tests to generate a more meaningful error message:
ERROR: tcl error sourcing ....exp.
ERROR: GDB must not be running in gdb_skip_xml_tests.
while executing
[...]
testsuite/
* lib/gdb.exp (gdb_skip_xml_tests): Error if GDB is running.
Parts of gdb.btrace/enable.exp are only valid for native debug. The check for
skip_gdbserver_tests is done while GDB is running, though, which causes it to
fail with --target_board=native-extended-gdbserver. Exit GDB before that check.
testsuite/
* gdb.btrace/enable.exp: Call gdb_exit before skip_gdbserver_tests.
With --target_board=native-extended-gdbserver non-stop tests are failing with
UNTESTED: gdb.btrace/non-stop.exp: failed to run to main
Fix that by adding '-ex "set non-stop on"' to GDBFLAGS before restarting.
testsuite/
* gdb.btrace/non-stop.exp: Add '-ex "set non-stop on"' to GDBFLAGS.
We may silently skip gdb.btrace tests if
- the target does not support record-btrace
- the target does not support TSX
- the target does not support gdbserver
- we fail to compile the test
- we fail to run to main
Add unsupported/untested messages for each of those.
testsuite/
* gdb.btrace/buffer-size.exp: Add unsupported/untested message if
the test is skipped.
* gdb.btrace/data.exp: Likewise.
* gdb.btrace/delta.exp: Likewise.
* gdb.btrace/dlopen.exp: Likewise.
* gdb.btrace/enable-running.exp: Likewise.
* gdb.btrace/enable.exp: Likewise.
* gdb.btrace/exception.exp: Likewise.
* gdb.btrace/function_call_history.exp: Likewise.
* gdb.btrace/gcore.exp: Likewise.
* gdb.btrace/instruction_history.exp: Likewise.
* gdb.btrace/multi-thread-step.exp: Likewise.
* gdb.btrace/nohist.exp: Likewise.
* gdb.btrace/non-stop.exp: Likewise.
* gdb.btrace/reconnect.exp: Likewise.
* gdb.btrace/record_goto-step.exp: Likewise.
* gdb.btrace/record_goto.exp: Likewise.
* gdb.btrace/rn-dl-bind.exp: Likewise.
* gdb.btrace/segv.exp: Likewise.
* gdb.btrace/step.exp: Likewise.
* gdb.btrace/stepi.exp: Likewise.
* gdb.btrace/tailcall-only.exp: Likewise.
* gdb.btrace/tailcall.exp: Likewise.
* gdb.btrace/tsx.exp: Likewise.
* gdb.btrace/unknown_functions.exp: Likewise.
* gdb.btrace/vdso.exp: Likewise.
When recording is started for a running thread, GDB was able to start tracing
but then failed to read registers to insert the initial entry for the current
PC. We don't really need that initial entry if we don't know where exactly we
started recording. Skip that step to allow recording to be started while
threads are running.
If we do run into errors, we need to undo the tracing enable to not leak this
thread. The operation did not complete so our caller won't clean up this
thread.
For the BTRACE_FORMAT_PT btrace format, we don't need that initial entry since
it will be recorded in the trace. We can omit the call to btrace_add_pc.
gdb/
* btrace.c (btrace_enable): Do not call btrace_add_pc for
BTRACE_FORMAT_PT or if can_access_registers_ptid returns false.
(btrace_fetch): Assert can_access_registers_ptid.
* record-btrace.c (require_btrace_thread, record_btrace_info): Call
validate_registers_access.
testsuite/
* gdb.btrace/enable-running.c: New.
* gdb.btrace/enable-running.exp: New.
This patch allows examination of the registers FS_BASE and GS_BASE
for Linux Systems running on 64bit. Tests for simple read and write
of the new registers is also added with this patch.
2017-01-27 Walfred Tedeschi <walfred.tedeschi@intel.com>
Richard Henderson <rth@redhat.com>
gdb/ChangeLog:
* amd64-linux-nat.c (PTRACE_ARCH_PRCTL): New define.
(amd64_linux_fetch_inferior_registers): Add case to fetch FS_BASE
GS_BASE for older kernels.
(amd64_linux_store_inferior_registers): Add case to store FS_BASE
GS_BASE for older kernels.
* amd64-linux-tdep.c (amd64_linux_gregset_reg_offset): Add FS_BASE
and GS_BASE to the offset table.
(amd64_linux_register_reggroup_p): Add FS_BASE and GS_BASE to the
system register group.
* amd64-nat.c (amd64_native_gregset_reg_offset): Implements case
for older kernels.
* amd64-tdep.c (amd64_init_abi): Add segment registers for the
amd64 ABI.
* amd64-tdep.h (amd64_regnum): Add AMD64_FSBASE_REGNUM and
AMD64_GSBASE_REGNUM.
(AMD64_NUM_REGS): Set to AMD64_GSBASE_REGNUM + 1.
* features/Makefile (amd64-linux.dat, amd64-avx-linux.dat)
(amd64-mpx-linux.dat, amd64-avx512-linux.dat, x32-linux.dat)
(x32-avx-linux.dat, x32-avx512-linux.dat): Add
i386/64bit-segments.xml in those rules.
* features/i386/64bit-segments.xml: New file.
* features/i386/amd64-avx-mpx-linux.xml: Add 64bit-segments.xml.
* features/i386/amd64-avx-linux.xml: Add 64bit-segments.xml.
* features/i386/amd64-avx512-linux.xml: Add 64bit-segments.xml.
* features/i386/amd64-mpx-linux.xml: Add 64bit-segments.xml.
* features/i386/x32-avx512-linux.xml: Add 64bit-segments.xml.
* features/i386/x32-avx-linux.xml: Add 64bit-segments.xml.
* features/i386/amd64-linux.xml: Add 64bit-segments.xml.
* features/i386/amd64-avx-linux.c: Regenerated.
* features/i386/amd64-avx-mpx-linux.c: Regenerated.
* features/i386/amd64-avx-mpx.c: Regenerated.
* features/i386/amd64-avx512-linux.c: Regenerated.
* features/i386/amd64-linux.c: Regenerated.
* features/i386/amd64-mpx-linux.c: Regenerated.
* features/i386/i386-avx-mpx-linux.c: Regenerated.
* features/i386/i386-avx-mpx.c: Regenerated.
* features/i386/x32-avx-linux.c: Regenerated.
* features/i386/x32-avx512-linux.c: Regenerated.
* regformats/i386/amd64-avx-linux.dat: Regenerated.
* regformats/i386/amd64-avx-mpx-linux.dat: Regenerated.
* regformats/i386/amd64-avx512-linux.dat: Regenerated.
* regformats/i386/amd64-linux.dat: Regenerated.
* regformats/i386/amd64-mpx-linux.dat: Regenerated.
* regformats/i386/x32-avx-linux.dat: Regenerated.
* regformats/i386/x32-avx512-linux.dat: Regenerated.
* regformats/i386/x32-linux.dat: Regenerated.
gdb/doc/ChangeLog:
* gdb.texinfo (i386 Features): Add system segment registers
as feature.
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_64_regmap): Add fs_base and gs_base
to the register table.
(x86_fill_gregset): Add support for old kernels for the
fs_base and gs_base system registers.
(x86_store_gregset): Likewise.
* configure.srv (srv_i386_64bit_xmlfiles): Add 64bit-segments.xml.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-gs_base.c: New file.
* gdb.arch/amd64-gs_base.exp: New file.
Change-Id: I2e0eeb93058a2320d4d3b045082643cfe4aff963
Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
With my debug build of Python (--with-pydebug), many tests fails because
of the same issue. Python scripts are loaded by the tests using this
pattern:
(gdb) python exec (open ('file.py').read ())
This causes Python to output this warning:
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='file.py' mode='r' encoding='ANSI_X3.4-1968'>
and the test to fail because of that extra output. Instead of using the
open + read + exec trick which leaks the file and causes the warning,
why not just source the files?
(gdb) source file.py
This patch changes this, and standardizes the test names of the tests I
touched to "load python file" (some of them were empty, others were
overly complicated).
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.exp: Load python file using "source".
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-evsignal.exp: Likewise.
* gdb.python/py-evthreads.exp: Likewise.
* gdb.python/py-frame-args.exp: Likewise.
* gdb.python/py-framefilter-invalidarg.exp: Likewise.
* gdb.python/py-framefilter-mi.exp: Likewise.
* gdb.python/py-framefilter.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
* gdb.python/py-pp-maint.exp: Likewise.
* gdb.python/py-pp-registration.exp: Likewise.
* gdb.python/py-prettyprint.exp: Likewise.
(run_lang_tests): Likewise.
* gdb.python/py-typeprint.exp: Likewise.
Exercising aarch64-elf with a custom debug stub i noticed a few failures in
both gdb.base/breakpoint-in-ro-region.exp and gdb.base/memattr.exp:
FAIL: gdb.base/breakpoint-in-ro-region.exp: create read-only mem region covering main
FAIL: gdb.base/breakpoint-in-ro-region.exp: writing to read-only memory fails
FAIL: gdb.base/breakpoint-in-ro-region.exp: inserting software breakpoint in read-only memory fails
FAIL: gdb.base/memattr.exp: create mem region 1
FAIL: gdb.base/memattr.exp: create mem region 2
FAIL: gdb.base/memattr.exp: create mem region 3
FAIL: gdb.base/memattr.exp: create mem region 4
FAIL: gdb.base/memattr.exp: create mem region 5
FAIL: gdb.base/memattr.exp: info mem (1)
FAIL: gdb.base/memattr.exp: mem1 cannot be read
FAIL: gdb.base/memattr.exp: mem2 cannot be written
FAIL: gdb.base/memattr.exp: mem2 can be read
FAIL: gdb.base/memattr.exp: disable mem 1
FAIL: gdb.base/memattr.exp: mem 1 was disabled
FAIL: gdb.base/memattr.exp: enable mem 1
FAIL: gdb.base/memattr.exp: mem 1 was enabled
FAIL: gdb.base/memattr.exp: disable mem 2 4
FAIL: gdb.base/memattr.exp: mem 2 and 4 were disabled
FAIL: gdb.base/memattr.exp: enable mem 2-4
FAIL: gdb.base/memattr.exp: mem 2-4 were enabled
FAIL: gdb.base/memattr.exp: mem 1 to 5 were disabled
FAIL: gdb.base/memattr.exp: mem 1 to 5 were enabled
FAIL: gdb.base/memattr.exp: delete mem 1
FAIL: gdb.base/memattr.exp: mem 1 was deleted
FAIL: gdb.base/memattr.exp: delete mem 2 4
FAIL: gdb.base/memattr.exp: mem 2 and 4 were deleted
FAIL: gdb.base/memattr.exp: mem 2-4 were deleted
These failures don't show up with gdbserver or native gdb on Linux because
they don't export any memory maps, therefore the vector of memory regions is
empty.
Outside of that scenario, we can't guarantee the absence of memory regions
reported by the target upon a connection. In our particular target, we
provide a memory map and the memory regions vector ceases to be empty.
With a non-empty memory regions vector, manipulating memory regions will cause
gdb to be more verbose and output text. For example:
memattr.c:require_user_regions
/* Otherwise, let the user know how to get back. */
if (from_tty)
warning (_("Switching to manual control of memory regions; use "
"\"mem auto\" to fetch regions from the target again."));
memattr.c:create_mem_region
if ((lo >= n->lo && (lo < n->hi || n->hi == 0))
|| (hi > n->lo && (hi <= n->hi || n->hi == 0))
|| (lo <= n->lo && ((hi >= n->hi && n->hi != 0) || hi == 0)))
{
printf_unfiltered (_("overlapping memory region\n"));
return;
}
In my particular case i got both of the above messages.
In order to fix this, i've moved the delete_memory proc from
gdb.base/memattr.exp to a new file lib/memory.exp and made lib/gdb.exp
load that file.
For both gdb.base/breakpoint-in-ro-region.exp and gdb.base/memattr.exp the
patch clears all existing memory regions after running to main. That way we
are guaranteed to have a clean state for memory regions so the tests can
exercise whatever they want and have an expected output pattern.
Regression checked on x86-64/Ubuntu 16.04.
gdb/testsuite/ChangeLog:
2017-01-26 Luis Machado <lgustavo@codesourcery.com>
* lib/memory.exp: New file.
* lib/gdb.exp: Load memory.exp.
* gdb.base/memattr.exp (delete_memory): Move proc to
lib/memory.exp and rename to delete_memory_regions.
Replace delete_memory with delete_memory_regions.
Cleanup memory regions before tests.
* gdb.base/breakpoint-in-ro-region.exp: Cleanup memory regions
before tests.
Changes in v2:
- Renamed arch-specific files to insn-reverse-<arch>.c.
- Adjusted according to reviews.
This patch prepares things for an upcoming testcase for record/replay support
on x86. As is, gdb.reverse/insn-reverse.c is divided into sections guarded by
a few #if blocks, and right now it only handles arm/aarch64.
If we move forward with requiring more tests for record/replay on different
architectures, i think this has the potential to become cluttered with a lot
of differing arch-specific code in the same file.
I've broken up the main file into other files with arch-specific bits
(insn-reverse-<arch>.c). The main file will hold the generic pieces that will
take care of calling the tests.
The arch-specific c files are then included at the top of the generic c file.
I've also added a generic initialize function since we need to run pre-test
checks on x86 to make sure the rdrand/rdseed instructions are supported,
otherwise we will run into a SIGILL.
The arch-specific files will implement their own initialize function with
whatever makes sense. Right now the aarch64 and arm files have an empty
initialization function.
Does this look reasonable?
gdb/testsuite/ChangeLog:
2017-01-26 Luis Machado <lgustavo@codesourcery.com>
* gdb.reverse/insn-reverse.c: Move arm and aarch64 code to their own
files.
(initialize): New function conditionally defined.
(testcases): Move within conditional block.
(main): Call initialize.
* gdb.reverse/insn-reverse-aarch64.c: New file, based on aarch64 bits
of gdb.reverse/insn-reverse.c.
* gdb.reverse/insn-reverse-arm.c: New file, based on arm bits of
gdb.reverse/insn-reverse.c.
Hi,
GDB calls some APIs from opcodes to do disassembly and provide some
call backs. This model makes troubles on C++ exception unwinding,
because GDB is a C++ program, and opcodes is still compiled as C.
As we can see, frame #10 and #12 are C++, while #frame 11 is C,
#10 0x0000000000544228 in memory_error (err=TARGET_XFER_E_IO, memaddr=<optimized out>) at ../../binutils-gdb/gdb/corefile.c:237
#11 0x00000000006b0a54 in print_insn_aarch64 (pc=0, info=0xffffffffeeb0) at ../../binutils-gdb/opcodes/aarch64-dis.c:3185
#12 0x0000000000553590 in gdb_pretty_print_insn (gdbarch=gdbarch@entry=0xbbceb0, uiout=uiout@entry=0xbc73d0, di=di@entry=0xffffffffeeb0,
insn=0xffffffffed40, insn@entry=0xffffffffed90, flags=flags@entry=0,
C++ exception unwinder can't go across frame #11 unless it has
unwind table. However, C program on many architectures doesn't
have it in default. As a result, GDB aborts, which is described
in PR 20939.
This is not the first time we see this kind of problem. We've
had a commit 89525768cd
"Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH".
We can fix the disassembly bug in a similar way, this is the option one.
Since opcodes is built with gdb, we fix this problem in a different
way as we did for the same issue with readline. Instead of throwing
exception in dis_asm_memory_error, we record the failed memory
address, and throw exception when GDB returns from opcodes disassemblers.
gdb:
2017-01-26 Yao Qi <yao.qi@linaro.org>
Pedro Alves <palves@redhat.com>
PR gdb/20939
* disasm.c (gdb_disassembler::dis_asm_memory_error): Don't
call memory_error, save memaddr instead.
(gdb_disassembler::print_insn): If gdbarch_print_insn returns
negative, cal memory_error.
* disasm.h (gdb_disassembler) <m_err_memaddr>: New field.
gdb/testsuite:
2017-01-26 Yao Qi <yao.qi@linaro.org>
* gdb.base/all-architectures.exp.in (do_arch_tests): Test
disassemble on address 0.
This patch adds a DW_OP_implicit_value in dwarf assembler, and uses
dwarf assembler in implptr-64bit.exp. Using dwarf assembler in
implptr-64bit.exp exposes some limitations in dwarf assembler,
- some variables are not evaluated in the caller's context, so we
can not pass variable to assembler, like this
Dwarf::assemble $asm_file {
cu {
version $dwarf_version
addr_size $addr_size
is_64 $is_64
} {
}
and
{DW_AT_type :$struct_label "DW_FORM_ref$ref_addr_size"}
this limitation is fixed by adding "uplevel" and "subst".
- dwarf assembler doesn't emit DW_FORM_ref_addr for label referencing.
this limitation is fixed by adding a new character "%",
{ type %$int_label }
this means we want to emit DW_FORM_ref_addr for label referencing.
- we can't set the form of label referencing offset in dwarf assembler.
Nowadays, dwarf assembler guesses the form of labels, which is
DW_FORM_ref4. However, in implptr-64bit.exp, both DW_FORM_ref4
and DW_FORM_ref8 is used (see REF_ADDR in implptr-64bit.S). This
patch adds the flexibility of setting the form of label reference.
Both of them below are valid,
{DW_AT_type :$struct_label}
{DW_AT_type :$struct_label DW_FORM_ref8}
the former form is the default DW_FORM_ref4.
I compared the .debug_info of objects without and with this patch
applied. There is no changes except abbrev numbers.
gdb/testsuite:
2017-01-25 Andreas Arnez <arnez@linux.vnet.ibm.com>
Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/implptr-64bit.exp: Use dwarf assembler.
* gdb.dwarf2/implptr-64bit.S: Remove.
* lib/dwarf.exp (Dwarf): Handle character "%". Evaluate some
variables in caller's context. Add DW_OP_implicit_value.
DW_OP_GNU_implicit_pointer refers to a DIE with an offset of different
sizes in different dwarf versions. In v2, the size is the pointer size,
while in v3 and above, it is the ref_addr size. This patch fixes
dwarf assembler to emit the correct size of offset. We've already fixed
this size issue in gdb,
https://sourceware.org/ml/gdb-patches/2011-09/msg00451.html
gdb/testsuite:
2017-01-25 Yao Qi <yao.qi@linaro.org>
* lib/dwarf.exp (Dwarf::_location): Handle
DW_OP_GNU_implicit_pointer with proper size.
Some leftover uppercase test names in py-xmethods.exp. The patch also
replaces two "continue" calls with untested calls to make things a bit more
clear.
gdb/testsuite/ChangeLog:
2017-01-20 Luis Machado <lgustavo@codesourcery.com>
* gdb.python/py-xmethods.exp: Fix test names starting with lowercase
and add untested calls.
I noticed gdb.python/python.exp failing on aarch64-elf like so:
FAIL: gdb.python/python.exp: Test decode_line func1 line number
This particular test expects the line number for func1 to be 19, hardcoded.
In my aarch64-elf tests gdb thinks func1 is at line 20, making the test fail.
The following patch addresses this by reading the line number information from
GDB and comparing it against the python decoded symtab information.
gdb/testsuite/ChangeLog:
2017-01-20 Luis Machado <lgustavo@codesourcery.com>
* gdb.python/python.exp: Check line number against what GDB thinks
the line number is for func1.
While casting works as expected with expression debugging turned off,
this seems to be an indication that the D language parser function is
doing something wrong in the building of the expression.
Without changing the grammar, using UNOP_CAST_TYPE is the right thing to
do here, as the TypeExp handler has already wrapped the type around a
pair of OP_TYPE opcodes.
gdb/ChangeLog:
* d-exp.y (CastExpression): Emit UNOP_CAST_TYPE.
gdb/testsuite/ChangeLog:
* gdb.dlang/debug-expr.exp: New file.
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.
gdb/ChangeLog:
Update copyright year range in all GDB files.
I recently see the test fails like this,
(gdb) PASS: gdb.gdb/selftest.exp: step over argv initialization
list^M
487 std::vector<struct cmdarg> cmdarg_vec;^M
(gdb) FAIL: gdb.gdb/selftest.exp: unknown source line (after step over argv initialization)
step^M
std::vector<cmdarg, std::allocator<cmdarg> >::vector (this=0x7fffffffdc10) at ../../binutils-gdb/gdb/main.c:487^M
487 std::vector<struct cmdarg> cmdarg_vec;^M
(gdb) FAIL: gdb.gdb/selftest.exp: step into xmalloc call
These fails are caused by using std::vector in commit
f60ee22ea1. selttest.exp should match
the source code of GDB. It is a maintenance pain, so this patch
removes do_steps_and_nexts.
gdb/testsuite:
2016-12-19 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Remove.
(test_with_self): Don't call do_steps_and_nexts, and remove
code about stepping into xmalloc.
I build GDB with all targets enabled, and "set architecture rx",
GDB crashes,
(gdb) set architecture rx
Program received signal SIGSEGV, Segmentation fault.
append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926
4926 name);
(gdb) bt 10
#0 append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926
#1 0x00000000004ce725 in rx_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rx-tdep.c:1051
#2 0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269
#3 0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557
#4 0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531
#5 0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20bee81 "rx ", from_tty=from_tty@entry=1, c=c@entry=0x20b1540)
at ../../binutils-gdb/gdb/cli/cli-setshow.c:455
#6 0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20bee70 "set architecture rx ", from_tty=1) at ../../binutils-gdb/gdb/top.c:666
#7 0x00000000006935f4 in command_handler (command=0x20bee70 "set architecture rx ") at ../../binutils-gdb/gdb/event-top.c:577
#8 0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767
#9 0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be7f0 "") at ../../binutils-gdb/gdb/event-top.c:200
The cause is that we want to access some builtin types in gdbarch init, but
it is not initialized yet. I fix it by creating the type when it is to be
used. We've already done this in sparc, sparc64 and m68k.
gdb:
2016-12-09 Yao Qi <yao.qi@linaro.org>
PR tdep/20954
* rx-tdep.c (rx_psw_type): New function.
(rx_fpsw_type): New function.
(rx_register_type): Call rx_psw_type and rx_fpsw_type.
(rx_gdbarch_init): Move code to rx_psw_type and
rx_fpsw_type.
gdb/testsuite:
2016-12-09 Yao Qi <yao.qi@linaro.org>
* gdb.base/all-architectures.exp.in: Remove kfail for "rx".
I build GDB for all targets enabled. When I "set architecture rl78",
GDB crashes,
(gdb) set architecture rl78
Program received signal SIGSEGV, Segmentation fault.
append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926
4926 name);
(gdb) bt 10
#0 append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926
#1 0x00000000004aaca8 in rl78_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rl78-tdep.c:1410
#2 0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269
#3 0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557
#4 0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531
#5 0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20be851 "rl78", from_tty=from_tty@entry=1, c=c@entry=0x20b1540)
at ../../binutils-gdb/gdb/cli/cli-setshow.c:455
#6 0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20be840 "set architecture rl78", from_tty=1) at ../../binutils-gdb/gdb/top.c:666
#7 0x00000000006935f4 in command_handler (command=0x20be840 "set architecture rl78") at ../../binutils-gdb/gdb/event-top.c:577
#8 0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767
#9 0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be890 "") at ../../binutils-gdb/gdb/event-top.c:200
The cause is that we want to access some builtin types in gdbarch init, but
it is not initialized yet. I fix it by creating the type when it is to be
used. We've already done this in sparc, sparc64 and m68k.
gdb:
2016-12-09 Yao Qi <yao.qi@linaro.org>
PR tdep/20953
* rl78-tdep.c (rl78_psw_type): New function.
(rl78_register_type): Call rl78_psw_type.
(rl78_gdbarch_init): Move code to rl78_psw_type.
gdb/testsuite:
2016-12-09 Yao Qi <yao.qi@linaro.org>
* gdb.base/all-architectures.exp.in: Remove kfail for rl78.
This adds a test that exposes several problems fixed by earlier
patches:
#1 - Buffer overrun when host/target formats match, but sizes don't.
https://sourceware.org/ml/gdb-patches/2016-03/msg00125.html#2 - Missing handling for FR-V FR300.
https://sourceware.org/ml/gdb-patches/2016-03/msg00117.html#3 - BFD architectures with spaces in their names (v850).
https://sourceware.org/ml/binutils/2016-03/msg00108.html#4 - The OS ABI names with spaces issue.
https://sourceware.org/ml/gdb-patches/2016-03/msg00116.html#5 - Bogus HP/PA long double format.
https://sourceware.org/ml/gdb-patches/2016-03/msg00122.html#6 - Cris big endian internal error.
https://sourceware.org/ml/gdb-patches/2016-03/msg00126.html#7 - Several PowerPC bfd archs/machines not handled by gdb.
https://sourceware.org/bugzilla/show_bug.cgi?id=19797
And hopefully helps catch others in the future.
This started out as a test that simply did,
gdb -ex "print 1.0L"
to exercise #1 above.
Then to cover both 32-bit target / 64-bit host and the converse, I
thought of having the testcase print the floats twice, once with the
architecture set to "i386" and then to "i386:x86-64". This way it
wouldn't matter whether gdb was built as 32-bit or a 64-bit program.
Then I thought that other archs might have similar host/target
floatformat conversion issues as well. Instead of hardcoding some
architectures in the test file, I thought we could just iterate over
all bfd architectures and OS ABIs supported by the gdb build being
tested. This is what then exposed all the other problems listed
above...
With an --enable-targets=all, this exercises over 14 thousand
combinations. If left in a single test file, it all consistenly runs
in under a minute on my machine (An Intel i7-4810MQ @ 2.8 MHZ running
Fedora 23). Split in 8 chunks, as in this commit, it runs in around
25 seconds, with make -j8.
To avoid flooding the gdb.sum file, it avoids calling "pass" on each
tested combination/iteration. I'm explicitly not implementing that by
passing an empty message to gdb_test / gdb_test_multiple, because I
still want a FAIL to be logged in gdb.sum. So instead this puts the
internal passes in the gdb.log file, only, prefixed "IPASS:", for
internal pass. TBC, if some iteration fails, it'll still show up as
FAIL in gdb.sum. If this is an approach that takes on, I can see us
extending the common bits to support it for all testcases.
gdb/testsuite/ChangeLog:
2016-12-09 Pedro Alves <palves@redhat.com>
* gdb.base/all-architectures-0.exp: New file.
* gdb.base/all-architectures-1.exp: New file.
* gdb.base/all-architectures-2.exp: New file.
* gdb.base/all-architectures-3.exp: New file.
* gdb.base/all-architectures-4.exp: New file.
* gdb.base/all-architectures-5.exp: New file.
* gdb.base/all-architectures-6.exp: New file.
* gdb.base/all-architectures-7.exp: New file.
* gdb.base/all-architectures.exp.in: New file.
gdb.perf/skip-prologue.exp is intended to measure the performance of
skipping prologue with prologue analysis by setting breakpoints.
However, if program is compiled with debug info, GDB is smart to
skip prologue by line table from debug info, so prologue analysis
is not exercised at all.
This patch adds a parameter COMPILE to specify compiling with
debug information, otherwise, it is compiled without debug
information.
gdb/testsuite:
2016-12-09 Yao Qi <yao.qi@linaro.org>
* gdb.perf/skip-prologue.exp: Add parameter COMPILE.
This gets rid of more useless pattern matching cases in gdb.base/maint.exp.
gdb/testsuite/ChangeLog:
2016-12-02 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/maint.exp: Use gdb_test instead of gdb_test_multiple when
possible.
Remove useless pattern-matching code.
New in v2:
- A few adjustments / simplifications were possible now that we
require C++11:
. Use std::unique_ptr to make the user_args_stack std::vector own
its elements:
static std::vector<std::unique_ptr<user_args>> user_args_stack;
. use vector::emplace_back to construct elements directly in the
corresponding vectors.
. use std::to_string instead of adding a gdb::to_string
replacement.
- Now includes a test.
Docs/NEWS are unchanged from v1 and have already been approved.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I recently wrote a user-defined command that could benefit from
supporting an unlimited number of arguments:
http://palves.net/list-active-signal-handlers-with-gdb/
E.g., 'info signal-dispositions 1 2 3 4 5 6 7 8 9 10 11'
However, we currently only support up to 10 arguments passed to
user-defined commands ($arg0..$arg9).
I can't find a good reason for that, other than "old code with hard
coded limits". This patch removes that limit and modernizes the code
along the way:
- Makes the user_args struct a real C++ class that uses std::vector
for storage.
- Removes the "next" pointer from within user_args and uses a
std::vector to maintain a stack instead.
- Adds a new RAII-based scoped_user_args_level class to help
push/pop user args in the stack instead of using a cleanup.
gdb/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
* NEWS: Mention that user commands now accept an unlimited number
of arguments.
* cli/cli-script.c: Include <vector>.
(struct string_view): New type.
(MAXUSERARGS): Delete.
(struct user_args): Now a C++ class.
(user_args_stack): New.
(struct scoped_user_args_level): New type.
(execute_user_command): Use scoped_user_args_level.
(arg_cleanup): Delete.
(setup_user_args): Deleted, and refactored as ...
(user_args::user_args): ... this new constructor. Limit of number
of arguments removed.
(insert_user_defined_cmd_args): Defer to user_args_stack.
(user_args::insert_args): New, bits based on old
insert_user_defined_cmd_args with limit of number of arguments
eliminated.
gdb/doc/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (User-defined Commands): Limit on number of
arguments passed to user-defined commands removed; update.
gdb/testsuite/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (user_defined_command_manyargs_test): New
procedure.
(top level): Call it.
We're missing a test that makes sure that arguments to user-defined
commands are handled correctly when a user-defined command calls
another user-defined command / recurses.
The following patch changes that code, so add such a test first so we
can be confident won't be breaking this use case.
gdb/testsuite/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (user_defined_command_args_stack_test):
New procedure.
(top level): Call it.
It'd be handy to be able to iterate over command arguments in
user-defined commands, in order to support optional arguments
($arg0..$argN).
I thought I could make it work with "eval", but alas, it doesn't work
currently. E.g., with:
define test
set $i = 0
while $i < $argc
eval "print $arg%d", $i
set $i = $i + 1
end
end
we get:
(gdb) test 1
$1 = void
(gdb) test 1 2 3
$2 = void
$3 = void
$4 = void
(gdb)
The problem is that "eval" doesn't do user-defined command arguments
substitution after expanding its own argument. This patch fixes that,
which makes the example above work:
(gdb) test 1
$1 = 1
(gdb) test 1 2 3
$2 = 1
$3 = 2
$4 = 3
(gdb)
New test included, similar the above, but also exercises expanding
$argc.
I think this is likely to simplify many scripts out there, so I'm
adding an example to the manual and mentioning it in NEWS as well.
gdb/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
PR cli/20559
* NEWS: Mention "eval" expands user-defined command arguments.
* cli/cli-script.c (execute_control_command): Adjust to rename.
(insert_args): Rename to ...
(insert_user_defined_cmd_args): ... this, and make extern.
* cli/cli-script.h (insert_user_defined_cmd_args): New
declaration.
* printcmd.c: Include "cli/cli-script.h".
(eval_command): Call insert_user_defined_cmd_args.
gdb/doc/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
PR cli/20559
* gdb.texinfo (Define): Add example of using "eval" to process a
variable number of arguments.
(Output) <eval>: Add anchor.
gdb/testsuite/ChangeLog:
2016-12-02 Pedro Alves <palves@redhat.com>
PR cli/20559
* gdb.base/commands.exp (user_defined_command_args_eval): New
procedure.
(top level): Call it.
This reverts the timeout handling (removed by
018572b888) for gdb.cp/ovldbreak.exp until we
decide what to do about this particular function.
gdb/testsuite/ChangeLog:
2016-12-02 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/ovldbreak.exp (take_gdb_out_of_choice_menu): Restore
timeout handling.
This patch adds support for DW_AT_main_subprogram.
This is PR symtab/16264.
DW_AT_main_subprogram is used to mark a program's entry point. GCC
can emit this, and I hope to change the Rust compiler to emit it as
well.
GDB already supports an older, pre-DWARF 4 convention adopted by
FORTRAN compilers, namely to emit DW_AT_calling_convention for the
"main" function. However, I think this support in GDB had a small
bug, in that it seems to rely on the DW_AT_name being read before
DW_AT_calling_convention. This patch fixes this as well.
Built and regtested on x86-64 Fedora 24 and the buildbot. New test
case included.
2016-12-02 Tom Tromey <tom@tromey.com>
PR symtab/16264:
* dwarf2read.c (struct partial_die_info) <main_subprogram>: New
member.
(add_partial_symbol): Call set_objfile_main_name.
(read_partial_die): Handle DW_AT_main_subprogram.
<DW_AT_calling_convention>: don't call set_objfile_main_name, but
set main_subprogram flag.
2016-12-02 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/main-subprogram.c: New file.
* gdb.dwarf2/main-subprogram.exp: New file.
This fixes a few cases where the testcase is explicitly handling timeouts
inside gdb_test_multiple when it is not necessary.
It also converts two gdb_test_multiple calls to gdb_test_no_output calls
(also removing the timeout handling).
gdb/testsuite/ChangeLog:
2016-12-01 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/maint.exp: Remove timeout handling for gdb_test_multiple.
* gdb.cp/gdb2495.exp: Likewise and convert gdb_test_multiple into
gdb_test_no_output for a couple of cases.
* gdb.cp/ovldbreak.exp: Remove timeout handling for gdb_test_multiple.
This fixes offender testcases that have test names starting with uppercase
when using gdb_test_multiple in a multi-line construct.
gdb/testsuite/ChangeLog
2016-12-01 Luis Machado <lgustavo@codesourcery.com>
* gdb.cp/gdb2495.exp: Replace gdb_test_multiple
with gdb_test_no_output.
Use command as test name.
This fixes offender testcases that have test names starting with uppercase
when using gdb_test_no_output in a multi-line construct.
gdb/testsuite/ChangeLog
2016-12-01 Luis Machado <lgustavo@codesourcery.com>
Fix test names starting with uppercase throughout the files.
* gdb.ada/assign_1.exp
* gdb.ada/boolean_expr.exp
* gdb.base/arrayidx.exp
* gdb.base/del.exp
* gdb.base/gcore-buffer-overflow.exp
* gdb.base/testenv.exp
* gdb.compile/compile.exp
* gdb.python/py-framefilter-invalidarg.exp
* gdb.python/py-framefilter.exp
This fixes offender testcases that have test names starting with uppercase
when using gdb_test_multiple in a single-line construct.
gdb/testsuite/ChangeLog
2016-12-01 Luis Machado <lgustavo@codesourcery.com>
Fix test names starting with uppercase throughout the files.
* gdb.arch/i386-bp_permanent.exp
* gdb.arch/i386-gnu-cfi.exp
* gdb.base/disasm-end-cu.exp
* gdb.base/macscp.exp
* gdb.base/pending.exp
* gdb.base/watch_thread_num.exp
* gdb.cp/exception.exp
* gdb.cp/gdb2495.exp
* gdb.cp/local.exp
* gdb.python/py-evsignal.exp
* gdb.python/python.exp
* gdb.trace/tracecmd.exp
Since we don't use suffix rules nor implicit rules in gdb, we can
disable them. The advantage is a slightly faster make [1].
Here are some numbers about the speedup. I ran this on my trusty old
Intel Q6600, so the time numbers are probably higher than what you'd get
on any recent hardware. I ran "make" in the gdb/ directory of an
already built repository (configured with --enable-targets=all). I
recorded the time of execution (average of 5). I then ran "make -d" and
recorded the number of printed lines, which gives a rough idea of the
number of operations done.
I compared the following configurations, to see the impact of both the
empty .SUFFIXES target and the empty pattern rules, as well as running
"make -r", which can be considered the "ideal" case.
A - baseline
B - baseline + .SUFFIXES
C - baseline + pattern rules
D - baseline + .SUFFIXES + pattern rules
E - baseline + make -r
config | time (s) | "make -d"
-----------------------------
A | 5.74 | 2396643
B | 1.19 | 298469
C | 2.81 | 1266573
D | 1.13 | 245489
E | 1.01 | 163914
We can see that the empty .SUFFIXES target has a bigger impact than the
empty pattern rules, but still it doesn't hurt to disable the implicit
pattern rules as well.
There are still some mentions of implicit rules I can't get rid of in
the "make -d" output. For example, it's trying to build .c files from
.w files:
Looking for an implicit rule for '/home/simark/src/binutils-gdb/gdb/infrun.c'.
Trying pattern rule with stem 'infrun'.
Trying implicit prerequisite '/home/simark/src/binutils-gdb/gdb/infrun.w'.
and trying to build Makefile.in from a bunch of extensions:
Looking for an implicit rule for 'Makefile.in'.
Trying pattern rule with stem 'Makefile.in'.
Trying implicit prerequisite 'Makefile.in.o'.
Trying pattern rule with stem 'Makefile.in'.
Trying implicit prerequisite 'Makefile.in.c'.
Trying pattern rule with stem 'Makefile.in'.
Trying implicit prerequisite 'Makefile.in.cc'.
... many more ...
If somebody knows how to disable them, we can do it, but at this point
the returns are minimal, so it is not that important.
I verified that both in-tree and out-of-tree builds work.
[1] Switching from explicit rules to pattern rules for files in
subdirectories actually made it slower, so this is kind of a way to
redeem myself. But it the end it's faster than it was previously,
so it was all worth it. :)
gdb/ChangeLog:
* disable-implicit-rules.mk: New file.
* Makefile.in: Include disable-implicit-rules.mk.
* data-directory/Makefile.in: Likewise.
* gnulib/Makefile.in: Likewise.
gdb/doc/ChangeLog:
* Makefile.in: Likewise.
gdb/gdbserver/ChangeLog:
* Makefile.in: Include disable-implicit-rules.mk.
gdb/testsuite/ChangeLog:
* Makefile.in: Include disable-implicit-rules.mk.
When the user writes or reads a variable whose location is described
with DWARF pieces (DW_OP_piece or DW_OP_bit_piece), GDB's helper
function copy_bitwise is invoked for each piece. The implementation of
this function has a bug that may result in a corrupted copy, depending
on alignment and bit size. (Full-byte copies are not affected.)
This rewrites copy_bitwise, replacing its algorithm by a fixed version,
and adding an appropriate test case. Without the fix the new test case
fails, e.g.:
print def_t
$2 = {a = 0, b = 4177919}
(gdb) FAIL: gdb.dwarf2/nonvar-access.exp: print def_t
Written in binary, the wrong result above looks like this:
01111111011111111111111
Which means that two zero bits have sneaked into the copy of the
original all-one bit pattern. The test uses this simple all-one value
in order to avoid another GDB bug that causes the DWARF piece of a
DW_OP_stack_value to be taken from the wrong end on big-endian
architectures.
gdb/ChangeLog:
* dwarf2loc.c (extract_bits_primitive): Remove.
(extract_bits): Remove.
(copy_bitwise): Rewrite. Fixes a possible corruption that may
occur for non-byte-aligned copies.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/nonvar-access.exp: Add a test for accessing
non-byte-aligned bit fields.
The DW_AT_data_bit_offset attribute was introduced by DWARF V4 and
allows specifying the offset of a data member within its containing
entity. But although the new attribute was intended to replace
DW_AT_bit_offset for this purpose, GDB ignores it, and thus GCC still
emits DW_AT_bit_offset instead. See also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71669.
This change fixes GDB's lack of support for DW_AT_data_bit_offset and
adds an appropriate test case.
gdb/ChangeLog:
PR gdb/12616
* dwarf2read.c (dwarf2_add_field): Handle the DWARF V4 attribute
DW_AT_data_bit_offset.
gdb/testsuite/ChangeLog:
PR gdb/12616
* gdb.dwarf2/nonvar-access.exp: New testcase. Check that GDB
respects the DW_AT_data_bit_offset attribute.
I find the big file lists in the Makefiles a bit ugly and not very
practical. Since there are multiple filenames on each line (as much as
fits in 80 columns), it's not easy to add, remove or change a name in
the middle. As a result, we have a mix of long and short lines in no
particular order (ALL_TARGET_OBS is a good example).
I therefore suggest flattening the lists (one name per line) and keeping
them in alphabetical order. The diffs will be much clearer and merge
conflicts will be easier to resolve.
A nice (IMO) side-effect I observed is that the files are compiled
alphabetically by make, so it gives a rough idea of the progress of the
build.
I added a comment in gdb/Makefile.in to mention to keep the file lists
ordered, and gave the general guidelines on what order to respect. I
added a comment in other Makefiles which refers to gdb/Makefile.in, to
avoid duplication.
Running the patch through the buildbot found that gdb.base/default.exp
started to fail. The languages in the error message shown when typing
"set language" have changed order. We could probably improve gdb so
that it prints them in a stable order, regardless of the order of the
object list passed to the linked, but just fixing the test is easier for
now.
New in v2:
- Change ordering style, directories go at the end.
- Cleanup gdbserver's and data-directory's Makefile as well.
- Add comments at top of Makefiles about the ordering.
- Remove wrong trailing backslahes.
- Fix test gdb.base/default.exp.
gdb/ChangeLog:
* Makefile.in: Add comment about file lists ordering.
(SUBDIR_CLI_OBS, SUBDIR_CLI_SRCS, SUBDIR_MI_OBS, SUBDIR_MI_SRCS,
SUBDIR_TUI_OBS, SUBDIR_TUI_SRCS, SUBDIR_GCC_COMPILE_OBS,
SUBDIR_GCC_COMPILE_SRCS, SUBDIR_GUILE_OBS, SUBDIR_GUILE_SRCS,
SUBDIR_PYTHON_OBS, SUBDIR_PYTHON_SRCS, SUBDIR_GDBTK_OBS,
SUBDIR_GDBTK_SRCS, XMLFILES, REMOTE_OBS, ALL_64_TARGET_OBS,
ALL_TARGET_OBS, SFILES, HFILES_NO_SRCDIR, HFILES_WITH_SRCDIR,
COMMON_OBS, YYFILES, YYOBJ, generated_files, ALLDEPFILES):
Flatten list and order alphabetically.
* data-directory/Makefile.in: Add comment about file lists
ordering.
(GEN_SYSCALLS_FILES, PYTHON_FILE_LIST): Flatten list and order
alphabetically.
gdb/gdbserver/ChangeLog:
* Makefile.in (SFILES, OBS): Flatten list and order
alphabetically.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Fix output of "set language".
Since GNU make is now required to build GDB, we can remove everything
that checks whether the current make implemention is the GNU one or
not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole
lines that were prefixed with @GMAKE_FALSE@.
I removed the code in the configure scripts that set those variables.
I also removed the following bits from the configure scripts:
AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable
internally to be used when invoking Makefiles recursively. I don't see
this variable being used anywhere else (in scripts for example), so I
think it's safe for removal.
AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which
is meant to be used in Makefiles to define the MAKE variable when
using an implementation of make that doesn't already define it.
Since we are now requiring GNU make, we don't need it anymore.
Plus, I don't see SET_MAKE being used anywhere, so I don't think it
was actually doing anything...
gdb/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
gdb/gdbserver/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
gdb/testsuite/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
This patch modifies the unwinder (sniffer) defined in
py-recurse-unwind.py so that, depending upon the value of one of its
class variables, it will take different paths through the code,
testing different functionality.
The original test attempted to obtain the value of an undefined
symbol.
This somewhat expanded test checks to see if 'pc' can be read via
gdb.PendingFrame.read_register() and also via gdb.parse_and_eval().
gdb/testsuite/ChangeLog:
* gdb.python/py-recurse-unwind.c (main): Add loop.
* gdb.python/py-recurse-unwind.py (TestUnwinder): Add calls
to read_register() and gdb.parse_and_eval(). Make each code
call a separate case that can be individually tested.
* gdb.python/py-recurse-unwind.exp (cont_and_backtrace): New
proc. Call cont_and_backtrace for each of the code paths that
we want to test in the unwinder.
The "struct S" type in bitfield-parent-optimized-out.exp is declared to
have a size of 4 bytes but to hold two 4-byte members: an int-based
bitfield and a 4-byte int. Also, both members have the same
data_member_location 2, causing them to overlap and to reach 2 bytes
beyond the structure's boundary.
This is fixed by increasing the structure size to 8 and setting the
first and second member's data_member_location to 0 and 4, respectively.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Fix DWARF code for
the definition of struct S.
Andreas Arnez
Doug Evans
Thomas Preud'homme
Anton Kolesov
Simon Marchi
Keith Seitz
Pedro Alves
Walfred Tedeschi
Peter Bergner
Luis Machado
Edjunior Barbosa Machado
Jan Kratochvil
Michael Sturm
Sergio Durigan Junior
Tim Wiederhake
Tom Tromey
Martin Galvan
Jerome Guitton
Ivo Raisr
Markus Metzger
Simon Marchi
Yao Qi
Iain Buclaw
Joel Brobecker
Doug Evans
Kevin Buettner
Catherine Moore