Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
The problem is that we see gdbserver exiting before we match gdb's
output:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
Fix this by removing $inferior_spawn_id from the set of spawn ids
expect is watching as soon as we see the "end of file" string out of
the inferior spawn id, using an indirect spawn id list.
Tested on x86-64 Fedora 20, native and gdbserver (both target remote
and extended-remote).
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Use an indirect spawn id list holding
$inferior_spawn_id instead of $inferior_spawn_id directly. On
"end of file", remove $inferior_spawn_id from the indirect list.
To avoid confusion between "end of file" string matching and eof
matching, as in process exit.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Rename saw_eof to saw_end_of_file.
Since silent handling of eof is usually the wrong thing to do, this
patch makes gdb_test_multiple handle it for all $any_spawn_id.
Currently, against gdbserver, interrupt.exp occasionaly fails like
this:
FAIL: gdb.base/interrupt.exp: send end of file
gdb.log with expect debug output enabled shows:
expect: does "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n" (spawn_id exp8) match regular expression "end of file"? Gate "end of file"? gate=no
expect: read eof
expect: set expect_out(spawn_id) "exp8"
expect: set expect_out(buffer) "\r\n\r\nChild exited with status 0\r\nGDBserver exiting\r\n"
FAIL: gdb.base/interrupt.exp: send end of file
Note "expect: read eof" for spawn_id=exp8. exp8 is
inferior_spawn_id/gdbserver_spawn_id. That means
expect/gdb_test_multiple saw gdbserver exit before we got the expected
gdb output. Since there's no explicit pattern for "eof", expect (and
thus gdb_test_multiple) just returns.
After this commit, we get instead:
ERROR: Process no longer exists
UNRESOLVED: gdb.base/interrupt.exp: send end of file
Note that before we still got an FAIL because $saw_inferior_exit is 0
when we get to:
gdb_assert { $saw_eof && $saw_inferior_exit } $msg
Fixing the fail (now unresolved) will be the subject of a separate
patch.
gdb/testsuite/ChangeLog:
2015-04-23 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Match eof/full_buffer/timeout
on $any_spawn_id instead of only on $gdb_spawn_id.
Certain conversion operations as well as vfpclassp{d,s} are ambiguous
when the input operand is in memory and no broadcast is being used.
While in Intel mode this gets resolved by printing suitable operand
size modifiers, AT&T mode need mnemonic suffixes to be added.
gas/testsuite/
2015-04-23 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512dq.d: Add 'z' suffix to vfpclassp{d,s} non-
register, non-broadcast cases.
* gas/i386/x86-64-avx512dq.d: Likewise.
* gas/i386/avx512dq_vl.d: Add 'x' and 'y' suffixes to
vcvt{,u}qq2ps and vfpclassp{d,s} non-register, non-broadcast
cases.
* gas/i386/x86-64-avx512dq_vl.d: Likewise.
* gas/i386/avx512f_vl.d: Add 'x' and 'y' suffixes to
vcvt{,t}pd2{,u}dq and vcvtpd2ps non-register, non-broadcast
cases.
* gas/i386/x86-64-avx512f_vl.d: Likewise.
opcodes/
2015-04-23 Jan Beulich <jbeulich@suse.com>
* i386-dis.c (putop): Extend "XY" handling to AVX512. Handle "XZ".
* i386-dis-evex.h.c (vcvtpd2ps, vcvtqq2ps, vcvttpd2udq,
vcvtpd2udq, vcvtuqq2ps, vcvttpd2dq, vcvtpd2dq): Add %XY.
(vfpclasspd, vfpclassps): Add %XZ.
Certain conversion operations as well as vfpclassp{d,s} are ambiguous
when the input operand is in memory. That ambiguity, however, doesn't
apply when using broadcasts (the destination operand size can be
induced from the broadcast specifier).
gas/
2015-04-23 Jan Beulich <jbeulich@suse.com>
* config/tc-i386.c (match_mem_size): Also allow no size
specification when broadcasting.
gas/testsuite/
2015-04-23 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512dq.s: Drop 'z' suffix from vfpclassp{d,s} in
some AT&T and all Intel cases.
* gas/i386/x86-64-avx512dq.s: Likewise.
* gas/i386/avx512dq_vl.s: Drop 'x' and 'y' suffixes from
vcvt{,u}qq2ps and vfpclassp{d,s} in some AT&T and all Intel
cases.
* gas/i386/x86-64-avx512dq_vl.s: Likewise.
* gas/i386/avx512f_vl.s: Drop 'x' and 'y' suffixes from
vcvt{,t}pd2{,u}dq and vcvtpd2ps in some AT&T and all Intel
cases.
* gas/i386/x86-64-avx512f_vl.s: Likewise.
In readline 6.3, the semantics of SIGWINCH handling has changed.
When a SIGWINCH signal is raised, readline's rl_sigwinch_handler() now
does not immediately call rl_resize_terminal(). Instead it sets a flag
that is checked by RL_CHECK_SIGNALS() at a point where readline has
control, and calls rl_resize_terminal() if said flag is set.
This change is item (c) in https://cnswww.cns.cwru.edu/php/chet/readline/CHANGES
c. Fixed a bug that caused readline to try and run code to modify its idea
of the screen size in a signal handler context upon receiving a SIGWINCH.
This change in behavior is important to us because TUI's
tui_sigwinch_handler() relies on the assumption that by the time it's
called, readline will have updated its knowledge of the terminal
dimensions via rl_resize_terminal(). Since this assumption no longer
holds true, TUI's SIGWINCH handling does not work correctly with
readline 6.3.
To fix this issue this patch makes TUI explicitly call
rl_resize_terminal() in tui_async_resize_screen() at the point where
current terminal dimensions are needed. (We could call it in
tui_sigwinch_handler too, but since readline avoids doing it, we are
probably safer off avoiding to call it in signal handler context as
well.) After this change, SIGWINCH handling continues to work properly
with both readline 6.2 and 6.3.
Since we no longer need it, we could now explicitly disable readline's
SIGWINCH handler by setting rl_catch_sigwinch to zero early on in the
program startup but I can't seem to find a good spot to place this
assignment (the first call to rl_initialize() occurs in
tui_initialize_readline() so the assignment should occur before then),
and the handler is harmless anyway.
gdb/ChangeLog:
* tui/tui-win.c (tui_async_resize_screen): Call
rl_resize_terminal().
I didn't commit this with the relro and powerpc .TOC. changes,
thinking that something should be done about the odd result of
.shstrtab appearing in PT_GNU_RELRO. On looking at it further,
I think that changing readelf would be wrong, so let's just
accept the results. Real binaries will always have other sections
past .got, so PT_GNU_RELRO won't finish past the end of loaded
sections.
* ld-powerpc/tocnovar.d: Adjust.
Otherwise, it causes a build warning on some platforms such as MinGW.
libiberty/ChangeLog (Eli Zaretskii <eliz@gnu.org>):
* setenv.c <environ>: Declare only if not a macro.
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
This error occurs because when handle_output_debug_string processes a Cygwin
signal message, it re-writes current_event.dwThreadId to reflect the thread that
the signal will be delivered to, which can be different to the thread reporting
the signal.
Altering current_event.dwThreadId() will cause ContinueDebugEvent() to be
applied to the wrong thread and fail.
So, rather than re-writing the thread id in current_event, use the thread
id by returning it.
With this patch applied this test now yields the expected result:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:42
42 raise (SIGHUP); /* third HUP */
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (handle_output_debug_string): Don't change
current_event.dwThreadId.
(get_windows_debug_event): Use thread_id, rather than relying on
current_event.dwThreadId being changed.
Using the 'catch-signal' test from the testsuite, on x86_64 Cygwin:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
[hangs]
This is due to a defect in the way Cygwin signals are handled: When
handle_output_debug_string processes a Cygwin signal message, it re-writes
current_event.dwThreadId to reflect the thread that the signal will be delivered
to.
Subsequently, the call to ContinueDebugEvent will fail, because we're trying to
resume the wrong thread. GDB is then stuck waiting forever for another event
that will never come.
This patch doesn't fix the problem, it just adds appropriate error handling.
Using error() seems appropriate here, if ContinueDebugEvent() fails, the
inferior is in an unknown state and we will probably not be debugging it
anymore.
With this patch applied, resuming the execution of the program now yields:
$ ./gdb testsuite/outputs/gdb.base/catch-signal/catch-signal.exe
[...]
(gdb) catch signal
Catchpoint 1 (standard signals)
(gdb) r
[...]
Catchpoint 1 (signal SIGHUP), main () at
../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
(gdb) c
Continuing.
main () at ../../../gdb/testsuite/gdb.base/catch-signal.c:40
40 raise (SIGHUP); /* second HUP */
Failed to resume program execution (ContinueDebugEvent failed, error 87)
(gdb)
gdb/ChangeLog:
2015-04-22 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (windows_continue): Report an error if
ContinueDebugEvent() fails.
The linker tries to put the end of the last section in the relro
segment exactly on a page boundary, because the relro segment itself
must end on a page boundary. If for any reason this can't be done,
padding is inserted. Since the end of the relro segment is typically
between .got and .got.plt, padding effectively increases the size of
the GOT. This isn't nice for targets and code models with limited GOT
addressing.
The problem with the current code is that it doesn't cope very well
with aligned sections in the relro segment. When making .got aligned
to a 256 byte boundary for PowerPC64, I found that often the initial
alignment attempt failed and the fallback attempt to be less than
adequate. This is a particular problem for PowerPC64 since the
distance between .got and .plt affects the size of plt call stubs,
leading to "stubs don't match calculated size" errors.
So this rewrite takes a direct approach to calculating a new relro
base. Starting from the last section in the segment, we calculate
where it must start to position its end on the boundary, or as near as
possible considering alignment requirements. The new start then
becomes the goal for the previous section to end, and so on for all
sections. This of course ignores the possibility that user scripts
will place . = ALIGN(xxx); in the relro segment, or provide section
address expressions. In those cases we might fail, but the old code
probably did too, and a fallback is provided.
ld/
* ldexp.h (struct ldexp_control): Delete dataseg.min_base. Add
data_seg.relro_offset.
* ldexp.c (fold_binary <DATA_SEGMENT_ALIGN>): Don't set min_base.
(fold_binary <DATA_SEGMENT_RELRO_END>): Do set relro_offset.
* ldlang.c (lang_size_sections): Rewrite code adjusting relro
segment base to line up last section on page boundary.
ld/testsuite/
* ld-x86-64/pr18176.d: Update.
Problem reported as PR pascal/17815
Part 1/3: Remember the case pattern that allowed finding a field of this.
File gdb/p-exp.y modified
This is the fix in the pascal parser (p-exp.y),
to avoid the error that GDB does find normal variables
case insensitively, but not fields of this,
inside a class or object method.
Part 2/3: Add "class" option for pascal compiler
File gdb/testsuite/lib/pascal.exp
This part of the patch series is unchanged.
It adds class option to pascal compiler
which adds the required command line option to
accept pascal class types.
Part 3/3:
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.exp
New file: gdb/testsuite/gdb.pascal/case-insensitive-symbols.pas
Here is an updated version of this test, using Pedro's suggestions.
Test to check that PR 17815 is fixed.
These printf statements are showing "word" objects which are typedefed
from long, so make sure to use l with %x when printing them to avoid
warnings from gcc.
Re-use the existing memory core that handles reads/writes.
The verbose command is converted to the common --verbose flag
since only a few call sites use it now.
In preparation for converting to the common memory framework, the custom
commands get in our way. But when we realize that gdb support has been
dropped for mcore, it makes things a bit easier: the main runner does not
let you run arbitrary commands once simulation starts.
So lets disable watchpoint support until it can be converted to the common
watchpoint logic. There's already an ifdef to let us do that.
We straight up drop support for the dumpmem command (no other sim supports
this, and if it's a feature people want, we can add a common func) and the
clearstats command (not a big deal -- just restart your simulation).
We leave in place the verbose check points as a follow up commit will cut
that over to common logic.
Now that libgloss has a header tracking the syscalls for this arch, we
can update the database to include it for the symbolic constants/maps.
Then we can switch the mcore syscall callbacks over to the common ones.
Since newlib no longer shares the same repo as binutils/gdb, we have to go
searching further afield to locate the sources. We still look at the top
level for newlib, but if that is not found, we also try up one dir outside
of this source tree. It sucks, but better than the status quo (no workie).
This patch extends the rl78 prologue analyzer so that it can recognize
this kind of prologue:
0x119f <main>: movw ax, sp
0x11a1 <main+2>: subw ax, #0x1fa6
0x11a4 <main+5>: movw sp, ax
The test case for gdb.base/miscexprs.exp is now compiled to generate
that sequence instead of a much longer and more inefficient sequence.
gdb/ChangeLog:
* rl78-tdep.c (RL78_SP_ADDR): Define.
(opc_reg_to_gdb_regnum): New static function.
(rl78_analyze_prologue): Recognize instructions forming slightly
more interesting prologues.
commit 9ad5cbcfb2 added the initial support
for more than 64k ELF sections with holes for reserved section indices in
section header table and set entries of reserved section indices in
section header table to index 0:
for (secn = 1; secn < section_number; ++secn)
- i_shdrp[secn]->sh_name = _bfd_elf_strtab_offset (elf_shstrtab (abfd),
- i_shdrp[secn]->sh_name);
-
+ if (i_shdrp[secn] == NULL)
+ i_shdrp[secn] = i_shdrp[0];
+ else
+ i_shdrp[secn]->sh_name = _bfd_elf_strtab_offset (elf_shstrtab (abfd),
+ i_shdrp[secn]->sh_name);
commit 4fbb74a605 removed holes in section
header table. Check for i_shdrp[secn] == NULL is no longer needed now.
This patch removes it.
* elf.c (assign_section_numbers): Always set up sh_name.
Iterate ELF sections by pointer without section counter. It removes
"i++".
* elf.c (assign_file_positions_for_non_load_sections): Iterate
sections by pointer.
(_bfd_elf_assign_file_positions_for_non_load): Likewise.
This patch silences texinfo 5.1 warnings by using @subsection and
sorting entries in Machine Dependencies menu.
* doc/as.texinfo (Bundle directives): Shorten menu entry and
use @subsection.
(CFI directives): Use @subsection.
(SH-Dependent, SH64-Dependent): Moved after SCORE-Dependent.
* doc/c-i386.texi (i386-Mnemonics): Use @subsection.
This commit fixes three gdb.base/attach.exp failures when using
extended remote targets. The failures occurred because GDB now
locates and loads files when attaching on remote targets if the
remote target supports qXfer:exec-file:read; the filenames were
shown but with "target:" prefixes which the test has been updated
to handle.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Fix three extended remote failures.
Code in update_dprintf_command_list performed a duplicated memory
allocation which caused an obvious memory leak. This removes the
duplication.
gdb/
2015-04-19 Gabriel Krisman Bertazi <gabriel@krisman.be>
* breakpoint.c (update_dprintf_command_list): Remove duplicated
xmalloc.
gdb/
* reply_mig_hack.awk: Don't bother to declare an intermediate
function pointer variable.
... allowing us to simplify the parsing a little bit. And, instead of
"warning: initialization from incompatible pointer type", we now get "warning:
function called through a non-compatible type". Oh well.
Change data ordering in emulated memory from target order (big endian)
to host order. Improves performance and simplifies most memory
operations. Requires some byte twisting during stores on little
endian hosts (intel). Also removed support for little-endian binaries.
Now that we've unified sim-cpu, we can delete the duplicate sim-engine
hooks -- these targets defined these only because they didn't fully
implement the sim-cpu callbacks.
Since every target typedefs this the same way, move it to the common code.
We have to leave Blackfin behind here for now because of inter-dependencies
on types and headers: sim-base.h includes sim-model.h which needs types in
machs.h which needs types in bfim-sim.h which needs SIM_CPU.
Almost every target defines sim_cia the same way -- either using the
address_word type directly, or a type of equivalent size. The only
odd one out is sh64 (who has 32bit address_word and 64bit cia), and
even that case doesn't seem to make sense. We'll put off clean up
though of sh64 and at least set up a sensible default for everyone.
gdb/ChangeLog:
* solib-svr4.c (svr4_exec_displacement): Rename outer "displacement"
to "exec_displacement" to avoid confusion with inner use of the name.
