This has been on my TODO list for a while. There's a really old bug
about this (PR testsuite/8595), and there was no reason for
environ.exp to be specific for hppa* targets. So this patch removes
this constraint, modernizes the testcase, and cleans up some things.
Most of the tests remained, and some were rewritten (especially the
one that checks if "show environment" works, which is something kind
of hard to do).
As a bonus, I'm adding a separated info-program.exp file containing
all the tests related to "info program" that were present on
environ.exp.
Tested locally, everything still passes.
gdb/testsuite/ChangeLog:
2017-04-28 Sergio Durigan Junior <sergiodj@redhat.com>
PR testsuite/8595
* gdb.base/environ.exp: Make test available in all architectures.
Move bits related to "info program" testing to
gdb.base/info-program.exp. Rewrite tests to use the two new
procedures mentione below.
(test_set_show_env_var) New procedure.
(test_set_show_env_var_equal): Likewise.
* gdb.base/info-program.exp: New file.
The test case examine-backward.exp issues the command "x/-s" after the end
of the first string in TestStrings, but without making sure that this
string is preceded by a string terminator. Thus GDB may spuriously print
some random characters from before that string, and then the test fails.
This patch assures that TestStrings is preceded by a string terminator.
gdb/testsuite/ChangeLog:
* gdb.base/examine-backward.c (Barrier): New character array
constant, to ensure that TestStrings is preceded by a string
terminator.
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.
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.
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.
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 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.
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.
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.
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.
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 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 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.
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 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_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
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".
- Use multi_line for matching multi-line GDB output.
- Add a multi_line_input variant of multi_line to build GDB input and
use it throughout.
(The two changes above make the tests much more readable, IMO.)
- Add a new valnum_re global to get rid of the multiple "\\\$\[0-9\]*".
- Remove gdb_stop_suppressing_tests uses.
- tighten a few regexps.
- Replace send_gdb/gdb_expect with gdb_test_multiple and simplify,
making pass/fail messages the same.
gdb/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (runto_or_return): New procedure.
(gdbvar_simple_if_test, gdbvar_simple_while_test)
(gdbvar_complex_if_while_test, progvar_simple_if_test)
(progvar_simple_while_test, progvar_complex_if_while_test)
(if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, redefine_hook_test)
(stray_arg0_test, error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use runto_or_return, $valnum_re,
multi_line_input and multi_line. Remove gdb_expect and
gdb_stop_suppressing_tests uses.
* lib/gdb.exp (valnum_re): New global.
* lib/gdb.exp (valnum_re): New global.
(multi_line_input): New procedure.
While adding new tests to gdb.base/commands.exp, I noticed that the
file includes a bunch of individual testcases split into their own
procedures, and that none have ever been adjusted to use
with_test_prefix. Instead, each gdb_test/gdb_test_multiple/etc
invocation takes care of including the procedure name in the test
message, in order to make sure test messages are unique.
Simon convinced me that using the procedure name as prefix is not that
bad of an idea:
https://sourceware.org/ml/gdb-patches/2016-10/msg00020.html
This commit adds an IMO simpler alternative to
with_test_prefix_procname added by that patch -- a new
"proc_with_prefix" convenience proc that is meant to be used in place
of "proc", and then uses it in commands.exp. Procedures defined with
this automatically run their bodies under with_test_prefix $proc_name.
Here's a sample of the resulting gdb.sum diff:
[...]
-PASS: gdb.base/commands.exp: break factorial #3
-PASS: gdb.base/commands.exp: set value to 5 in test_command_prompt_position
-PASS: gdb.base/commands.exp: if test in test_command_prompt_position
-PASS: gdb.base/commands.exp: > OK in test_command_prompt_position
+PASS: gdb.base/commands.exp: test_command_prompt_position: break factorial
+PASS: gdb.base/commands.exp: test_command_prompt_position: set value to 5
+PASS: gdb.base/commands.exp: test_command_prompt_position: if test
+PASS: gdb.base/commands.exp: test_command_prompt_position: > OK
[...]
gdb/testsuite/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (gdbvar_simple_if_test)
(gdbvar_simple_while_test, gdbvar_complex_if_while_test)
(progvar_simple_if_test, progvar_simple_while_test)
(progvar_complex_if_while_test, if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, deprecated_command_test)
(bp_deleted_in_command, temporary_breakpoint_commands)
(stray_arg0_test, source_file_with_indented_comment)
(recursive_source_test, if_commands_test)
(error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use proc_with_prefix.
* lib/gdb.exp (proc_with_prefix): New proc.
A user reported a GDB crash with TUI when trying to debug a function
with a long demangled C++ method name. It turned out that the logic for
displaying the TUI disassembly window has a bug that can cause a buffer
overrun, possibly overwriting GDB-internal data structures. In
particular, the logic performs an unguarded strcpy.
Another (harmless) bug in tui_alloc_source_buffer causes the buffer to
be two lines longer than needed. This may have made the crash appear
less frequently.
gdb/ChangeLog:
* tui/tui-disasm.c (tui_set_disassem_content): Fix line buffer
overrun due to unchecked strcpy.
gdb/testsuite/ChangeLog:
* gdb.base/tui-layout.c: New file.
* gdb.base/tui-layout.exp: Use tui-layout.c, to ensure that the
disassembly window contains very long lines.
Fixes:
PASS: gdb.base/maint.exp: maint w/o args
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/maint.exp: maint info line-table w/o a file name
The problem is just many symtabs and long line tables, enough to
overflow the expect buffer. Fix this by matching input incrementally.
gdb/testsuite/ChangeLog:
2016-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp <maint info line-table w/o a file name>: Use
gdb_test_multiple, tighten regexps and match symtabs and line
tables incrementally.
Testing a powerpc toolchain running gdbserver on the other end i noticed a
failure in gdb.base/foll-exec.exp. Turns out gdb is outputting a slightly
different pattern due to the presence of debug information.
--
foll-exec is about to execlp(execd-prog)...^M
Continuing.^M
process 21222 is executing new program: gdb.d/outputs/gdb.base/foll-exec/execd-prog^M
^M
Catchpoint 2 (exec'd gdb.d/outputs/gdb.base/foll-exec/execd-prog), _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32^M
--
Notice the presence of source file information.
Now, on my local machine, i get this:
--
foll-exec is about to execlp(execd-prog)...^M
Continuing.^M
process 9285 is executing new program: gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog^M
^M
Catchpoint 2 (exec'd gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog), 0x00007ffff7dd7cc0 in ?? () from /lib64/ld-linux-x86-64.so.2^M
--
So the output differs slightly and the testcase is actually expecting only
the second form with the "in" anchor.
This patch removes the "in" pattern and lets the test match both kinds of
output.
gdb/testsuite/ChangeLog:
2016-10-28 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/foll-exec.exp (do_exec_tests): Make test pattern more
general.
The following testcases make GDB crash whenever an invalid sysroot is
provided, when GDB is unable to find a valid path to the symbol file:
gdb.base/catch-syscall.exp
gdb.base/execl-update-breakpoints.exp
gdb.base/foll-exec-mode.exp
gdb.base/foll-exec.exp
gdb.base/foll-vfork.exp
gdb.base/pie-execl.exp
gdb.multi/bkpt-multi-exec.exp
gdb.python/py-finish-breakpoint.exp
gdb.threads/execl.exp
gdb.threads/non-ldr-exc-1.exp
gdb.threads/non-ldr-exc-2.exp
gdb.threads/non-ldr-exc-3.exp
gdb.threads/non-ldr-exc-4.exp
gdb.threads/thread-execl.exp
The immediate cause of the segv is that follow_exec is passing a NULL
argument (the result of exec_file_find) to strlen.
However, the problem is deeper than that: follow_exec simply isn't
prepared for the case where sysroot translation fails to locate the
new executable. Actually all callers of exec_file_find have bugs due
to confusion between host and target pathnames. This commit attempts
to fix all that.
In terms of the testcases that were formerly segv'ing, GDB now prints
a warning but continues execution of the new program, so that the
tests now mostly FAIL instead. You could argue the FAILs are due to a
legitimate problem with the test environment setting up the sysroot
translation incorrectly.
A new representative test is added which exercises the ne wwarning
code path even with native testing.
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2016-10-25 Sandra Loosemore <sandra@codesourcery.com>
Luis Machado <lgustavo@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR gdb/20569
* exceptions.c (exception_print_same): Moved here from exec.c.
* exceptions.h (exception_print_same): Declare.
* exec.h: Include "symfile-add-flags.h".
(try_open_exec_file): New declaration.
* exec.c (exception_print_same): Moved to exceptions.c.
(try_open_exec_file): New function.
(exec_file_locate_attach): Rename exec_file and full_exec_path
variables to avoid confusion between target and host pathnames.
Move pathname processing logic to exec_file_find. Do not return
early if pathname lookup fails; Call try_open_exec_file.
* infrun.c (follow_exec): Split and rename execd_pathname variable
to avoid confusion between target and host pathnames. Warn if
pathname lookup fails. Pass target pathname to
target_follow_exec, not hostpathname. Call try_open_exec_file.
* main.c (symbol_file_add_main_adapter): New function.
(captured_main_1): Use it.
* solib-svr4.c (open_symbol_file_object): Adjust to pass
symfile_add_flags to symbol_file_add_main.
* solib.c (exec_file_find): Incorporate fallback logic for relative
pathnames formerly in exec_file_locate_attach.
* symfile.c (symbol_file_add_main, symbol_file_add_main_1):
Replace 'from_tty' parameter with a symfile_add_file.
(symbol_file_command): Adjust to pass symfile_add_flags to
symbol_file_add_main.
* symfile.h (symbol_file_add_main): Replace 'from_tty' parameter
with a symfile_add_file.
gdb/testsuite/ChangeLog:
2016-10-25 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/exec-invalid-sysroot.exp: New file.
Since
[commit] [testsuite patch] Fix gcc_compiled for gcc 6 & 7
https://sourceware.org/ml/gdb-patches/2016-10/msg00620.html
there has started running again
Running gdb/testsuite/gdb.base/morestack.exp ...
+FAIL: gdb.base/morestack.exp: continue
+PASS: gdb.base/morestack.exp: up 3000
but as you can see it FAILs now - on Fedora 24 x86_64 (although for example it
still PASSes on CentOS-7.2 x86_64).
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff787c7bb in malloc_consolidate (av=av@entry=0x7ffff7bbcb00 <main_arena>) at malloc.c:4181
4181 unlink(av, nextchunk, bck, fwd);
(gdb) bt
[...]
[...]
This apparently is due to - man gcc - -fsplit-stack:
When code compiled with -fsplit-stack calls code compiled without
-fsplit-stack, there may not be much stack space available for the
latter code to run. If compiling all code, including library code,
with -fsplit-stack is not an option, then the linker can fix up these
calls so that the code compiled without -fsplit-stack always has
a large stack. Support for this is implemented in the gold linker in
GNU binutils release 2.21 and later.
gdb/testsuite/ChangeLog
2016-10-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/morestack.exp: Try to build it using -fuse-ld=gold first.
Fix a commit 4a556533cf ("Fix PR11094: JIT breakpoint is not properly
recreated on reruns") regression:
Running .../gdb/testsuite/gdb.base/killed-outside.exp ...
Executing on host: mips-mti-linux-gnu-gcc -Wl,--no-as-needed -c -g -o .../gdb/testsuite/outputs/gdb.base/killed-outside/killed-outside0.o .../gdb/testsuite/gdb.base/killed-outside.c .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so (timeout = 300)
spawn mips-mti-linux-gnu-gcc -Wl,--no-as-needed -c -g -o .../gdb/testsuite/outputs/gdb.base/killed-outside/killed-outside0.o .../gdb/testsuite/gdb.base/killed-outside.c .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so
mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
output is:
mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
gdb compile failed, mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
UNTESTED: gdb.base/killed-outside.exp: failed to prepare
and adjust the call to `prepare_for_testing' by removing a reference to
`options', which is not set in this test case but a stale value is
carried over from `gdb.base/jit-simple.exp' previously executed in a
full test suite run.
gdb/testsuite/
* gdb.base/killed-outside.exp: Remove $options from a call to
`prepare_for_testing'.
This patch skips some tests related to floating point in structs.exp
if gdb_skip_float_test return false.
gdb/testsuite:
2016-10-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/structs.exp: Invoke gdb_skip_float_test, and do
floating point tests if $skip_float_test is false.
Correct a commit 2151ccc56c ("Always organize test artifacts in a
directory hierarchy") regression causing:
Running .../gdb/testsuite/gdb.base/solib-disc.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.base/so-disc-shr.c.o: No such file or directory
by using `standard_output_file' to construct output file names
throughout.
gdb/testsuite/
* gdb.base/solib-disc.exp: Use `standard_output_file'
throughout.
Sergio Durigan Junior
Andreas Arnez
Simon Marchi
Pedro Alves
Martin Galvan
Jerome Guitton
Luis Machado
Yao Qi
Joel Brobecker
Doug Evans
Simon Marchi
Catherine Moore
Sandra Loosemore
Jan Kratochvil
Maciej W. Rozycki
Tom Tromey