This commit introduces a new shared function to replace three
identical functions in various places in the codebase.
gdb/ChangeLog:
* common/common-remote-fileio.h (remote_fileio_to_fio_error):
New declaration.
* common/common-remote-fileio.c (remote_fileio_to_fio_error):
New function, factored out the named functions below.
* inf-child.c (gdb/fileio.h): Remove include.
(common-remote-fileio.h): New include.
(inf_child_errno_to_fileio_error): Remove function. Update
all callers to use remote_fileio_to_fio_error.
* remote-fileio.c (remote_fileio_errno_to_target): Likewise.
gdb/gdbserver/ChangeLog:
* hostio-errno.c (errno_to_fileio_error): Remove function.
Update caller to use remote_fileio_to_fio_error.
bfd * elf32-rx.c (describe_flags): Report the settings of the string
insn using bits.
(rx_elf_merge_private_bfd_data): Handle merging of the string insn
using bits.
bin * readelf.c (get_machine_flags): Report the setting of the string
insn using bits.
gas * config/tc-rx.c (enum options): Add OPTION_DISALLOW_STRING_INSNS.
(md_longopts): Add -mno-allow-string-insns.
(md_parse_option): Handle -mno-allow-string-insns.
(md_show_usage): Mention -mno-allow-string-insns.
(rx_note_string_insn_use): New function. Produces an error
message if a string insn is used when it is not allowed.
* config/rx-parse.y (SCMPU): Call rx_note_string_insn_use.
(SMOVU, SMOVB, SMOVF, SUNTIL, SWHILE, RMPA): Likewise.
* config/rx-defs.h (rx_note_string_insn_use): Prototype.
* doc/c-rx.texi: Document -mno-allow-string-insns.
elf * rx.h (E_FLAG_RX_SINSNS_SET): New bit in e_flags field.
(E_FLAG_RX_SINSNS_YES): Likewise.
(E_FLAG_RX_SINSNS_MASK): New define.
gdb/ChangeLog:
2015-04-09 Pedro Alves <palves@redhat.com>
* gnulib/update-gnulib.sh (aclocal version check): Filter out
"called too early to check prototype".
Hi,
I see the following error on arm linux gdbserver,
continue^M
Continuing.^M
../../../binutils-gdb/gdb/gdbserver/linux-arm-low.c:458: A problem internal to GDBserver has been detected.^M
raw_bkpt_type_to_arm_hwbp_type: unhandled raw type^M
Remote connection closed^M
(gdb) FAIL: gdb.base/cond-eval-mode.exp: hbreak: continue
After we make GDBserver handling Zx/zx packet idempotent,
[PATCH 3/3] [GDBserver] Make Zx/zx packet handling idempotent.
https://sourceware.org/ml/gdb-patches/2014-04/msg00480.html
> Now removal/insertion of all kinds of breakpoints/watchpoints, either
> internal, or from GDB, always go through the target methods.
GDBserver handles all kinds of breakpoints/watchpoints through target
methods. However, some target backends, such as arm, don't support Z0
packet but need software breakpoint to do breakpoint stepping over in
linux-low.c:start_step_over,
if (can_hardware_single_step ())
{
step = 1;
}
else
{
CORE_ADDR raddr = (*the_low_target.breakpoint_reinsert_addr) ();
set_reinsert_breakpoint (raddr);
step = 0;
}
a software breakpoint is requested to the backend, and the error is
triggered. This problem should affect targets having
breakpoint_reinsert_addr hooked.
Instead of handling memory breakpoint in these affected linux backend,
this patch handles memory breakpoint in linux_{insert,remove}_point,
that, if memory breakpoint is requested, call
{insert,remove}_memory_breakpoint respectively. Then, it becomes
unnecessary to handle memory breakpoint for linux x86 backend, so
this patch removes the code there.
This patch is tested with GDBserver on x86_64-linux and arm-linux
(-marm, -mthumb). Note that there are still some fails in
gdb.base/cond-eval-mode.exp with -mthumb, because GDBserver doesn't
know how to select the correct breakpoint instruction according to
the arm-or-thumb-mode of requested address. This is a separate
issue, anyway.
gdb/gdbserver:
2015-04-09 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_insert_point): Call
insert_memory_breakpoint if TYPE is raw_bkpt_type_sw.
(linux_remove_point): Call remove_memory_breakpoint if type is
raw_bkpt_type_sw.
* linux-x86-low.c (x86_insert_point): Don't call
insert_memory_breakpoint.
(x86_remove_point): Don't call remove_memory_breakpoint.
When --enable-targets=all is used with non-ELF target, we should enable
ELF ld_list_options.
* configure.ac (elf_list_options): Set to TRUE for
--enable-targets=all.
(elf_shlib_list_options): Likewise.
(elf_plt_unwind_list_options): Likewise.
* configure: Regenerated.
This patch is related to PR python/16699, and is an improvement over the
patch posted here:
<https://sourceware.org/ml/gdb-patches/2014-03/msg00301.html>
Keith noticed that, when using the "complete" command on GDB to complete
a Python command, some strange things could happen. In order to
understand what can go wrong, I need to explain how the Python
completion mechanism works.
When the user requests a completion of a Python command by using TAB,
GDB will first try to determine the right set of "brkchars" that will be
used when doing the completion. This is done by actually calling the
"complete" method of the Python class. Then, when we already know the
"brkchars" that will be used, we call the "complete" method again, for
the same values.
If you read the thread mentioned above, you will see that one of the
design decisions was to make the "cmdpy_completer_helper" (which is the
function the does the actual calling of the "complete" method) cache the
first result of the completion, since this result will be used in the
second call, to do the actual completion.
The problem is that the "complete" command does not process the
brkchars, and the current Python completion mechanism (improved by the
patch mentioned above) relies on GDB trying to determine the brkchars,
and then doing the completion itself. Therefore, when we use the
"complete" command instead of doing a TAB-completion on GDB, there is a
scenario where we can use the invalid cache of a previous Python command
that was completed before. For example:
(gdb) A <TAB>
(gdb) complete B
B value1
B value10
B value2
B value3
B value4
B value5
B value6
B value7
B value8
B value9
(gdb) B <TAB>
comp1 comp2 comp4 comp6 comp8
comp10 comp3 comp5 comp7 comp9
Here, we see that "complete B " gave a different result than "B <TAB>".
The reason for that is because "A <TAB>" was called before, and its
completion results were "value*", so when GDB tried to "complete B " it
wrongly answered with the results for A. The problem here is using a
wrong cache (A's cache) for completing B.
We tried to come up with a solution that would preserve the caching
mechanism, but it wasn't really possible. So I decided to completely
remove the cache, and doing the method calling twice for every
completion. This is not optimal, but I do not think it will impact
users noticeably.
It is worth mentioning another small issue that I found. The code was
doing:
wordobj = PyUnicode_Decode (word, sizeof (word), host_charset (), NULL);
which is totally wrong, because using "sizeof" here will lead to always
the same result. So I changed this to use "strlen". The testcase also
catches this problem.
Keith kindly expanded the existing testcase to cover the problem
described above, and everything is passing.
gdb/ChangeLog:
2015-04-08 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/16699
* python/py-cmd.c (cmdpy_completer_helper): Adjust function to not
use a caching mechanism. Adjust comments and code to reflect
that. Replace 'sizeof' by 'strlen' when fetching 'wordobj'.
(cmdpy_completer_handle_brkchars): Adjust call to
cmdpy_completer_helper. Call Py_XDECREF for 'resultobj'.
(cmdpy_completer): Likewise.
gdb/testsuite/ChangeLog:
2015-04-08 Keith Seitz <keiths@redhat.com>
PR python/16699
* gdb.python/py-completion.exp: New tests for completion.
* gdb.python/py-completion.py (CompleteLimit1): New class.
(CompleteLimit2): Likewise.
(CompleteLimit3): Likewise.
(CompleteLimit4): Likewise.
(CompleteLimit5): Likewise.
(CompleteLimit6): Likewise.
(CompleteLimit7): Likewise.
Both PRs are triggered by the same use case.
PR18214 is about software single-step targets. On those, the 'resume'
code that detects that we're stepping over a breakpoint and delivering
a signal at the same time:
/* Currently, our software single-step implementation leads to different
results than hardware single-stepping in one situation: when stepping
into delivering a signal which has an associated signal handler,
hardware single-step will stop at the first instruction of the handler,
while software single-step will simply skip execution of the handler.
...
Fortunately, we can at least fix this particular issue. We detect
here the case where we are about to deliver a signal while software
single-stepping with breakpoints removed. In this situation, we
revert the decisions to remove all breakpoints and insert single-
step breakpoints, and instead we install a step-resume breakpoint
at the current address, deliver the signal without stepping, and
once we arrive back at the step-resume breakpoint, actually step
over the breakpoint we originally wanted to step over. */
doesn't handle the case of _another_ thread also needing to step over
a breakpoint. Because the other thread is just resumed at the PC
where it had stopped and a breakpoint is still inserted there, the
thread immediately re-traps the same breakpoint. This test exercises
that. On software single-step targets, it fails like this:
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2: continue to sigusr1_handler
gdb.log (simplified):
(gdb) continue
Continuing.
Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) thread 3
(gdb) queue-signal SIGUSR1
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))]
#0 main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106
106 wait_threads (); /* set wait-threads breakpoint here */
(gdb) break sigusr1_handler
Breakpoint 5 at 0x400837: file src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31.
(gdb) continue
Continuing.
[Switching to Thread 0x7ffff7fc0700 (LWP 24828)]
Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
66 callme (); /* set breakpoint thread 2 here */
(gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler
For good measure, I made the test try displaced stepping too. And
then I found it crashes GDB on x86-64 (a hardware step target), but
only when displaced stepping... :
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2: continue to sigusr1_handler (PRMS: gdb/18216)
KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3: continue to sigusr1_handler (PRMS: gdb/18216)
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
4964 if (sr_bp->loc->permanent
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54.
Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217.
(top-gdb) p sr_bp
$1 = (struct breakpoint *) 0x0
(top-gdb) bt
#0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
#1 0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715
#2 0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165
#3 0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298
#4 0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
#5 0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658
#6 0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0, ready_mask=1) at src/gdb/event-loop.c:658
The all-stop-non-stop series fixes this, but meanwhile, this augments
the multiple-step-overs.exp test to cover this, KFAILed.
gdb/testsuite/ChangeLog:
2015-04-08 Pedro Alves <palves@redhat.com>
PR gdb/18214
PR gdb/18216
* gdb.threads/multiple-step-overs.c (sigusr1_handler): New
function.
(main): Install it as SIGUSR1 handler.
* gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
parameter. Always use "setup" as prefix. Toggle "set
displaced-stepping" off/on depending on global. Don't switch to
thread 1 here.
(top level): Add displaced stepping "off/on" test axis. Update
"setup" calls. Wrap each subtest with with_test_prefix. Test
continuing with a queued signal in each thread.
Nowadays, in infrun.c:resume, the setting to 'step' variable is like:
if (use_displaced_stepping (gdbarch)
&& tp->control.trap_expected
&& sig == GDB_SIGNAL_0
&& !current_inferior ()->waiting_for_vfork_done)
{
}
/* Do we need to do it the hard way, w/temp breakpoints? */
else if (step)
step = maybe_software_singlestep (gdbarch, pc); <-- [1]
...
if (execution_direction != EXEC_REVERSE
&& step && breakpoint_inserted_here_p (aspace, pc))
{
...
if (gdbarch_cannot_step_breakpoint (gdbarch)) <-- [2]
step = 0;
}
spu doesn't have displaced stepping and uses software single step,
so 'step' is set to zero in [1], and [2] becomes unreachable as a
result. So don't have to call set_gdbarch_cannot_step_breakpoint
in spu_gdbarch_init.
gdb:
2015-04-08 Yao Qi <yao.qi@linaro.org>
* spu-tdep.c (spu_gdbarch_init): Don't call
set_gdbarch_cannot_step_breakpoint.
This patch adds --compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}
options to gas and objcopy for ELF files. They control how DWARF debug
sections are compressed. --compress-debug-sections=none is equivalent to
--nocompress-debug-sections. --compress-debug-sections=zlib and
--compress-debug-sections=zlib-gnu are equivalent to
--compress-debug-sections. --compress-debug-sections=zlib-gabi compresses
DWARF debug sections with SHF_COMPRESSED from the ELF ABI. No linker
changes are required to support SHF_COMPRESSED.
bfd/
* archive.c (_bfd_get_elt_at_filepos): Also copy BFD_COMPRESS_GABI
bit.
* bfd.c (bfd::flags): Increase size to 18 bits.
(BFD_COMPRESS_GABI): New.
(BFD_FLAGS_SAVED): Add BFD_COMPRESS_GABI.
(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.
(bfd_update_compression_header): New fuction.
(bfd_check_compression_header): Likewise.
(bfd_get_compression_header_size): Likewise.
(bfd_is_section_compressed_with_header): Likewise.
* compress.c (MAX_COMPRESSION_HEADER_SIZE): New.
(bfd_compress_section_contents): Return the uncompressed size if
the full section contents is compressed successfully. Support
converting from/to .zdebug* sections.
(bfd_get_full_section_contents): Call
bfd_get_compression_header_size to get compression header size.
(bfd_is_section_compressed): Renamed to ...
(bfd_is_section_compressed_with_header): This. Add a pointer
argument to return compression header size.
(bfd_is_section_compressed): Use it.
(bfd_init_section_decompress_status): Call
bfd_get_compression_header_size to get compression header size.
Return FALSE if uncompressed section size is 0.
* elf.c (_bfd_elf_make_section_from_shdr): Support converting
from/to .zdebug* sections.
* bfd-in2.h: Regenerated.
binutils/
* objcopy.c (do_debug_sections): Add compress_zlib,
compress_gnu_zlib and compress_gabi_zlib.
(copy_options): Use optional_argument on compress-debug-sections.
(copy_usage): Update --compress-debug-sections.
(copy_file): Handle compress_zlib, compress_gnu_zlib and
compress_gabi_zlib.
(copy_main): Handle
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
* doc/binutils.texi: Document
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
binutils/testsuite/
* compress.exp: Add tests for
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
* binutils-all/dw2-3.rS: New file.
* binutils-all/dw2-3.rt: Likewise.
* binutils-all/libdw2-compressedgabi.out: Likewise.
gas/
* as.c (show_usage): Update --compress-debug-sections.
(std_longopts): Use optional_argument on compress-debug-sections.
(parse_args): Handle
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
* as.h (compressed_debug_section_type): New.
(flag_compress_debug): Change type to compressed_debug_section_type.
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
* write.c (compress_debug): Set BFD_COMPRESS_GABI for
--compress-debug-sections=zlib-gabi. Call
bfd_get_compression_header_size to get compression header size.
Don't rename section name for --compress-debug-sections=zlib-gabi.
* config/tc-i386.c (compressed_debug_section_type): Set to
COMPRESS_DEBUG_ZLIB.
* doc/as.texinfo: Document
--compress-debug-sections={none|zlib|zlib-gnu|zlib-gabi}.
gas/testsuite/
* gas/i386/dw2-compressed-1.d: New file.
* gas/i386/dw2-compressed-2.d: Likewise.
* gas/i386/dw2-compressed-3.d: Likewise.
* gas/i386/x86-64-dw2-compressed-2.d: Likewise.
* gas/i386/i386.exp: Run dw2-compressed-2, dw2-compressed-1,
dw2-compressed-3 and x86-64-dw2-compressed-2.
ld/testsuite/
* ld-elf/compress.exp: Add a test for
--compress-debug-sections=zlib-gabi.
(build_tests): Add 2 tests for --compress-debug-sections=zlib-gabi.
(run_tests): Likewise.
Verify linker output with zlib-gabi compressed debug input.
* ld-elf/compressed1a.d: New file.
* ld-elf/compressed1b.d: Likewise.
* ld-elf/compressed1c.d: Likewise.
Optional argument of a command line option must start with "=".
* objcopy.c (copy_usage): Replace "--interleave [<number>]" with
--interleave[=<number>].
The recent actions.exp change to check gdb_run_cmd succeeded caught
further problems. The test now fails like this
with --target_board=native-extended-gdbserver:
FAIL: gdb.trace/actions.exp: Can't run to main
gdb.log shows:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.trace/actions
Running the default executable on the remote target failed; try "set remote exec-file"?
(gdb) FAIL: gdb.trace/actions.exp: Can't run to main
The problem is that a gdb_load call is missing.
Grepping around for similar problems in other tests, I found that
infotrace.exp and while-stepping.exp should be likewise affected. And
indeed this is what we get today:
FAIL: gdb.trace/infotrace.exp: tstart
FAIL: gdb.trace/infotrace.exp: continue to end (the program is no longer running)
FAIL: gdb.trace/infotrace.exp: tstop
FAIL: gdb.trace/infotrace.exp: 2.6: info tracepoints (trace buffer usage)
FAIL: gdb.trace/while-stepping.exp: tstart
FAIL: gdb.trace/while-stepping.exp: tstop
FAIL: gdb.trace/while-stepping.exp: tfile: info tracepoints
FAIL: gdb.trace/while-stepping.exp: ctf: info tracepoints
while-stepping.exp even has the same race bug actions.exp had.
After this, {actions,infotrace,while-stepping}.exp all pass cleanly
with the native-extended-gdbserver board.
gdb/testsuite/ChangeLog:
2015-04-08 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_load before gdb_run_cmd.
* gdb.trace/infotrace.exp: Use gdb_load before gdb_run_cmd. Use
gdb_breakpoint instead of gdb_test that doesn't expect anything.
Return early if running to main fails.
* gdb.trace/while-stepping.exp: Likewise.
The gdb.base/interrupt.exp test is important for testing system call
restarting, but because it depends on inferior I/O, it ends up skipped
against gdbserver. This patch adjusts the test to use send_inferior
and $inferior_spawn_id so it works against GDBserver.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't skip if $inferior_spawn_id !=
$gdb_spawn_id. Use send_inferior and $inferior_spawn_id to
interact with inferior program.
Some important tests, like gdb.base/interrupt.exp end up skipped
against gdbserver, because they depend on inferior I/O, which
gdbserver doesn't do.
This patch adds a mechanism that makes it possible to make them work.
It adds a new "inferior_spawn_id" global that is the spawn ID used for
I/O interaction with the inferior. By default, for native targets, or
remote targets that can do I/O through GDB (semi-hosting) this will be
the same as the gdb/host spawn ID. Otherwise, the board may set this
to some other spawn ID. When debugging with GDBserver, this will be
set to GDBserver's spawn ID.
Then tests can use send_inferior instead of send_gdb to send input to
the inferior, and use expect's "-i" switch to select which spawn ID to
use for matching input/output. That is, something like this will now
work:
send_inferior "echo me\n"
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "echo me\r\necho\r\n" {
...
}
}
Or even:
gdb_test_multiple "continue" "test msg" {
-i "$inferior_spawn_id" -re "hello world" {
...
}
-i "$gdb_spawn_id" -re "error.*$gdb_prompt $" {
...
}
}
Of course, by default, gdb_test_multiple still matches with
$gdb_spawn_id.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (inferior_spawn_id): New global.
(gdb_test_multiple): Handle "-i". Reset the spawn id to GDB's
spawn id after processing the user code.
(default_gdb_start): Set inferior_spawn_id.
(send_inferior): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Set
inferior_spawn_id.
(close_gdbserver, gdb_exit): Unset inferior_spawn_id.
I adjusted a test to do 'expect -i $server_spawn_id -re ...', and saw
really strange behavior. Whether that expect would work, depended on
whether GDB would also send output and the same expect matched it too
(on $gdb_spawn_id). I was perplexed until I noticed that
gdbserver_spawn spawns gdbserver and then uses expect_background to
reap gdbserver. That expect_background conflicts/races with any
"expect -i $server_spawn_id" done anywhere else in parallel...
In order to make it possible for tests to read inferior I/O out of
$server_spawn_id, we to get rid of that expect_background. This patch
makes us instead reap gdbserver's spawn id when GDB exits. If GDB is
still around, this gives a chance for gdbserver to exit cleanly. The
current code in gdb_finish uses "kill", but that doesn't work with
extended-remote (gdbserver doesn't exit). We now use "monitor exit"
instead which works in both remote and extended-remote modes.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_finish): Delete persistent gdbserver handling.
* lib/gdbserver-support.exp (gdbserver_start): Make
$server_spawn_id global.
(gdbserver_start): Don't wait for gdbserver's spawn id with
expect_background.
(close_gdbserver): New procedure.
(gdb_exit): Rename the default version and reimplement.
While teaching gdb_test_multiple to forward "-i" to gdb_expect, I
found that with:
gdb_test_multiple (...) {
-i $some_variable -re "..." {}
}
$some_variable was not getting expanded in the gdb_test_multiple
caller's scope. This is a bug inside gdb_test_multiple. When
processing an argument in passed in user code, it was appending the
original argument literally, instead of appending the uplist'ed
argument.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): When processing an argument,
append the substituted item, not the original item.
Working on splitting gdb and inferior output handling in this test, I
noticed a race that happens to be masked out today.
The test sends "a\n" to the inferior, and then inferior echoes back
"a\n".
If expect manages to read only the first "a\r\n" into its buffer, then
this matches:
-re "^a\r\n(|a\r\n)$" {
and leaves the second "a\r\n" in output.
Then the next test that processes inferior I/O sends "data\n", and expects:
-re "^(\r\n|)data\r\n(|data\r\n)$"
which fails given the anchor and given "a\r\n" is still in the buffer.
This is masked today because the test relies on inferior I/O being
done on GDB's terminal, and there are tested GDB commands in between,
which consume the "a\r\n" that was left in the output.
We don't support SunOS4 anymore, so just remove the workaround.
gdb/testsuite/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Don't handle the case of the inferior
output appearing once only.
I saw this on PPC64 once:
not installed on target
(gdb) PASS: gdb.trace/actions.exp: 5.10a: verify teval actions set for two tracepoints
break main
Breakpoint 4 at 0x10000c6c: file ../../../src/gdb/testsuite/gdb.trace/actions.c, line 139.
(gdb) PASS: gdb.trace/actions.exp: break main
run
Starting program: /home/palves/gdb/build/gdb/testsuite/outputs/gdb.trace/actions/actions
tstatus
Breakpoint 4, main (argc=1, argv=0x3fffffffebb8, envp=0x3fffffffebc8) at ../../../src/gdb/testsuite/gdb.trace/actions.c:139
139 begin ();
(gdb) tstatus
Trace can not be run on this target.
(gdb) actions 1
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $regs
>end
(gdb) PASS: gdb.trace/actions.exp: set actions for first tracepoint
tstart
You can't do that when your target is `native'
(gdb) FAIL: gdb.trace/actions.exp: tstart
info tracepoints 1
Num Type Disp Enb Address What
1 tracepoint keep y 0x00000000100007c8 in gdb_c_test at ../../../src/gdb/testsuite/gdb.trace/actions.c:74
collect $regs
not installed on target
...
followed by a cascade of FAILs. The "tstatus" was supposed to detect
that this target (native) can't do tracepoints, but, alas, it didn't.
That detection failed because 'gdb_test "break main"' doesn't expect
anything, and then the output was slow enough that 'gdb_test ""
"Breakpoint .*"' matched the output of "break main"...
The fix is to use gdb_breakpoint instead. Also check the result of
gdb_test while at it.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/testsuite/ChangeLog:
2015-04-07 Pedro Alves <palves@redhat.com>
* gdb.trace/actions.exp: Use gdb_breakpoint instead of gdb_test
that doesn't expect anything. Return early if running to main
fails.
ld * ld.h (struct ld_config_type): Add new field: warn_orphan.
* ldlex.h (enum option_values): Add OPTION_WARN_ORPHAN and
OPTION_NO_WARN_ORPHAN.
* lexsup.c (ld_options): Add --warn-orphan and --no-warn-orphan.
(parse_args): Handle the new options.
* ldemul.c (ldemul_place_orphan): If requested, generate a warning
message when an orphan section is placed in the output file.
* ld.texinfo: Document the new option.
* NEWS: Mention the new feature.
tests * ld-elf/orphan-5.l: New test - checks the linker's output with
--warn-orphan enabled.
* ld-elf/elf.exp: Run the new test.
On GNU/Linux, if the running kernel supports clone events, then
linux-thread-db.c defers thread listing to the target beneath:
static void
thread_db_update_thread_list (struct target_ops *ops)
{
...
if (target_has_execution && !thread_db_use_events ())
ops->beneath->to_update_thread_list (ops->beneath);
else
thread_db_update_thread_list_td_ta_thr_iter (ops);
...
}
However, when live debugging, the target beneath, linux-nat.c, does
not implement the to_update_thread_list method. The result is that if
a thread is marked exited (because it can't be deleted right now,
e.g., it was the selected thread), then it won't ever be deleted,
until the process exits or is killed/detached.
A similar thing happens with the remote.c target. Because its
target_update_thread_list implementation skips exited threads when it
walks the current thread list looking for threads that no longer exits
on the target side, using ALL_NON_EXITED_THREADS_SAFE, stale exited
threads are never deleted.
This is not a big deal -- I can't think of any way this might be user
visible, other than gdb's memory growing a tiny bit whenever a thread
gets stuck in exited state. Still, might as well clean things up
properly.
All other targets use prune_threads, so are unaffected.
The fix adds a ALL_THREADS_SAFE macro, that like
ALL_NON_EXITED_THREADS_SAFE, walks the thread list and allows deleting
the iterated thread, and uses that in places that are walking the
thread list in order to delete threads. Actually, after converting
linux-nat.c and remote.c to use this, we find the only other user of
ALL_NON_EXITED_THREADS_SAFE is also walking the list to delete
threads. So we convert that too, and end up deleting
ALL_NON_EXITED_THREADS_SAFE.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): Rename to ...
(ALL_THREADS_SAFE): ... this, and don't skip exited threads.
(delete_exited_threads): New declaration.
* infrun.c (follow_exec): Use ALL_THREADS_SAFE.
* linux-nat.c (linux_nat_update_thread_list): New function.
(linux_nat_add_target): Install it.
* remote.c (remote_update_thread_list): Use ALL_THREADS_SAFE.
* thread.c (prune_threads): Use ALL_THREADS_SAFE.
(delete_exited_threads): New function.
Fixes tic6x testsuite failures due to .rela.plt having a zero sh_info.
I considered passing link_info to get_reloc_section so we could
directly return the .got.plt output section, but we need the fallback
to name lookup anyway for objcopy.
bfd/
* elf.c (_bfd_elf_get_reloc_section): Allow for .got.plt being
mapped to output .got section.
ld/testsuite/
* ld-arm/tls-gdesc-nlazy.g: Adjust for readelf note.
* ld-tic6x/shlib-1.rd: Expect corrected .rela.plt sh_info.
* ld-tic6x/shlib-1b.rd: Likewise.
* ld-tic6x/shlib-1r.rd: Likewise.
* ld-tic6x/shlib-1rb.rd: Likewise.
* ld-tic6x/shlib-app-1.rd: Likewise.
* ld-tic6x/shlib-app-1b.rd: Likewise.
* ld-tic6x/shlib-app-1r.rd: Likewise.
* ld-tic6x/shlib-app-1rb.rd: Likewise.
* ld-tic6x/shlib-noindex.rd: Likewise.
This is a linker-only solution to the incompatibility between shared
library protected visibility variables and using .dynbss and copy
relocs for non-PIC access to shared library variables.
bfd/
* elf32-ppc.c (struct ppc_elf_link_hash_entry): Add has_addr16_ha
and has_addr16_lo. Make has_sda_refs a bitfield.
(ppc_elf_check_relocs): Set new flags.
(ppc_elf_link_hash_table_create): Update default_params.
(ppc_elf_adjust_dynamic_symbol): Clear protected_def in cases
where we won't be making .dynbss entries or editing code. Set
params->pic_fixup when we'll edit code for protected var access.
(allocate_dynrelocs): Allocate got entry for edited code and
discard dyn_relocs.
(struct ppc_elf_relax_info): Add picfixup_size.
(ppc_elf_relax_section): Rename struct one_fixup to struct
one_branch_fixup. Rename fixups to branch_fixups. Size space for
pic fixups.
(ppc_elf_relocate_section): Edit non-PIC accessing protected
visibility variables to PIC. Don't emit dyn_relocs for code
we've edited.
* elf32-ppc.h (struct ppc_elf_params): Add pic_fixup.
ld/
* emultempl/ppc32elf.em: Handle --no-pic-fixup.
(params): Init new field.
(ppc_before_allocation): Enable relaxation for pic_fixup.
Although not currently possible in practice when we get here,
'resume_ptid' can also be a wildcard throughout this function. It's
clearer to fetch the regcache using the thread's ptid.
gdb/ChangeLog:
2015-04-07 Pedro Alves <pedro@codesourcery.com>
* infrun.c (resume) <displaced stepping debug output>: Get the
leader thread's regcache, not resume_ptid's.
Nowadays, the alarm value is 60, and alarm is generated on some slow
boards. This patch is to pass DejaGNU timeout value to the program,
and move the alarm call before going to infinite loop. If any thread
has activities, the alarm is reset.
gdb/testsuite:
2015-04-07 Yao Qi <yao.qi@linaro.org>
* gdb.threads/non-stop-fair-events.c (SECONDS): New macro.
(child_function): Call alarm.
(main): Move call to alarm into the loop.
* gdb.threads/non-stop-fair-events.exp: Build program with
-DTIMEOUT=$timeout.
